Rapid prototyping with real users: how we validate in days, not months

The fastest way to be wrong about a product is to write a spec. The fastest way to be right is to put something clickable in front of the people who will actually use it — and then watch what they do.

Day 1–2: shape the problem

One-hour interviews with three to five users. Not a survey — a conversation. We're listening for the workaround they've already invented, because that's where the real product lives.

Day 3–5: build the smallest useful version

A prototype doesn't need auth, a database, or edge cases. It needs the one flow that answers the biggest open question. If you're not sure what that question is, you're not ready to build yet.

Day 6–7: test, then decide

We watch users hit the prototype without narration. Everywhere they hesitate is a design bug. Everywhere they invent shortcuts is a feature request. Two rounds of this beats a month of Figma reviews.

Why speed matters

Feedback is a decaying signal. The longer the gap between a stakeholder's idea and a working artifact, the more the idea drifts and the harder it gets to say “this isn't working.” Rapid prototyping is really just permission to change your mind cheaply.