Product prototyping before you build

01 — The prototype

It behaves like the product. It is not the product.

A prototype here is something a person who has never seen your product can sit down with and use: real tasks, realistic data, the states that actually occur — empty, wrong, waiting, done. It is narrowed to the one decision we are testing, and everything outside that decision stays deliberately rough.

That is what makes it evidence. When someone hesitates, chooses wrongly, or finishes without help, that is a reaction to the product — not to a description of it.

• Not a deck. A deck can’t be used wrongly, so it can’t tell you anything.
• Not a wireframe. Boxes don’t behave, and behaviour is the uncertain part.
• Not a pixel-perfect design. Polish answers a question nobody has asked yet.
• Not an MVP. Nothing here ships; it exists to be thrown away once the decision is made.

02 — The four weeks

Four weeks, one decision — and what each week produces.

The outline is on the home page. This is what sits underneath it: what happens, what I need from you, and what you hold at the end of each week.

1. Week 1Name the decision — and what it costs.

   What happens

   Two or three working sessions with the people who own the decision. We write down the decision in one sentence, what committing to it costs, the assumption it rests on, and what would have to be true for that assumption to hold. If we can’t write that page, that is the finding.

   What you bring

   The decision-maker, an hour or two of the people closest to the users, and whatever already exists — concept, requirements, data, the deck.

   What you hold

   The one-page decision brief. It is yours whether or not we continue.

2. Week 2Build the thing people can react to.

   What happens

   I build the prototype against the brief: the flow the decision depends on, with realistic data and the states that occur in practice. We agree the tasks people will be given and what a good or a bad outcome looks like — before anyone sees it.

   What you bring

   Sample data and the awkward cases, an hour with a subject-matter expert, and a yes on the task list.

   What you hold

   A working prototype you can open in a browser, and the task list it will be tested against.

3. Week 3Put it in front of the people who would use it.

   What happens

   Sessions with the people who would use the product — usually five to eight per round, one round per decision. Each person works through the tasks; I observe and note what they do, where they hesitate, and what they say without being asked. Your team is welcome to watch.

   What you bring

   The participants. Your customers, your users, your internal experts — the people whose reaction counts.

   What you hold

   The study findings: what happened, per task and per person, and what it means for the assumption.

4. Week 4Decide, in writing.

   What happens

   I write the recommendation: build, change course, or stop — with the evidence attached — and the product logic, requirements and design decisions the recommendation implies. We walk through it together.

   What you bring

   The decision meeting, with the people who can commit.

   What you hold

   The written recommendation, the prototype, the findings, the brief. Everything engineering needs to start — or the reason not to.

What I don’t do is make the decision. The evidence and the recommendation are mine; the commitment is yours.

03 — The testing

Behaviour, not preference.

Asking people whether they like something produces politeness. Giving them a task produces behaviour. Sessions are built around tasks the product will actually be used for: complete this, find that, decide whether to approve this. What matters is what people do — and whether they can predict what the product will do next.

Sessions run remotely by default, on-site when the work or the users require it. Recruiting is yours: the people whose reaction counts already know you, and a round of five to eight tells you what you need to know for one decision. If reaching users isn’t possible, this is the wrong engagement — better to know that in week one.

Where a decision has two credible answers, both are prototyped and tested against the same tasks. I have done this at scale for a Mercedes-Benz companion app — thirty-two people, two interaction models, identical tasks — as a master’s-thesis collaboration. Same principle, smaller round.

04 — Where it works

Complex products, expensive commitments.

The method pays off where being wrong is expensive and hard to undo: enterprise and B2B products with workflows nobody fully sees, AI features whose value depends on whether people trust them, interfaces where every screen is a decision someone is accountable for.

• Enterprise workflows — a design system and community of practice at CERN, built by finding the decisions every team was making twice. →
• Cross-device behaviour — a study for Mercedes-Benz on whether familiarity should come from the platform or the product. →
• AI people can verify — a review workflow at PwC built around one question: why did the AI make this prediction? →

These were staff roles and a thesis collaboration, not four-week engagements. They are where the method comes from.

For AI workflows specifically: designing AI products people can verify →

05 — Questions