Design thinking is taught as five tidy boxes in a row and practised as something considerably less tidy. That gap is where most of the scepticism comes from: teams run the workshop, fill the walls with sticky notes, produce a prototype, and six months later cannot point to anything the process left behind. The diagram was followed. Nothing durable was built.
The missing piece is usually the same one. The five steps are good at producing a solution to today’s problem. What they should also produce — and rarely do by accident — is a small set of experience principles: statements that keep deciding things long after the project team has moved on.
The short version
- The five steps are a vocabulary for what you are currently doing, not a schedule.
- Empathy is a research obligation, not a feeling. It is evidenced or it did not happen.
- Define is the step that decides whether everything after it is useful.
- Experience principles are the durable output. The prototype is the perishable one.
- A principle that nobody could reasonably argue against is not a principle.
- Going backwards is the process working, not the process failing.
The five steps, and the trap inside each
1. Empathise — gather evidence, not sentiment
Understand the people you are designing for in their actual context: what they are trying to achieve, what gets in the way, what they have already invented to cope, and the words they use for all of it. Interviews, observation, support logs, whatever gives you first-hand material.
The trap: empathy as an attitude rather than an activity. A team that “really cares about users” and has spoken to none of them has skipped this step while feeling it has completed it. Empathy without evidence is just confident imagination.
Must produce: raw material you can quote — observations, recordings, verbatim language — not a summary of your existing beliefs.2. Define — frame the problem you will actually solve
Turn a pile of observations into one framing sharp enough to generate ideas and narrow enough to reject them. A good problem statement is specific about the person, the goal and the obstacle, and it contains no solution.
The trap: framing so broad it permits anything. “Users want a better experience” generates infinite ideas and rules out none, which feels productive and is the opposite. If your framing cannot be wrong, it cannot be useful.
Must produce: a problem statement, and the first draft of your experience principles — because this is where the insight is still close to the evidence.3. Ideate — generate widely, then cut hard
Quantity first, deliberately including options you expect to reject, because the range is what makes the eventual choice meaningful. Then narrow fast, against the principles rather than against seniority or enthusiasm.
The trap: divergence without a selection mechanism. Forty ideas on a wall and no agreed basis for choosing means the loudest person decides, and the workshop was theatre. The principles exist precisely to make this step not a popularity contest.
Must produce: a shortlist with written reasons, including why the discarded options were discarded.4. Prototype — build the cheapest thing that can be wrong
The purpose is to make the idea testable, not to make it look finished. A paper sketch, a clickable flow, a fake back end, a role-played service — whatever is fastest to produce and sufficient to provoke a real reaction.
The trap: polish. A prototype that looks finished gets feedback on its styling and protects itself from criticism, because nobody wants to tell you to throw away something that clearly took a week.
Must produce: something specific enough that a person outside the team can try to use it and fail in an informative way.5. Test — look for the failure, not the approval
Put it in front of people whose behaviour you care about, give them a real task, and watch. The valuable outcome is the thing that did not work, and the reason it did not.
The trap: testing for validation. Asking “does this make sense?” gets a yes from almost everyone almost always. Give a task, stay quiet, and record what happens instead of what people say about what happens.
Must produce: a decision — iterate, re-frame, or stop — and a note of which principle, if any, this round has revised.Going backwards is the process working. A project that never loops has usually stopped asking.
So what is an experience principle?
A principle is a short, arguable statement that settles a recurring design trade-off in advance, so that dozens of future decisions do not have to be argued from scratch.
It is not a company value — “we are user-centred” decides nothing. It is not a guideline, which tells you how to execute something you have already decided. It is not a tagline. It sits between the insight you found in research and the thousand small choices that come afterwards, and its job is to carry the insight forward when the researcher is no longer in the room.
Four tests separate a real one from a slogan.
| Test | The question | Fails if |
|---|---|---|
| Arguable | Could a competent team reasonably hold the opposite view? | Nobody would ever disagree — “be intuitive”. |
| Grounded | Can you name the research that produced it? | It came from a workshop opinion, not an observation. |
| Decisive | Does it tell you what to give up? | It promises everything at once — fast and thorough and simple. |
| Actionable | Does it settle a decision on your desk this week? | You cannot name a single thing it would change. |
Draft one
Pick the context and the tension your research actually surfaced. The tool drafts the principle, names the decisions it settles, states what you are giving up — and shows the weak version that would have survived a workshop unchallenged.
Experience principle builder
Three inputs. The trade-off does most of the work; the context sharpens it.
Who is this for?
Which tension did your research surface?
How strong is the evidence?
Draft principle
Choose a context and a tension
Principles are written from a specific observation about specific people. Both inputs change the sentence.
Decisions this settles
- —
What you are giving up
—
0 of 3 chosen
Where principles come from
They emerge between Define and Ideate, and the moment matters. Too early and you are writing down assumptions; too late and the research has already been compressed into a summary and lost its edges.
The practical move is to look at your findings and ask, for each one: what would we have to always do, if this is true? Most findings produce nothing — they are facts, not forces. A few produce a sentence that makes you slightly uncomfortable, because it closes off an option somebody wanted. Those are the ones.
Keep three to five. Fewer than three and you have not actually resolved any tensions. More than five and nobody remembers them, which means they stop operating, which means you have a document rather than a principle.
A useful sanity check: write the opposite of each principle. If the opposite sounds obviously ridiculous, you have written a value, not a principle. If it sounds like something a reasonable competitor might genuinely choose, you have written a real one.
Making principles operate
Use them to reject things, out loud. The first time a design review says “that is a good idea, and it conflicts with principle two, so we are not doing it” is the moment the principles become real. Until a principle has cost you something, it is decoration.
Put them where decisions happen. In the design review template, at the top of the brief, in the ticket description. Not in a deck opened once at launch.
Revise them openly. Principles are conclusions drawn from evidence available at the time. When testing contradicts one, change it and say why. A principle silently abandoned teaches the team that none of them matter.
Date them and name an owner. Same as any other living artefact. Undated statements of belief accumulate until nobody knows which ones are current.
How design thinking goes wrong
| Failure | Looks like | Prevention |
|---|---|---|
| Workshop as substitute for research | Two days of sticky notes, no participants | No ideation session without first-hand evidence in the room. |
| Problem framed too broadly | Every idea qualifies | A framing specific enough to exclude things. |
| No selection criteria | The senior person picks | Score the shortlist against written principles. |
| Over-polished prototype | Feedback is all about styling | Build at the lowest fidelity that can still fail usefully. |
| Testing for approval | Everyone liked it | Assign tasks, stay silent, record behaviour not opinion. |
| Linear execution | Nobody ever revisits the framing | Treat a loop back as a planned outcome with time reserved for it. |
| No durable output | A prototype and nothing else | Leave three to five principles behind, owned and dated. |
What to actually do on Monday
You do not need a five-day workshop. Take a decision your team is currently arguing about. Spend two days talking to five people who have recently done the relevant thing. Write the one framing that argument keeps circling. Draft three principles from what you heard, including at least one that makes somebody uncomfortable. Then use them to settle the argument.
That is the whole method, compressed. The boxes are just names for the parts of it you are doing at any given moment — and the thing worth keeping afterwards is not the prototype you built, but the three sentences that will decide the next forty things nobody has thought of yet.
Until a principle has cost you something, it is decoration.
How we run this at Adi Design. Every project leaves behind three to five experience principles, drawn from named research, owned by the client team rather than by us. They outlive the engagement, and they are what makes the next decision cheaper. If you want that applied to a project, get in touch.
