Prototype the risky parts first

Start with the question

A prototype can look convincing without answering anything that matters. A polished click-through might sell a visual direction while leaving permissions, business rules and error recovery untouched. So before opening Figma, write down the decision the prototype needs to inform.

For an approval tool, the question might be: can reviewers tell what changed between two submissions? For a customer portal: can people recover from an interrupted task? Those need very different prototypes. And neither needs every screen in the journey.

Choose just enough fidelity

A rough flow is fine for comparing the order of steps. A more realistic interface helps when you’re testing whether people read information correctly or find the right action. Coded prototypes earn their place when keyboard behaviour, responsive layout or complex interactions are part of the question.

The rule we use is the simplest version that can represent the behaviour believably. Higher fidelity isn’t automatically better evidence. Sometimes it’s worse, because people comment on the polish instead of the flow.

Make the content do real work

Placeholder content hides real problems. Long names, unfamiliar terms, incomplete records and competing priorities all change how a workflow feels. Use realistic examples that aren’t sensitive, chosen to stress the thing you’re testing.

Take a screen for comparing requests. Three neat, near-identical sample records will make the layout look tidy. They won’t tell you whether a reviewer can spot an unusual amount or a missing attachment. Vary the examples on purpose. Include the information a person needs to decide, plus the kind of noise the real interface will have to cope with.

Include one alternative that matters

The main route is only part of a complex workflow. Pick at least one alternative that could change the design: insufficient permissions, a returned request, two people editing at once, a failed connection. You’re not trying to simulate everything. You’re testing the riskiest branch.

Be upfront about what the prototype fakes. If a confirmation appears instantly but real processing takes an hour, note it. If every button goes to the same place, the prototype can’t show whether people understand the alternatives. Don’t let a staged demo stand in as proof that the finished product works.

Watch, don’t coach

When you test with people, give them a realistic task and avoid hints about where to click. Watch what they do, where they hesitate and what they think has happened. Ask follow-up questions without turning the session into a product tour.

Agree before the sessions how you’ll use what you see. One participant’s preference shouldn’t settle a design direction. Look for patterns between the task, the interaction and the evidence, and be honest about how small the sample was.

Turn what you learned into the next version

After each round, record:

• The question the prototype explored.
• What people did and said.
• The decision you made, and why.
• What’s still uncertain.
• Which states still need detailed design or technical checks.

On the conversational banking work described in the case study, a separate future-state prototype showed how the assistant could eventually propose a plan for the customer to review and approve. It was clearly labelled as a concept, not a commitment, and that’s why it was useful: it let people react to the idea without anyone mistaking it for the day-one release.

If your team needs to settle a tricky interaction before building it, let’s talk about a workflow design brief.