High-fidelity prototype: the checklist before approving and building

The approval meeting for a high-fidelity prototype is misleading. The canvases look beautiful, everyone nods their heads, someone says "it looks great" and the project moves forward. Weeks later, development stalls on questions no one asked in that room: what happens when the list is empty? What about the error state? And offline?

The difference between a prototype that gets the job done and one that hides problems is not beauty. It is in the rigor of the review. Approving based on appearance is the most common and most expensive mistake made by those who work with products.

This text is for those who are close to deciding: are we going to build this? Instead of explaining what a high-fidelity prototype is, he offers a review checklist, the questions that separate a prototype ready to become a product from one that will generate rework.

Why approving based on appearance is risky

High fidelity tricks the brain. When something feels real, we assume it is complete. It's a known bias: visual realism creates a feeling of readiness that often doesn't correspond to the depth of what was thought.

The result is that important decisions become invisible. The prototype shows the happy path, user does everything right, connection works, data exists. But real product lives in the unfortunate ways: wrong fields, unstable connections, empty lists, denied permissions.

A high-fidelity prototype that only covers the happy path is not ready for approval. It's ready to be questioned. And structured questioning is what the checklist guarantees.

The thesis: the checklist protects against optimism

I advocate that every high-fidelity prototype approval undergoes a deliberate review, with fixed questions, regardless of how convincing it appears. Not because of distrust, but because optimism is the natural state of someone who has just produced something beautiful.

The checklist is not bureaucracy. It's the way to transfer attention from "does it look nice?" to "is it complete and buildable?". It forces the difficult conversation before commit, when it is still cheap.

Teams that adopt this discipline see a real drop in rework. The problems that would appear in sprint 3 appear in the prototype review, costing a conversation instead of a redo.

The checklist of states and exceptions

The first front of review is the most neglected: the states that are not the happy path.

For each important screen, ask: How does it appear empty, with no data? How does it appear loading? How does it appear when there is an error? What about when there is too much data, a list with hundreds of items, a name that is too long, text that overwhelms the layout?

Go further and cover connection exceptions: what does the user see offline? What happens when the operation fails in the middle? What about when he doesn't have permission for what he tried to do?

If the prototype doesn't answer these questions, it's not wrong, it's incomplete. And approving an incomplete prototype as if it were ready transfers the problem to the developer, who will invent answers under deadline pressure.

The content and clarity checklist

The second front is content. High-fidelity prototypes often use text carefully chosen to fit beautifully. Real product doesn't have that luxury.

Check that the texts are real and plausible, not optimized for the layout. Test with the longest name, the highest value, the longest title. Confirm that button labels say what they do, that error messages guide rather than scare, and that technical terms haven't leaked into the end user interface.

In a digital public service, this care is even more serious. The citizen needs to understand what is being asked without knowing the agency's internal vocabulary. An ambiguous label on a benefit form can lead to massive filling errors and face-to-face service that digital services should have avoided.

Content is part of the experience, not embellishment. A prototype approved without text review is postponing a guaranteed problem.

The technical feasibility checklist

The third front requires engineering to participate in the review, not just design and business.

Ask: is this flow buildable within the expected time frame? Are there any interactions that look simple in the prototype but are expensive to implement? Does the data that appears on the screen actually exist in the system, or was it invented to make the prototype look nice?

That last question overturns many prototypes. It is common to design screens with information that the system cannot provide, or that depend on integrations that do not exist. Finding this out in the review costs a conversation. Finding out in implementation costs a redesign.

Bringing engineering to approval is not distrust of design. It is recognizing that feasibility is part of the quality of a prototype. A beautiful, unbuildable prototype is a document of future frustration.

The expectations and scope checklist

The fourth front is about the people in the room, not the screens.

Before closing the approval, make it clear: what does this prototype cover and what does it not cover? Does it represent the final version or just a part? How much time actually separates this prototype from the delivered product?

This alignment avoids the classic attrition in which stakeholders see the realistic prototype and start to treat it as an almost finished product. When what is delivered does not match the brilliance of the prototype, the perception is of failure, when in fact it was just the natural distance between simulation and construction.

Recording the scope of the prototype, even in one sentence, protects the team and protects the relationship with whoever sponsors the project.

Turning the checklist into a habit

A checklist only works if it is used all the time, not just when the project is large. The temptation is to skip the review when the prototype "seems obvious." It is precisely in these cases that forgotten states go unnoticed.

The best way to incorporate this is to make it light: a short list, reviewed together, with design, product, and engineering in the same conversation. It doesn't have to be a long form. It needs to be a deliberate pause before “pass.”

Leadership defines whether this sticks. When leaders ask the difficult questions during the review, the team understands that approving is a responsibility, not a formality. When leadership approves based on appearance, the team learns to focus on the showcase and ignore the substance.

In the end, the checklist is an act of honesty with the future. He exchanges the comfort of "it looks beautiful, approved" for the work of ensuring that what is beautiful is also complete, clear and buildable. This work isn't glamorous, but it's what separates teams that deliver from teams that redo.

If you are setting up a prototype approval process and want to structure a review like this, there are other texts here on the blog about prototyping and product quality. And if you want to discuss how to adapt the checklist to your context, just call to talk.