Design Thinking

Design thinking is a way of approaching problems that borrows from how designers work: start with people, explore many options, make things to learn, and test them. It was shaped by researchers such as Herbert Simon, who described design as changing existing situations into preferred ones, and popularised through IDEO, the Stanford d.school and books such as Tim Brown's Change by Design.

At its core it is not a magic ritual. It does not guarantee innovation, and it is not the same as running a workshop with sticky notes. It is a set of habits: understanding the people involved, framing the problem before solving it, generating alternatives, and learning from early versions.

Different organisations draw it as different diagrams, with three, five or more stages. The labels vary, such as empathise, define, ideate, prototype and test, but the movement is the same: understand, then explore, then make, then learn, with frequent loops back.

Treat the stages as a map, not a script. Real projects jump backward, run stages in parallel and stall. A designer's job is to know which kind of activity the project needs next, not to march through a diagram in order.

The Double Diamond is a model published by the UK Design Council in 2005. It describes design as two diamonds. The first diamond is about the problem: explore widely, then narrow to a clear definition. The second is about the solution: explore many possibilities, then narrow to something that works.

The four phases are commonly called Discover, Define, Develop and Deliver. Discover is divergent and open, collecting insight about people and context. Define converges on a clear brief. Develop diverges again to try different solutions. Deliver converges on the one that is tested and released.

The diamond shape is the point. In each diamond you first widen the field and then narrow it. Many teams skip the first diamond and start in the second, designing solutions to an unexamined problem. Others never narrow, and stay in endless exploration.

Use the model to ask where you are. If you are generating ideas without a clear problem statement, you are in the second diamond too early. If you have a clear problem but have only one solution, you have not yet diverged enough.

Empathy in design is not a feeling. It is a practice of research that reveals what people do, need and struggle with, including things they cannot easily say. People are often poor at predicting or explaining their own behaviour, so what they say and what they do can differ.

A basic toolkit includes interviews, observation and contextual enquiry, diary studies, surveys and analysis of existing data. Interviews reveal reasons and stories. Observation reveals actual behaviour and workarounds. Surveys give breadth but little depth. Use methods in combination.

Good interviewing is a skill. Ask open questions, follow with why and how, and ask for stories about the last time something happened rather than hypothetical futures. Avoid leading questions and avoid pitching your idea, which turns people polite and unhelpful.

Record and share what you learn in a form others can use, such as quotes, observations and patterns, then look for needs rather than solutions. A user saying they want a faster horse is describing a need for speed, and your job is to find it.

The Define stage turns raw research into a clear, actionable statement of what to solve. It is where a great deal of project outcome is decided. A weak or vague problem statement leads to a weak or vague solution, however good the later craft.

A useful statement names a person or group, their need and the reason it matters, without prescribing the solution. For example, busy parents need a way to know their child's school schedule at a glance because missed events cause stress. It points to a need and invites many solutions.

To get there, cluster research notes to find patterns, then look for tensions and contradictions. Personas, journey maps and affinity diagrams are common tools. Their value lies in the thinking they force, not in the artefact itself.

Check the statement by asking if different solutions are possible. If only one is conceivable, the statement has smuggled in an answer. If a thousand are possible and none is better, it is too vague. Write several versions and compare.

Ideation is a structured divergence, not free association. The aim is to produce a wide range of options before judging them, because early judgement kills strange ideas that might lead somewhere useful.

Useful techniques include timed sketching with a quantity target, constraint based prompts, analogies from other fields, worst idea exercises that are then inverted, and structured variation such as SCAMPER. Each gives the group something to push against rather than a blank page.

Separate generating from evaluating. Set a time, collect everything, and only afterwards cluster and select. Mixing the two makes people self censor and drives sessions toward safe and familiar answers.

Quantity is a means, not an end. After a wide spread, look for ideas that combine, challenge assumptions or reveal a new direction. The best outcome of ideation is often a changed understanding of the problem rather than a single brilliant idea.

A prototype is a question made visible. Its job is to answer something specific as cheaply as possible, such as whether people understand a flow, whether a shape fits a hand or whether a service step makes sense.

Match fidelity to the question. A paper sketch can test structure and sequence. A clickable mock up can test navigation and wording. A working model can test performance and feel. Higher fidelity costs more and can anchor feedback on surface details such as colour instead of the concept.

Prototype anything, not only screens. Services can be prototyped with role play and storyboards, spaces with cardboard and tape, and products with foam and clay. The goal is to put something in front of people so they can react to it.

Be willing to throw prototypes away. They are tools for learning, not early versions of the final thing. Teams that become attached to a prototype stop learning from it.

Testing is for finding out where the design is wrong, early and cheaply, not for confirming that it is right. Teams that seek validation tend to ask leading questions and hear what they hoped for.

A small test can be very informative. Observing five people on a defined task commonly reveals most of the main usability problems in an interface, a pattern described by Jakob Nielsen. Test more than once, with a small group each round, rather than once with a large group.

Give participants tasks and watch what they do. Ask them to think aloud and resist the urge to explain or help. Silence is data. Note where people hesitate, backtrack or misread, and rate problems by severity and frequency.

Testing results should change something. Capture findings, decide what to change, and test again. If a test never changes the design, it was probably theatre.

Design thinking has been criticised, and a mature practitioner should know the arguments. One critique is that it becomes a corporate ritual of sticky notes and workshops that produces the feel of innovation without the substance. Another is that a simple process diagram understates how messy and skilled real design is.

Don Norman has called it a useful myth, and designer Natasha Jen criticised it in a widely seen 2017 talk for lacking critique and craft. Lucy Kimbell and others have argued for treating it as a set of situated practices instead of a universal method.

The deeper problem concerns wicked problems, a term from Horst Rittel and Melvin Webber, where the problem itself is contested and changes as you work on it. A linear process can mislead in those cases, since there is no clean point at which the problem is defined.

The useful response is not to discard the approach, but to use it with care. Combine it with research rigour, domain expertise and craft, and be honest about what it can and cannot do. Judge it by outcomes for the people affected.