The Design Dash (or, in hashtag form, #designdash) is a quick introductory design thinking exercise for you to use. Download it from GitHub:

• Design Dash - EN (PDF, PPT)
• Design Dash - DE (PDF, PPT)
• Design Dash - CN (PDF, PPT)
• Facilitators Guide (PDF)

A “dash” means both a sprint (“a 100-meter dash”) and a small amount of something (“a dash of cayenne pepper”). The Design Dash is both. It’s a taster activity that still has some weight to it, and that can be deepened and expanded as your time and expertise allow. Reading through this activity and the accompanying facilitator’s guide is no substitute for taking a human-centered design course yourself! But if you have some background in the topic and you’re looking for a structured, ready-to-use activity, this is for you.

You can use it as-is, or you can hack it. You can use it alone, or you can use it to open another workshop or session. It’s meant to be open-source, extensible, and customizable. It expands or contracts to fill different time slots. And it’s free (as long as you credit us, and release any modifications under a Creative Commons license).

Why the Design Dash?

I created the Design Dash because I realized that the introductory design thinking exercises I was seeing – and, yes, leading – were not doing what I wanted them to do. When people asked “is design thinking also relevant to people who don’t design products,” or “how would I sell a product that just one person would ever buy,” or “is it also possible to do this in teams,” that meant the exercise hadn’t communicated the concepts I care about.

So I set out to design the intro activity I was missing.

Goals of the Design Dash

• People get used to externalizing ideas, through words, drawings, sketches, and prototypes.
• They experience how working quickly and making fast decisions in teams leads to surprise, creativity, fun, and a lot of output.
• They practice discovering and framing a challenge around human needs, only very slightly abstracted from a single person.
• They get caught up in learning about their own ideas, rather than defending them.

(“People go through a design thinking process” isn’t in here. Why not? Because that’s a crappy goal for an exercise. First, that framing is from your point of view, not theirs. Second, “design thinking” has become so buzzy that it often seems to mean nothing and everything. You really need to give serious thought to what exactly design thinking means to you, and why you care about others learning those things, before you go around facilitating activities.)

Other Design Principles I Care About

• The activity should be appropriate and understandable for many different people. That means people from different industries, different cultures, and different age and experience levels. An 8-year-old should be able to do this exercise with her grandfather. An engineer should be able to work comfortably with a dancer.
• The exercise should be adaptable to different time scales, and tolerant of different space arrangements. Sometimes you’re offered a 60-minute slot, sometimes you get three hours. Sometimes you get a conference room with a huge table in the middle, sometimes you get a converted warehouse space with no tables at all (hm, maybe that’s mostly a Berlin problem). Or, hey, maybe your space is outside under a big, shady tree.
• The setup should be cheap, easy, and undemanding, with no hard-to-find materials or extensive preparation. There is no “design thinking equipment.” The only things you really need here are A3 print-outs, square post-its, pens, and something, anything, to build with.

Things I Actually Don’t Care About

• I don’t care whether we “go through all the phases” of design thinking, using the “correct vocabulary.” There are so many different models of design thinking. I want the activity to focus on the underlying attitudes that all these models have in common.
• I don’t care whether everybody in the room has a standardized experience. Everyone’s experience will be different anyway, because of who they are and the background they come in with. In fact, if it’s a little different for everybody every time, the exercise becomes all the more repeatable and reusable.

For the Geeks: A Few Design Notes

Here’s how I thought through a couple of the new aspects of this exercise.

The Random Topic

I’ve been in a lot of meetings agonizing over what topic to use in a short activity. The stated goal is often to pick something “light” and “random.” Look, if you’re not trying to link the activity to some outside goal, don’t overthink the topic. Wallets, backpacks, gift-giving, moving to a new city, they all work just fine.

Let’s kill off this decision angst by inviting a huge swarm of topics into the room and forcing a blind choice. Since design thinking has problem-framing tools within it, what’s really important is the challenge you define during the exercise, not the topic you start with.

Okay, it’s not quite true that the topic doesn’t matter. Actually, I’ve had a run of bad luck lately with “redesign the wallet experience.” Of course I don’t say, or mean, “design a better wallet” – but still, that’s what 90% of people seem to hear. A show of prototypes at the end of this exercise reveals a lot of small, flat objects. A handful of folks will understand that this was never about wallets. They’ll build a restaurant where you pay with a retina scan, or a rolling memory exhibit inside a suitcase, or an alternative to a money-based economy. But these people are few and far between, and I don’t like relying on just a couple people to make one of my main points.

If you do want to link the Design Dash to an outside goal, or narrow the topic list so that it matches your event, go for it! For example, the topic list for a workshop about educational technology might include topics like “mobile phones in the classroom,” “teachers and new technology,” “school and social media,” “student/parent relationships,” etc.

The Problem Definition

Designers use an intimidating and delightful arsenal of methods to define a design problem. They collect their notes, look for themes, look for contradictions, describe personas, identify needs, and identify design insights. They work based on a combination of structured externalization and highly-trained gut sense. Frankly, this is where the true-blue process nerds really get their kicks. (Ahem.)

But remember, we are not teaching a room full of process nerds. We’re not interested in the best possible problem definition, because we aren’t introducing tools for evaluating “best.” We just want people to reflect on their interview, pick a problem, move on, and fix it later if needed.

So, first, we draw the person and nickname them. The sketch and the nickname make the interviewee just ever so slightly abstract, so it’s clear that we’re not really designing for just one person.

Next, we report something this person said they need. (They may have reported many needs, but we’ll pick the first ones that spring to our minds.) And finally, we make a guess at one possible need behind this need. (There may be many, but, again, we’ll pick the first.) That’s the end. We could have made this much more complicated, but we are choosing not to. The interviewee is still in the room, so we can check our work later.

Teamwork

Diverse teams are good at generating divergent solutions – a big part of what makes design thinking work. So any good introductory exercise should show how working in a team sparks surprises and produces unexpected results. For this reason, people are teamed up in groups of 3 to 4.

Why 3 to 4 people? Fewer, and the “interview” and “test” steps become one-on-one, putting a high burden on the tester or interviewer to filter and communicate their findings to the other team member afterwards. More, and you’ll run out of space for post-it notes in the A3 packets.

Putting people in teams also has a practical advantage in an intro setting: people can help each other along so you don’t have to. Some folks will always be slower to start than others, for whatever reason. Maybe they don’t understand the language used as well, maybe they’re shy, maybe they’re just a bit overwhelmed. If I see a participant with a blank paper and a blank expression, I’m going to have to gently tug this person along, like a tutor by the side of a frustrated student who’s fallen behind. This dynamic isn’t any fun for either of us. If they’re helped by a teammate instead of by a facilitator, they’ll all get more out of the experience.

Credits & Team

The Design Dash is not mine alone, but a collaboration between a bunch of us: me, Katharina Birg, Emma Callahan, Cheng Yao, Johanna Grefertz, Yani Guo, Deborah Kohn, Jana Mendelski, Laura Plemper, and Katrin Unger. They’re all students in the Winter 2018 Advanced course that I teach at the HPI School of Design Thinking in Potsdam, Germany.

For our first trial, I facilitated the exercise, and they were the “participants.” Afterwards, we reflected together and revised several steps. Then I stood aside while they facilitated it with over 70 visitors at our semi-annual Open House. We went through a few more rounds of revisions together during the following week and created the Facilitators Guide. It’s still a work in progress, and we’ll be revising and adding for a while yet. Additional thanks go out to Lisa Carlgren, Christian Smirnow, Louisa Löwenstein, Jonathan Edelman, and Steffi Gerken for their feedback and support.

Whoever you are, wherever you’re working, we hope our work is helpful to you! Use it, hack it, and enjoy – and let us know how it goes. 

Cross-posted to Medium.