Design Thinking Process

You come back from research with sixty observations, forty quotes and a great deal of enthusiasm. This is the moment most teams quietly fail, because the obvious next step — summarise it — produces something no one can act on.

Define is the mode that turns raw material into a single sentence sharp enough to build against. The output is a point of view: a specific user, a specific need, and an insight about why the need exists.

The discipline is in the narrowing. Sixty observations should collapse to one or two of these, not fifteen, and the collapse is uncomfortable because you have to leave things out. A team that keeps everything ends up with a point of view like “users want the product to be easier”, which is true, unarguable, and useless.

The test is whether the sentence can reject anything. That is a define statement doing its job — a point of view that rules nothing out has not defined anything.

Ideate is the mode everyone thinks they understand and most teams run badly, because it looks like a meeting where people say ideas and it is actually a discipline with one hard rule.

The rule: generating and judging must not happen at the same time. The moment evaluation enters the room, people stop offering the ideas most worth having — the odd ones, the half-formed ones, the ones that sound stupid until someone builds on them. And those are precisely the ideas that a competitor has not already had.

This is why the format matters more than the creativity of the people involved. Ask for quantity, explicitly — thirty ideas, not five good ones. Defer all judgement to a later, separate session. Build on other people’s ideas rather than competing with them. And write silently before anyone speaks, because otherwise the first idea offered anchors the next thirty minutes, and the first idea is usually the most senior person’s.

One team produced almost nothing for half an hour, switched to silent card-writing, and filled a board in four minutes. Nothing about the people changed. Divergence is a social problem far more often than a creative one.

Wild ideas earn their place here, and not for the reason people usually give. It is not that the wild idea gets built — it rarely does. It is that a wild idea moves the boundary of what the group considers thinkable, and the idea that eventually ships is often a tamed version of something that arrived sounding impossible.

A prototype is not an early version of the product. That misunderstanding is expensive, because it leads teams to build something half-real, which takes weeks and is then too costly to throw away.

A prototype is a question made touchable. Its only job is to make one uncertainty testable as cheaply as possible, and it should be built with the expectation of throwing it away — that is the point, not a compromise.

The right fidelity is the lowest one that can answer your question. A paper sketch answers “is this the right structure?” A clickable mockup answers “can people find the button?” A role-play with a person pretending to be the system answers “does this service flow make sense?” None of those need code, and code would make all of them slower to change.

That is really the whole argument. Cheap prototypes get killed; expensive ones get defended. If your prototype is costly enough that abandoning it feels like a loss, it has stopped being a prototype and started being the product.

Testing sounds like the end of the process — the bit where you confirm the work was good. Treating it that way is the single most common way design thinking gets watered down into a nicer waterfall.

Test is not a verdict. It is the mode that generates the next round of empathy. You put the prototype in front of real people, watch where they hesitate, and what you learn is new understanding of the user — which sends you back round the loop, usually to define or ideate, sometimes all the way to the beginning.

How to run one, briefly: give people a realistic task rather than a tour, then be quiet. Watch what they do before listening to what they say. Ask “what were you expecting to happen?” rather than “was that confusing?” — the first measures the product, the second measures how agreeable your participant is.

The loop closes here and immediately reopens, which is why the diagram is drawn as a ring. The question at the end of a test is never “did it pass?” — it is “what do we now know that we did not this morning?”