Adi - User Center Designer

Future of Design

Design Thinking & Human-Centered Design

Five Design Thinking Steps Reframed for Real-World UX Impact

Empathise becomes Expose. Define becomes Choose. Five verb swaps that turn activities into decisions, plus a diagnostic for the step you’re stuck on.

Five design thinking steps for UX impact

Adi Design · Practice notes · 12 minute read

Design thinking has a strange reputation. Practitioners roll their eyes at it, and the same practitioners do a version of it every week. The method is not the problem. The problem is that the five steps are taught as activities, and activities are easy to perform without producing anything — you can run a full cycle, fill four boards with notes, leave everyone energised, and change no decision whatsoever.

The reframe below swaps the verb on each step. Each original word describes something you do. Each replacement describes something that has to change as a result. That one substitution is most of the difference between a workshop and an outcome.

The classical five
Each word names an activity. Activities can be performed completely and correctly without anything downstream changing, which is why the method gets a bad name among people who have sat through it.

The short version

  • Swap each step’s verb from something you do to something that must change.
  • Empathy is not built in a workshop. It is built by hours of exposure, and the team needs them, not just you.
  • Defining a problem is an act of exclusion. If nothing was excluded, nothing was defined.
  • Idea volume is rarely the bottleneck. Deciding is. Constrain deliberately rather than diverging by habit.
  • Prototype the riskiest assumption, not the concept. Fidelity should match the risk being tested.
  • Write down what each possible result will cause before you test. Otherwise the result gets interpreted to fit the plan.

Why it stalls in real conditions

Before the reframes, it is worth naming the structural reason this method underperforms, because no amount of better facilitation fixes it.

The person running the process usually does not own the decision. A designer or a facilitator convenes the workshop, produces the insight, builds the prototype — and then hands it to someone who was not in the room and is measured on something else. Design thinking is written as though the practitioner has authority. Most practitioners have influence, which is a different instrument and requires different tactics.

Everything below assumes you are working with influence rather than authority, because that is the common case. It is also why each reframe attaches to a decision rather than to a deliverable — a deliverable can be received politely and shelved, whereas a decision has to be made by someone.

Design thinking is written as though the practitioner has authority. Most have influence. That single mismatch explains most of the disappointment.

The five reframes

Empathise → Expose

Stop building empathy. Start accumulating exposure hours.

Empathy is not a state you reach in a two-hour session with sticky notes, and it does not transfer through a persona document. What actually changes how people build things is time spent watching real users struggle — and crucially, that time has to be spent by the people making decisions, not summarised for them by you.

A persona read by an engineer changes very little. An engineer watching three people fail at the flow they wrote last month changes a great deal, and the change persists for months. The unit to manage is therefore not a research phase but exposure hours per person per quarter, tracked honestly.

The move: stop presenting findings and start arranging attendance. Two colleagues on one session beats a deck seen by twelve.
Define → Choose

A problem statement is not discovered. It is chosen, and the choice has a cost.

Teams write problem statements that nobody could disagree with: “users find onboarding confusing”. Nothing was decided there. A real definition excludes things — it says which users, which part of onboarding, and what you are consciously not fixing this quarter despite knowing it is also broken.

The test is simple. Name what the definition rules out. If you cannot name anything, you have written a description, and the hard choice is still ahead of you — it will just get made later, implicitly, by whoever is building.

The move: write the problem statement with an explicit “not this” clause, and get the person who owns the roadmap to agree to both halves.
Ideate → Constrain

Idea volume is almost never the bottleneck. Deciding is.

The ritual of generating fifty ideas comes from a context where options were genuinely scarce. In most product teams the opposite is true: there is a backlog of plausible things and no mechanism for choosing between them. Another divergence session adds to the pile it was meant to resolve.

Constraint is the generative move. Solve it with no new screens. Solve it without asking the user for anything. Solve it so it ships in one week. Hard constraints produce better and fewer ideas than open briefs, and they arrive pre-filtered against the reality they have to survive.

The move: before any idea session, write the three constraints the answer must satisfy. Then generate for twenty minutes, not ninety.
Prototype → De-risk

Prototype the assumption, not the concept.

Teams build a prototype of the whole idea at whatever fidelity their tools default to, then test everything at once and learn little about anything. The useful question is narrower: what is the one belief that, if wrong, makes all of this worthless? Build only enough to examine that.

Fidelity follows from the risk. If the risk is whether people want it, the prototype may be a landing page with nothing behind it. If it is whether they can understand the model, grey boxes are better than polish, because polish attracts comments about polish. If it is whether the interaction feels right, you need the real thing in a real device, and nothing lower will do.

The move: write the risk on the prototype file before building. One file, one assumption, stated at the top.
Test → Decide

Decide what the results will mean before you collect them.

Testing without pre-commitment is where most of this method quietly dies. Results arrive ambiguous, as results do, and the team interprets them toward whatever it already intended. Everyone acts in good faith and the plan survives intact, which was never going to be falsified by a session nobody agreed the terms of.

The fix is a sentence written beforehand: if three of five people cannot complete this, we redesign the step rather than reword the label. It takes two minutes, it feels pedantic, and it is the single highest-leverage habit in the whole cycle because it converts a study into a decision in advance.

The move: before testing, write what you will do for each plausible outcome — including the outcome where nothing is clear.

Where is your process leaking?

Pick the step you are at, the constraint you are under, and who actually makes the call. The third input changes the advice more than the other two, which is itself the point of this piece.

Step diagnostic

Three inputs. One of the outcomes is that the process is not the thing to fix.

Which step are you at?

What is constraining you?

Who makes the final call?

Choose a step

Three inputs, one diagnosis

Pick where you are, what is in the way, and who decides.

Do this instead

—

Do not bother with

—

0 of 3 chosen

Exposure hours, measured honestly

Of everything above, the first reframe is the one with the longest payback, and it is the easiest to turn into a number.

Count, per quarter, how many hours each decision-maker on your team has spent watching or speaking with an actual user. Not reading a summary. Not attending a readout. Watching someone use the thing. In most teams the designer has many hours and nearly everyone else has none, which fully explains why the designer keeps having to re-argue the same points.

The intervention is unglamorous: invite two people to each session, rotate who comes, and keep the count visible. When an engineer has watched four people fail at their flow, you no longer have to persuade them — and the arguments in planning get shorter, which is the return on the whole exercise.

One caution about the reframes. None of this is an argument against divergence, empathy or prototyping as such. The original five steps describe real and necessary work. The point is that each word names an activity, and activities get performed to completion without producing a change. Reframing the verb attaches each step to something a team has to actually decide, which is what makes the cycle survive contact with delivery pressure.

Where this goes wrong

Common failures when design thinking is run as a process rather than a set of decisions
FailureLooks likePrevention
The ceremonyA full cycle run, four boards filled, no decision changedAttach each step to a decision with a named owner.
Empathy by proxyPersonas circulated, nobody has watched a userCount exposure hours per decision-maker, not per project.
Problem statements that exclude nothing“Users find it confusing”Require an explicit “not this” clause, agreed by the roadmap owner.
Divergence by habitFifty ideas added to a backlog that was already too longWrite the constraints first, then generate for twenty minutes.
Prototyping everythingA polished prototype testing six assumptions at onceOne file, one assumption, written at the top.
Fidelity mismatched to riskFeedback on colours during a structural testMatch fidelity to the question being asked.
Interpreting results to fit the plan“Mixed signals, let’s proceed as intended”Pre-commit in writing to what each outcome will cause.
Running the process without the deciderA beautiful handover to someone who was never in the roomIf they cannot attend, shrink the activity until they can.

Where to start

Take whatever you are about to test this month and write one sentence before you run it: if this happens, we will do that. Including the awkward branch, where the result contradicts the plan. It takes two minutes and it is the cheapest of the five reframes to adopt, because it needs nobody’s permission.

Then look at your next problem statement and add the “not this” clause. If you find you cannot write one — if everything feels in scope — that is the finding, and it is better to discover it now than in week six of building.

Neither of those is a process change. They are two sentences, written at two specific moments, and between them they convert most of the activity you are already doing into decisions somebody has to own.

How we work at Adi Design. We run these five as decisions rather than stages — the problem statement comes with what it excludes, prototypes name the single assumption they test, and we write down what each possible result will cause before testing. If your team runs the workshops and the roadmap never moves, get in touch.

Chat on WhatsApp