The Stanford d.school (a.k.a. Stanford Design School, for the less pretentious) is well known for its “design thinking” methodology in problem-solving. For those who aren’t lucky enough to visit their campus, they’ve created a 90-minute, video-guided virtual crash course that brings participants through the 5 stages of their design thinking process. Last week, I conducted a session of the d.school’s virtual course for my colleagues in office.
Here are the 3 mistakes that I made (rephrased as tips) and 6 lessons that I learnt in that 1.5-hour-long session.
Wait, what’s this “design thinking” thing you’re talking about? Is it, like, edible or something?
But here’s what I think it is. It’s a specific approach to solving any given problem, with 2 factors that make it unique:
- It’s highly focused on the user. An integral part of this approach is getting feedback from your users about your prototype or product.
- It’s highly iterative. Another crucial aspect is the fact that you’ll tweak your product after getting user feedback, and get more feedback after tweaking, and then tweak your product again (and the cycle repeats).
Stanford’s Design Thinking Approach
Stanford Design School’s own set of design thinking approach consists of 5 stages:
- Empathise (a.k.a. understand your user and their problems)
- Define (a.k.a. define your user’s problem)
- Ideate (a.k.a. brainstorm as many ideas as possible)
- Prototype (erm, this one’s pretty obvious)
- Test (a.k.a. get feedback from your users, then tweak your prototype)
What happened in the 90-minute session
The crash course was a paired activity, so the 8 participants involved got into 4 pairs.
The main task of the course was to redesign the gift giving experience for your partner, by focusing on the last gift that he/she gave to someone else. To do so, each partner took turns to interview the other partner, build a problem statement for their pain points, develop multiple prototypes, get feedback from the partner, and then develop the prototypes further. We were basically brought through Stanford’s 5 stages of design thinking.
Time was short, but most of us felt that the pace was ok.
The 6 Key Lessons Learnt
#1: Talk to users before fully committing to any one solution.
This applies to almost any product that you’re working on. Talking to users about our ideas means that we get to know which work, and which don’t (for that user). It prevents us from wasting time and effort on something that eventually wouldn’t work anyway.
#2: You don’t hit the sweet spot on the first try (duh).
This is related to #1 above, but is worth mentioning as a separate point. There’s always something in your product that wouldn’t work quite as you’d expect. Because of that, iterating based on user feedback almost always results in better products (for that user, at least).
#3: Adopt a right frame of mind when showing an unfinished prototype to a user.
Some of us might feel squirmy about showing half-baked ideas to others. The key when doing it to potential users, is to focus on getting feedback and improving the product, and not think that you’re somehow being evaluated by your user.
#4: We are not our users, so don’t design for ourselves.
One thing stood out during the session: some of us had significantly different gift giving problems than our partners.
One could be concerned with giving gifts that really benefit the recipient, while the other might be concerned with giving affordable gifts that don’t look too cheap. This highlights the problem of designing a product based on what we think is important (i.e. without actual user feedback).
#5: Some users might not even know what their problems are.
Some of us didn’t really know what our own gift giving problems were, because we’re not used to thinking like that. We don’t often stop in our tracks and analyse the problems that we face day-to-day.
That’s why asking the right questions is crucial: we need to know the whys of our users’ problems. If an answer doesn’t quite make sense, probe deeper and get to the root problem or motivation.
#6: But it’s tempting to not ask why.
When users try to explain their decisions or problems, it’s easy to just take what they say and move on to ask them something else. For some of us, it takes conscious effort to probe deeper and find out why they did (or felt) what they did (or felt).
3 Tips on Conducting a Better Design Thinking Session
If you’re thinking of conducting your own session of Stanford’s design thinking crash course, here are some tips that’ll make your session (much) better than the one I conducted.
#1: Do the course yourself first (you’ll need a partner, of course).
Doing so has 2 important implications.
First, you’d get familiar with the course (and trust me, watching the video alone isn’t enough). That way, you’ll know which parts are potentially tricky (e.g. the interview portion, because some people won’t know how to ask the right questions), and you’ll then be able to provide prompts to better facilitate the session. You’ll also likely find some parts slightly irrelevant (like the prototyping stage, which many of us felt was redundant, because we just finished sketching our ideas on paper at that point), and can play them down in your session.
Second, doing the course prior to the session also means that you won’t be participating in it. In other words, you’ll be free to move around and facilitate the session, which is what you should really be doing.
#2: Don’t use Stanford’s video in your session.
I know, it’s tempting to just let the video do the job for you. But there are reasons why you should conduct the session yourself.
First, using the video makes the session feel that much lamer (it’s true, I relied on it and it felt like we’re just going through the motion). More importantly, giving instructions yourself allows you to make sure that everyone in the session clearly understands what they have to do, and are able to clarify things that they’re not certain about.
If you need a timer for the different stages in the session, Google has a great one (in fact, you can just google “timer” to get to it).
#3: Go through everyone’s problems and solutions at the end of the session.
Do it if your group is small enough (say, less than 10 pairs).
This not only increases the level of engagement in your participants (which is always good), but also allows them to share their biggest takeaways or stumbles during the session. On top of that, your participants are also likely curious about what other participants went through during the hour-and-a-half session. Going through a round of sharing also prevents the session from ending abruptly (which was what happened to mine).
And that’s all!
I hope you found this post useful! Let me know what your key lessons and mistakes were in the comments below, after you’ve conducted your own design thinking session!