I was reminded how good the Double Diamond is as a way for executives to think about their strategic investments in product development.
When a new strategic initiative is launched, user research and design is often first. Good design at the beginning helps build empathy and increase insight into people in a given product experience context. This research helps generate insight that is then used to make investment decisions:
- What does the research say I should do to impact customer satisfaction?
- Where does the research say I can create more business value?
How does Design Thinking help?
Design Thinking is the framework that underpins the Double Diamond. Its five phases, according to the Hasso-Plattner Institute of Design at Stanford, are as follows:
- Empathise – with the people who will use your product.
- Define – your users’ needs, their problem, and your insights.
- Ideate – by challenging assumptions and creating ideas for innovative solutions.
- Prototype – sometimes in low-res paper, or higher resolution wireframes, to demonstrate what the final solution could look like.
- Test – the prototype.
Overall, the framework assess the facts, analyses them, and asks designers to then apply an appropriate, good design pattern or practice, to then test. According to Stewart (Management 2.0, 2002) “here it is possible to work rationally toward a decision, but doing so requires refined judgment and expertise’.
But, product development is “complex”
Scrum, an agile framework, reminds us that product development is a complex endeavour. While we might engage in user research and use prototypes to predict how people will react to our products, we’ll never really know if a design truly meets a need until people actually use it in a real life situation.
The tendency of some executives is to initiate more design work upfront to give some comfort in the outcome. Unfortunately, the more we design upfront the longer we delay the delivery of value. The more we prototype the more time we spend eliciting feedback that is of lower quality than feedback on a working product. The more time (and money) we spend on this kind of testing the lower our return on investment.
There’s a balance to be struck. But where do we draw that line? How much should we invest in design and research upfront to inform good product development?
Cynefin has some of the answer.
Cynefin and Complexity Theory
Frameworks like Cynefin remind executives that making informed decisions requires an assessment of the context.
Simple environments allow us to collect requirements, design and deliver because the solution is obvious. Processes are used in simple environments because they always create the desired outcome.
Complicated environments enable us to plan the risk out of an unknown solution. In other words, by getting experts to assess the situation, analyse what is known, interpret the findings, and then decide on the best response using “good practice”. This is what Design Thinking is designed to do.
Some leaders rely too heavily on external experts in complicated situations, while dismissing or overlooking creative solutions from other people. To overcome this, I often advise leaders to assemble a group of people from a wide variety of backgrounds, including business stakeholders, and use facilitation techniques like Liberating Structures to ensure everyone has equal voice.
Complex contexts are typically unpredictable and unknown until you run an experiment. Rather than trying qualify the context through research first, conducting business experiments in these situations is the best course of action. Be aware of whether you’re running an experiment or a simulation – a simulation isn’t going to provide as reliable data as an experiment. A product executive’s job is to learn about how the real context responds to the experiment as part of the decision-making process about what to invest in.
Design Thinking is often treated like the proverbial hammer. Empathy in design is critical, as is good user research, but your choice of what initiatives to commission as a leader of product development should always depend on knowing what context you are in first.