Lean Design Thinking
Where product, design, and development converge
It’s been about two years now since we’ve used the popular design thinking approach in validating and building paths to the outcomes we try and help our customers achieve. We practice dual track agile(more on this later), so it only seems fitting that we apply design thinking and lean techniques to validate the most important thing for us to build and ship next.
Like many teams, we really don’t like to build products people don’t use; this is a colossal waste of time. We’ve been there, and so have many others. It’s not fun.
I’d love to share with you how one team has brought together and has applied both Lean and Design Thinking to make (or try to at least) qualitative and quantitative driven decisions.
Identify and Understand the Problem
What problem are you trying to solve and who are the people involved?
Here is where you’ll need to figure out what problem you want to tackle (feature, process, epic, product,etc.):
Get out there and talk to people. Set up customer calls, visits, team interviews, whichever flavor floats your boat. The point here is to simply begin to understand who these people are and what their struggles are. Don’t over think this step.
A simple way to start these interviews is to have some basic questions ready and well drafted. For example,
- Tell us about your roll and responsibilities?
- What does a typical day look like?
- What are some frustrations that you have?
- What are you currently doing now to solve these problems?
These are just a few example questions to get things going. You’ll be able to dig in and ask clarifying questions. Please, avoid leading questions. :) Make sure you have someone recording these sessions, jotting down notes, so that you have take-aways and can synthesize this information later.
Initial Outcome Stories
Simple, light, broad stories to help build a narrative.
Based on your discovery and exploration of the problem, use the learnings to inform some very high level outcome stories to help drive the next steps. We found, over time, that having these basic sketched-out stories help support the problem and help the team begin to identify a possible solution. Think of these stories as “assumption stories” since there are still many unknowns.
More on personas here, if you’re wondering.
Ideation
Diverge, Emerge, and Converge as a team to design a solution to the problem.
Gather all of your research findings, outcome stories, customer/user quotes and present them to the team to understand the problem. Then present a question: “How can we solve this problem?”
At this point, everyone designs. In the picture above, there are developers, designers, and even testers designing. We get together and explore all the different solutions that we could create to help our end users reach their outcomes. Here are some exercises we’ve used in the past.
Design Studio
-Gamestorming (Several types of games and activities to achieve an outcome.)
-Empathy map
-Story Mapping
Experiment and find one that works best for your team and the problem you’re trying to solve.
Hypothesis and Iteration
Draft hypothesis based on your designs and test.
Here is where “lean” comes into play. We still struggle to get this part right, and that’s ok. Others do too in similar situations. Some teams begin with a hypothesis and design from there. We found that creating hypothesis based on our designs is a bit easier. We feel less restricted to a statement and feel free to explore. Here are some layouts and approaches we’ve taken and learned from.
- Draft your hypothesis based on ideas and designs that came out of the ideation phase.
2. Design experiments and identify risks.
Some of this is inspired by invisionsapps experimentation grid.
3. Create prototypes to experiment and test your hypothesis and risks. This is where lean comes in. What is the quickest and cheapest way you can learn? Paper prototypes, mock-ups, or invisionapp/axure prototypes are options to help continue the conversation and validate your hypothesis.
4. Get back in front of your users/customers. Observe their behvaviors and reactions to the prototypes. (Bonus: Jot down what you want to learn as a team before going into these sessions. This helped us be intentional about what to ask and have somewhat of a structured conversation.)
Rinse and repeat these steps until you’ve validated and identified your minimum viable product (MVP) and feel comfortable enough iterating in the software itself.
Bonus! Some prototyping tools to get you started:
- Pen and paper (so cheap and easy)
- Invision app (we use this quite a bit)
- Pixate (Want to find an excuse to use it)
- Proto.io
- Framer
- Flinto
Decompose and ship
Once you have validated your hypothesis and tests, it’s time to decompose your findings into more concrete user stories. These stories will have acceptance criteria and resources, such as validated mockups and prototypes to support what will actually be built. These are the stories that you can estimate and add into the validated backlog. Bring on the agile and continue to iterate after you release.
Take-aways
It’s just one approach to make things people actually want to use. There are some great posts that are floating around beginning to question Design Thinking’s capacity to solve the entire problem. We need to apply the same questions that we use to build great products as we do to the approaches that help us arrive to these solutions. Is this working? What have we learned? How can we improve it? If we don’t continue to inspect and adapt, we’re doing it wrong. I don’t think Design Thinking is the silver bullet to innovation. If others are doing this, or something similar, how will we yield “innovative” results? For now, at least, I think it helps us be intentional about asking the right questions, gives us opportunity to understand who we’re solving problems for, and allows us to remove arrogance from the equation and experiment with different designs to a solution.
