Running the Perfect Design Thinking Workshop: 15 Best Practices
There are many reasons for running a Design Thinking (DT) workshop — solving a complex problem in creative ways, creating organizational change, growing a business, educating folks about DT methods and mindset, or even planning your family’s next big move in life.
You might be running a DT workshop for colleagues, clients, students, or even family members. Doesn’t matter. A good DT workshop generates fresh insights, instills creative confidence in partners, and produces tangible innovative solutions while a bad one can forever damage people’s trust in DT as an effective method and mindset for innovation, or worse, make them abandon faith in solving difficult problems.
I have done many DT workshops in my career. Some conducted under 4 hours and some curated over the course of 4 months. Most of them follow the famous format (Empathy, Define, Ideate, Prototype, Test) and are done in teams of 4–6 people. And all the good ones have certain qualities in common — here I listed 15:
Early in the process: DT has its own culture, but so does the room. And guess what, dysfunctional team dynamics can overpower DT culture. You play a key role in shaping healthy team dynamics. But you can’t do that without good intel. So early in the workshop, activate your inner interviewer and get to know people in the room —give them space to share beyond their credentials and observe their body language as they interact with each other. Use this intel to nudge the team dynamics towards DT dynamics.
During the entire process: Be a good ethnographer and take written (not mental) notes about the team dynamics: likes, wishes, wonders, pick any format you want. Take a few minutes at the end of each phase to share your observations with them. When they’re doing things right, you must let them know — it’ll encourage them to do more of that. If they’re doing something wrong, pose it as a question, and ask them how we might address it as a team.
Also during the entire process: At times, team members interact contestably — they disagree and challenge each other. It’s only natural. Define is perhaps the most fertile phase for conflict — disagreements could even happen during rainbow and confetti phases like Ideate. In my field, architecture, we acknowledge and celebrate this in the form of “crit” — it’s key to our practice and primary form of operationalizing critical and creative thinking. But no one in architecture takes “crit” personally. Why? Because everybody knows it’s staged; it’s a form of improv carefully crafted at the moment to elevate the idea to the next level. Explain to your team members to craft their “crit” for the purpose of elevating the conversation rather than stroking their inner devil advocate. For those who are at its receiving end, encourage them to use “reframing” techniques to “overcome the block”. In any case, it must not be delivered and received as personal criticism. So row your boat above the crit, don’t swim in it.
During the Empathy phase: Your participants might already know a lot about the topic of design — this could create bias during the fieldwork. Before sending them to the field, ask them to do “assumption-storming” and create a list. The list includes all the things they expect to hear during the interview. Let them know that this is, in fact, the list of your biases. So they should be aware of them as they interview folks and should be open and ready to hear the opposite of their assumption.
During Define phase: Often participants are knowledgeable and experienced people. Unfortunately, this knowledge and experience can get in their way of adopting a curious mindset and developing good POVs and fresh insights. It might be difficult for them to unlearn what they already know, but you can help them temporarily block the all-knowing part of their brain through “jargon disarm”! For example, as they get into the Define phase, encourage them to not use technical terms and phrases in their field for an entire 15 minutes!
Also during Define: Participants are synthesizing their interviews and observations on post-its. They write certain keywords or phrases in abbreviated form on each post-it that look like these: “gamifying learning”, “reflection in groups”, “storytelling” … WRONG! Keywords and abbreviations omit context and transform unexpected discoveries into bland generalizations. Encourage them to use complete sentences or statements with at least one verb on each post-it.
One more thing about the Define phase: Teams have arranged all of their data points from the interviews and observations on the whiteboard. There are many post-its of different colors some in clusters and some just floating by themselves. Now they’re asking themselves, where should we start our “inference” from? Give them criteria for picking the most generative post-its from which they can start their abductive phase: Post-its that confirm each other across interviews; post-its that contradict each other across interviews; post-its that challenge one or some of your assumptions; post-its that include or express an emotion, etc.
One last thing about the Define phase: The team might ask you, “Are we solving this problem for this particular interviewee?”. You could let them know that the better question is, “Is this problem worth solving?”. If the answer is yes, then it doesn’t matter that it has stemmed from only one interview.
During the Ideation phase: If you’re choosing good old post-it brainstorming as a form of ideation (yes, brainstorming is only one form of ideation!), then give your participants some time to do individual brainstorming first. Not everyone is wired to think on their feet. Encourage people to go for quantity and enjoy watching them generate post-its in silence. After this, they can move to group brainstorming where each person shares their idea in their group while others “Yes, and …” it.
During the Idea Selection phase: Is this idea disruptive? Is it going to make your users’ eyes shine? Are you going to pull an all-nighter to make it happen? If the post-it checks all of these three boxes, then it qualifies to move to the Prototype phase.
Also during the Idea Selection phase: Push participants to avoid “feature-creep”. This means “less is more” — don’t squeeze too many things into one idea. However, sometimes, there are a few post-its on the board that call into each other. The gravitational force between them is strong and them merging into each other is only natural. At this point, encourage them to think of those few post-its as metals that need to be mixed to become an alloy, not additional tools that are being added to an existing swiss army knife.
During the Prototype phase: They look at their top post-it. It’s big and cool, and it’s vague. There are so many plot holes. So many unanswered questions, and even more unasked questions. Make it clear that they don’t need to map their entire idea in order to be able to prototype it. Because they’re not prototyping “the idea”, their prototyping “a moment in the life of the idea”. A prototype is not the smaller version of their original idea, but an experiment to answer certain curiosities and test certain hypotheses about the original idea. It might also help to think about the prototype as a plot in a movie. They don’t need to know everything about the entire movie, all they need to know is the plot and how it relates to the movie.
Also during the Prototype phase: Their first reaction is to start a conversation around their table. Encourage them to push the table to the side and replace it with random making-stuff. Tell them sometimes the stuff, or rather what we see in the stuff, is what shapes the plot.
One more thing about Prototype phase: Encourage teams to build multiple prototypes each exploring one curiosity. These prototypes will turn out to look very different from each other.
During the Test phase: It’s natural for participants to feel awkward to show half-baked prototypes to potential end-users — people don’t want to be judged based on incomplete work, and prototypes are indeed incomplete work. This requires a level of vulnerability that many people, especially the perfectionist type, might not have. Suggest for them to start their testing session with the end-user with something like: “I want to share three ideas/prototypes with you, and hey, none of them will work!” This way, they’d let the audience know that the goal is to run some ideas by them not to make an impression. Then they can add “… but each of these prototypes offers something that in conjunction with the other one could lead to a better solution.”