The prototype that tells you everything
Why the live prototype usually gives a clearer brief than the tidy project document ever can.
Every project has a brief. Most briefs are wrong - not dishonestly, just incompletely. The client writes down what they think the problem is. The real problem is usually one layer deeper, and it only becomes visible when you look at what they’ve actually built.
This is why I ask for the live link before anything else.
There’s a moment that happens in almost every engagement, usually in the first hour of looking at the real thing. Someone has spent months - sometimes years - building a prototype. They know it inside out. They’ve written a brief explaining what it does, what’s wrong with it, and what they need fixed. And then I open the link, and within about three clicks I can see a problem they haven’t mentioned anywhere.
Not because they were hiding it. Because they stopped seeing it. They got too close, too long ago.
The brief says: “We need the UI redesigned, it’s not converting.” The prototype says: the UI is fine. The problem is that users can’t tell whether the data is trustworthy. Every number on the screen looks provisional. There’s no timestamp, no source attribution, no error state for when data is missing. The user doesn’t know if what they’re looking at is current or stale, accurate or approximate. They bounce - not because the design is wrong, but because the design doesn’t answer the question they have before they’ll act on anything.
That’s not in the brief. It can’t be. It requires seeing the thing.
This is why I don’t do discovery calls before I’ve looked at the project. “Tell me about your idea” is a useful conversation for some practitioners. It’s not how I work. Ideas described in words are always tidier than ideas expressed in code. I want to see the gap between what the project intends to do and what it currently does to a first-time user. That gap is the actual brief.
The prototype is also more honest than the person briefing it. Not because clients are unreliable - they’re not - but because a person who has built something has necessarily become blind to certain things about it. They navigate it the way they built it. They know the shortcut. They know to wait two seconds on that screen. They’ve forgotten what it’s like not to know any of that.
I come in knowing nothing. That’s the useful thing.
The practical version of this: when something half-built arrives, I’m looking for three things.
The first is the core loop - can I get from entry point to the thing the product exists to do, without help? If I can’t, that’s the priority. Everything else is secondary until that path works for someone who has never seen the product.
The second is trust signals. Does the product communicate that it’s reliable? Current? Built by someone who thought about edge cases? Most prototypes are built by people who know the happy path. The edge cases - slow connection, missing data, ambiguous input, unexpected device - are where trust is built or destroyed. They’re almost always under-built.
The third is the smallest version of done. Most prototypes have too much in them. Features added because they seemed useful at the time, flows that branch into dead ends, copy that was never finalised. Getting to a cleaner, smaller version usually makes the product more useful, not less. But you can only see what to remove from the outside.
None of this is magic. It’s just what happens when you look at a thing with fresh eyes and enough experience to know what you’re looking at.
The brief you write is the project as you understand it. The prototype is the project as it actually is. I work from the prototype.
Send me the messy one. The tidy brief can come later.