A founder emailed me last week with a Figma file that genuinely impressed me. Forty-odd screens, a proper component library, an onboarding flow with empty states and error states drawn out. It looked like a finished product. So I asked the question I always ask: how many of your future users have you actually shown this to? The reply came back honestly. None yet, I wanted it to look right first. That is the pattern I want to write about, because it is the single most common thing we see when a founder first approaches us, and it costs people more money than almost any other early decision.
The pattern: a perfect prototype, an empty user list
The shape is almost always the same. Someone has an idea they believe in, they spend weeks in Figma turning it into something that looks real, and they treat the prototype as the proof that the idea works. By the time they reach a studio like ours, the design feels settled. The colours are chosen, the screens are named, the flows are locked. What is missing underneath all of it is a single conversation with a person who would actually use the thing.
I understand the instinct completely. A Figma file is tidy and controllable. You can make it beautiful on your own, at your own pace, without anyone telling you your idea has a hole in it. Talking to users is the opposite. It is messy, it is slightly embarrassing, and it carries the real risk that someone says the polite version of “I would not use this”. So founders reach for the part that feels like progress and quietly skip the part that feels like exposure.
The trouble is that a prototype with no users behind it is a guess in a nice frame. Every screen encodes an assumption about what people want, how they think, and what they would pay for. Drawing those assumptions in higher resolution does not make them more true. It just makes them more expensive to change later, because now there is a design everyone is attached to.
Why it happens
Part of it is that design tools have become extraordinary. You can build something in a weekend that looks like it came from a funded company, and that polish creates a feeling of certainty that the underlying idea has not earned yet. The artefact gets ahead of the evidence.
Part of it is fear, and I say that with sympathy because I have done it myself. When you talk to users early, you invite reality in before you are ready for it. As long as the idea lives only in Figma, it stays perfect and it stays yours. The moment a real person interacts with it, it stops being a dream and becomes a thing with flaws. A lot of founders postpone that moment without ever deciding to, simply by staying busy with the design.
And part of it is a genuine misunderstanding about what a prototype is for. A prototype is not a finished decision. It is a prop you use to have a better conversation. The best Figma files I see are not the most polished ones, they are the ones a founder has clearly pointed at across a table while watching someone’s face.
What the Figma is usually hiding
When we dig into one of these no-users prototypes, the gaps are nearly always in the same places. The flows assume people will behave logically, in the order the founder imagined, which real people almost never do. The hardest part of the product, the bit that is actually difficult to build or to make people care about, is often the bit that has been designed last and thinnest, because it was the least fun to draw. And the core question, would anyone change their current behaviour to use this, has not been asked of anyone who is not already a believer.
None of this means the idea is bad. Plenty of these founders are onto something real. It means the prototype is answering the wrong question. It is showing that the idea can be made to look good, when the thing that needs proving is that the idea solves a problem someone has badly enough to act on.
What works instead
The fix is small and it is fast. Before you commission anyone to build anything, take whatever you already have, even a rough version, and put it in front of five people who match your target user. Not friends who will be kind. Five people who have the actual problem. You do not need a research budget or a moderation script. You need to watch them try to use it and stay quiet while they do.
Five is not a number I made up. It is roughly the point at which the same problems start repeating, which is the signal that you are learning the structure of what is wrong rather than collecting one-off opinions. You will hear the same confusion in the same place. You will see people skip the screen you were proudest of. You will discover that the feature you treated as secondary is the only one anyone reacted to.
Do that, and the Figma stops being a guess and starts being a tested hypothesis. The screens that survive contact with real people are the ones worth building. The ones that do not survive just saved you a five-figure development bill. This is also exactly what a good product studio will push you towards before writing a line of code, and it is why the strongest briefs we receive describe a problem and the people who have it, not just a set of screens.
What we do differently now
Early on, we used to take the polished Figma at face value and quote against it. We learned the hard way that this was doing the founder a disservice. We would build exactly what was drawn, it would work perfectly, and then it would meet users for the first time after launch, which is the most expensive possible moment to discover that a flow is wrong.
So now the first thing we do is gently separate the design from the evidence. We ask who has used it, what they did, and what surprised the founder. If the answer is no one, we do not treat that as a failing, we treat it as the first piece of work. A short round of conversations with real users, before any building, is the cheapest insurance a founder can buy, and it almost always changes the product for the better.
If you have a Figma file you are proud of and a user list that is still empty, that is not a problem, it is just the next step waiting to be taken. Show it to five real people this week, then tell us what you learned. The version of your product that comes out the other side will be worth far more than the one that stayed perfect in a design file.
.webp)
.webp)
