Faced with a problem shrouded in unknowns, the root cause is often complicated and the solution unclear. These so called ‘wicked problems’ can benefit from a healthy dose of design thinking. But what is design thinking and how can you use it to solve problems?
If you are reading this article then you’ve probably already read Why is solving complex problems so complicated? If you haven’t then I suggest you read that first.
What is design thinking?
Design thinking is something you likely already do.
- We have an outcome defined as an objective (rather than a clear problem).
- We use that objective to generate and validate solutions.
- We do this until we deliver something that we are happy meets our success criteria.
The impact of changes made should be measured. What we learn with each cycle should then inform the next step.
A real-life case study for design thinking
A great example of the use of design thinking can be found in the following 99% Invisible Podcast. This episode explores the Finnish government experimenting and developing Universal Basic Income (UBI) policy using design thinking principles.
In fact, if you don’t already listen to it I’d recommend exploring the 99% Invisible back catalog to find explore such topics as:
- How data has reduced the death rate in cars by 80% in the US?
- What do we really know about how Dinosaurs looked?
- How pockets perpetuate gender inequality?
But I digress…
People solve problems, not processes
You don’t have to be a designer or have an artistic streak to use design thinking. Anyone can design solutions. And the best people to do it is … everyone.
When looking for solutions that aren’t immediately apparent.
- Start with the people experiencing the problem.
- Talk to them.
- Observe them.
- Immerse ourselves in their experience.
- Develop a theory through that immersion.
Genchi Genbutsu
This Japanese term loosely translates to ‘go and see’. Essentially, it means to go to the actual spot where actual work is happening on the actual product to confirm your conclusions.
A mistake we make too often is to base our decisions or understanding on second or third hand information. You know what they say about assumptions…
What do we learn from people building towers with spaghetti?
I highly recommend watching the following TED talk. Build a tower, build a team, Tom Wujec, TED
TL;DR
We have a tendency to spend time planning and trying to create a detailed and fool-proof master place that we can then flawlessly execute. We then set about actioning it only to discover some flaws in our understanding right at the end.
In this case of the video above, most teams create plans based on big assumptions and grand ambitions.
- We know very little about the tensile strength of a piece of dry spaghetti.
- We have no practical experience with how well it will support the weight of a marshmallow.
- We only gain this information late in the build (when it’s too late to recover from a collapse).
Young children frequently outperform adults. They do this because they build through experimentation rather than to a plan.
The objective isn’t elegance. It’s to make a tower that actually supports the marshmallow. Not to be ambitious, build something that nearly works, then watch it collapse at the last moment.
Experiment early, fail fast (the usual Agile clichés)
A better alternative is to validate and test our assumptions early. Invest time and effort into experimentation, not just the usual delivery costs. By doing this we replace assumptions with practical knowledge (in a way that we hope will be more cost-effective than last minute failure).
A Minimum Viable Product (MVP) should not solve all the problems up front. That would make it a final product. Instead it’s purpose is to inform the final design as cheaply as possible.
Nature is filled with iteration and evolution. No good idea ever emerges in a perfect and fully-formed state.
Exploring neigbourhoods
In his biography of Pixar, Creativity, Inc, Ed Catmull discusses the importance of allowing teams and individuals to ‘explore neighbourhoods’ as part of a creative process.
It isn’t enough to pick a path—you must go down it. By doing so, you see things you couldn’t possibly see when you started out; you may not like what you see, some of it may be confusing, but at least you will have, as we like to say, “explored the neighborhood.”
The key point here is that even if you decide you’re in the wrong place, there is still time to head toward the right place. And all the thinking you’ve done that led you down that alley was not wasted. Even if most of what you’ve seen doesn’t fit your needs, you inevitably take away ideas that will prove useful.
Relatedly, if there are parts of the neighborhood you like but that don’t seem helpful in the quest you’re on, you will remember those parts and possibly use them later.
— Ed Catmull
Exploration vs. Exploitation
In his TED talk 3 ways to make better decisions Tom Griffiths discusses the Explore-Exploit trade-off (roughly 3 mins in).
When faced with a decision such as what to have for dinner we have two options:
- Exploit: The safe option. Use the knowledge we have an pick somewhere we know well.
- Explore: The riskier option. Try something new and expand our knowledge for the future.
If we are overly risk averse we won’t explore new ground. That means we are likely to become increasingly predictable and repetitive – due to having a limited data set. There is therefore a growing risk inherent in taking the safe option each time.
The key is to find a balance. To benefit from the experimentation we’ve already done we need to exploit it. But to gain it we need to explore in the first place.
A structured approach to design thinking
Tackling problems requires that we start by defining and objective or outcome.
- What is the problem you are trying to solve?
- How can you or would you measure success?
- What is the definition of done?
Specifications Assumptions
Write down the word Specifications. Then cross it out and replace it with the word Assumptions.
Under this heading we write down what we ‘know’.
Until we’ve explored and conducted our initial research:
- Everything we think we know is an assumption.
- Everything we know we don’t know is an unknown.
User interviews and workshops
Get the people in the know to validate our assumptions. They will quickly highlight gaps in our knowledge and flesh-out our understanding.
Keep your questions and mind open
It’s important to avoid asking leading questions. Instead try to give space to let others lead you to the answers.
If they dry up or struggle, then a gentle nudge can be used. The aim is to avoid planting your own ideas and by doing so disrupting them from exploring the topic themselves.
Examples of open questions:
- What does a typical day look like? A day in the life
- What do you do? Process and dependencies
- Talk me through your process?
- What are you inputs and outputs?
- What do you need to start work?
- What does ‘done’ mean to you?
- Which teams are upstream or downstream of you?
- Who do you rely on to do your work?
- Who relies on you to do their work?
- Where is your time or effort spent? Efficiencies
- How much of your time do you spend …
- In meetings?
- Writing emails?
- Developing?
- …
- How much of your time do you spend …
- What does good look like? Quality
- How do you know your work is good?
- How do you measure quality?
- What are the gaps? Fresh perspective
- Is there another way
- Can we make it easier?
- Can it be done more effectively or efficiently?
Wrapping up
Once you have ideas rated and broken down into measurable steps you can turn them into actions. Be sure to schedule when you’ll regroup to measure and reassess the impact. Make any changes systematically until you meet your success criteria.