Functional prototypes before you build

A prototype here behaves like the product

Most things called prototypes are pictures of a product: screens linked together, one happy path, a demo that holds up as long as nobody touches anything unexpected. That is a useful thing to make. It is not this.

A functional prototype has real interactions, real logic and real data. It responds the way the product would respond — including when someone does something nobody planned for. Your team can use it. Your users can use it. That is the entire bar.

Which is also why it belongs before engineering commits. The questions that sink a build are questions about behaviour: what happens in this state, who is allowed to do that, what does the system do when it isn’t sure. A picture cannot answer those. A working prototype answers them by existing.

A picture collects opinions. A prototype collects evidence.

Show a room a mockup and everyone fills in the missing behaviour themselves — differently, and silently. The conversation that follows is about the picture. Everyone leaves with an opinion, and the opinions aren’t comparable, because no two people in the room were imagining the same product.

Give that room something they can operate and the conversation changes shape. It either works for them or it doesn’t. You stop hearing “I think users would…” and start watching what people actually do.

make. test. learn. decide.

Where it fits

Prototyping isn’t a phase bolted onto the front of a project; it’s how the work runs at every stage. Four ways in, depending on where the product already is:

• Decide — 1 day — One critical question in the way? A fixed-price session that settles the direction, and names the evidence that would confirm it.
• Validate — 1–2 weeks — Have a direction? Turn it into something real enough to test before you commit to building it.
• Launch — typically 4–8 weeks — Ready to build? Turn a validated direction into a production-ready product experience people can actually use.
• Evolve — ongoing — Already shipping? Improve the experience, add features, and build the systems your team needs to scale.

Testing behaviour, not preference

Asking people whether they like something produces answers about people, not about the product. Sessions here are moderated and task-based: someone is handed something real to get done, and the interesting data is where they hesitate, what they misread, and what they never find.

Twelve hikers ran the adaptive route prototype for Field. Eight analysts worked through investigations in Orbit. Thirty-two participants tested two competing interaction models for the Mercedes-Benz companion app, and the split in observed behaviour — 75% favouring the MBUX-adapted model — settled a question that had two entirely defensible answers on paper.

The number of sessions is usually smaller than people expect. You aren’t measuring a population. You’re finding out whether the thing works, and that shows up fast.

What you’re left with

The prototype, and the evidence from putting it in front of the people who would use it. Alongside that: the product logic, the requirements and the design decisions to build from — the things an engineering team needs and a design file doesn’t carry.

The prototype isn’t really the deliverable. The decision it lets you make is.

When not to do this

It’s the wrong spend if the decision is already made and what you actually need is production design. It’s the wrong spend if there’s no access to the people who’d use the thing — without them there’s no evidence to collect, and you’re paying a premium for an opinion. And it’s the wrong spend on a question nobody disagrees about. If the team already knows what to build, build it.