Design Thinking in a Nutshell
This article is still being fleshed out and refined, feedback welcome.
A few years ago you’d hear “move fast and break things” up and down the halls of tech startups and the big companies trying to emulate them. I watched product folks, designers and engineers move fast. I watched them break things. A lot of times, they broke team morale along the way. Sometimes they lost the trust of their audience.
Trust is fragile, people.
Yes,our jobs are fun, we get to solve big problems. It’s exciting. Don’t let that excitement get the best of you. Slow down. If you only read two more lines of this article read these:
Don’t be the person who pitches solutions. Pitch problems to solve.
Do your homework. Do it with others. Don’t formally present the “shower ideas” you’ve developed alone.
Design Thinking is a framework that helps teams do 3 things:
1 Place researched human stories, big and small, at the center of strategy.
2 Align on identifying the real problem to solve before coming up with solutions.
3 Then, and only then, work iteratively toward designing the most powerful solutions.
Building trust with your peers and customers is a vague task so it helps to have these 3 “rails” to keep you on track practicing solid Design Thinking. Each of these rails has essential furnishing, which I’ll boil down in this article as well as adjacent articles.
Step one: looking at stories big and small.
To truly understand hard data, we need to authentically understand the human stories behind the numbers. It can be hard to see there is a missing story. Similar to the physical phenomena that happens when we look at an object and our brain fills in the space around it, we fill in the blanks around numbers without even acknowledging the blanks exist. We project our personal perspective, sometimes turning correlation into causation:
Data Signal: Parents of toddlers are buying pool noodles like crazy!
Fill in the blank: Toddlers love to swim! Let’s create a line of kid swimwear! Wow, we’re so in touch.[Pats self on back]
Qualitative research (observing real people) shows us: New parents put pool noodles under bedsheets to keep toddlers from rolling out of bed. It’s a hack for parents who don’t want to splurge on a crib.
In the “move fast and break things” playbook you rush to launch and iterate after the fact. You can run out and launch that line of baby swim trunks (adorbs!) and improve upon them after they’re on the market, but you’re just improving the solution to the less meaningful problem. When we rush to develop solutions based on a faulty premise, iteration only.. erm, polishes the turd.
When we skip or rush the discovery research phase we also miss out on the moment where we develop a common story rooted in simple human terms that cross-functional teams can speak confidently about.
Think about how much jargon you come across at work. Designers speak their own language. Engineers speak their own language. Sales, Legal, Product.. everyone has their own wheelhouse and accompanying language. When we come together speaking different languages you’ll see a lot of confident head nodding. No one wants to show their hand and scream: speak human please!!
The great thing about qualitative research is that it’s about people and we all speak “people”.
Getting authentic human stories at the center of your strategic narrative creates a touchstone for alignment, which is the first step in working together to identify the right problem to solve.
The first steps made are the most important ones, so start with strong Discovery Research.
Use signals from data to frame a qualitative study.
Read about framing user research with data here.
NEXT: Define a “people- centered” challenge.
DISCOVERY STEP 2: Observe people in a strong qualitative study.
The depth of your challenge will determine the depth of your Discovery research.
- DEEP DIVE: observe people in a specific context in order to develop a deeper shared understanding of their experience and identify opportunities to make your product and it’s messaging stronger. This is not an area to rush or skimp. This is where you pull out the big ux guns: ethnographic research. Just a fancy way of saying: observe people on their own turf, spend a lot of time there and get their stories. Not getting what you need from a standard interview? You may need to develop “show not tell” interview strategies. More on this later.
- MEDIUM DEPTH, i.e. understand motivation and intent. You’ve already done the deep dive research and built some features or messaging that sticks. Perhaps you need to prioritize your feature roadmap and you still need to understand: what motivates people in this space when it comes to this bit here? What detracts them? Where do they lean in or get hung up? You need to speak with them in a live conversation — maybe more than one over a period of time (aka diary study). Remote video interviews are great because you get face to face time and can speak with a handful of people from all over the country — or globe — in a day.
- QUICK & DIRTY: guerrilla research. You and your team know your space really well. You have some light questions to clear up some confusion. Guerrilla research can be as easy as going down to the mall, street corner or the cafeteria and getting quick snapshots of people’s experiences to add to your picture of what’s going on in a space. Some people get excited by the idea of doing guerrilla research and feel like it’s all you need. It’s not that their lazy, it’s just that their in a reactive mode rather than a proactive one. Reacting to tight deadlines, an engineering pipeline that needs to be constantly filled, etc. But being reactive is no substitute for being proactive. When it comes to research & design remember: garbage in, garbage out. So, can guerrilla research replace deeper research? Nope. It’s just a supplement.
All of the above is “Generative” research that informs ideation.
A great researcher will make this look easy peasy. It’s just talking to people, right? Don’t be fooled. People research is a craft that requires skill to extract actionable insights that are not biased by the study.
For newbies starting out in generative research, you can read some tips here:
- Develop a learning agenda that will lead to actionable insights.
- Develop an interview guide that’s not leading but effective.
- Staying safe, but reasonably uncomfortable, on in-home research.
The struggle: generative vs evaluative research.
Naturally, most people want to skip the generative step and go straight to evaluating ideas.
Let’s just put it out into the world and we’ll optimize from there!
Fair enough, and in some circumstances that’s fine. But if you chose the wrong problem to solve — as with the pool parent example above — optimizing will only help you solve the wrong problem better.
Er, more polite way to say it:
You’ll reach a local maximum, probably not a global one.
Let’s assume you’ve done your research. You had some great learning moments. You’re wheels are turning. How do you get everyone’s wheels’ turning?
First: observations →insights
An insight is just an observation hammered into a more powerful statement.
Start by determining top observations from your generative study.
Cognitive bias is real so make sure you have a note taking framework to ensure you’re being evenhanded about what happened in user interviews across the board. The 4th image here shows a notes matrix I often create to help keep a bird’s eye view on things.
When everyone who joined the research has had a chance to contribute notes to the matrix, you’ll be ready to host a workshop where you can reflect on the top observations and — as a group — transform them into insights.
Silent voting is a popular way to narrow in on your top observations. If you’re going the post-it and sharpie route give people stickers or marker and ask them to quietly vote on the 3 observations they find most interesting / sticky / or important. If your team uses Slack, you can also post your top observations there and ask people to upvote the top 3.
Agree on the top 1–3 observations gained.. next “uplevel” those observations into insights.
Here’s IDEO’s definition of a great insight that I sometimes use in design thinking workshops:
Don’t be surprised if you ask people to write insights and they write solutions.
- Test a concept
- Test a prototype
- Optimize a product that mostly works. You’re product already exists and works well overall, but there are some areas where it could be better. Just observe people using your product. Ask non-leading questions to dig into motives and generate some insights. This could easily be an unmoderated study with a tool like UserTesting or DScout — you’ll have findings back in less than a day! (Isn’t this just evaluative research? Basically. Depending on where you are in the product development process this may be an appropriate place to start. When in doubt: go deep.)ENDING PENDING :) JULY 2018