Test the design before you build it: what a clickable prototype saves you

A team spends three or four months building a new portal. It launches. Within a fortnight, support is fielding calls from customers who cannot find the button to submit a claim, and sales are walking prospects through a sign-up form that was meant to be self-service. Nobody designed it badly on purpose. The problem is that the first time real users touched the product was after it was finished.

The cost is easy to underestimate. Every confused user is a lost sign-up, a support call or a form filled in wrongly. Fixing it now means reopening work that was signed off, pulling developers off the roadmap and retesting code that already works. The same change, made while the design was still a set of linked screens, would have taken an afternoon.

This article is about closing that gap: putting a clickable prototype in front of real users before development starts, and what that does and does not tell you.

Why usability problems survive until launch

Most products are reviewed many times before they ship. The trouble is who does the reviewing.

• Stakeholders know too much. People inside the organisation understand the terminology, the process and the reason each step exists. They cannot unsee that knowledge.
• Designs are judged on how they look. A static mock-up invites comments on colour and layout, not on whether someone can complete a task.
• Journeys are designed around the organisation. Forms mirror internal systems, menus mirror the org chart, and steps exist because a department needs them, not because the user does.
• Testing is scheduled at the end. When user testing happens on the built product, findings compete with the launch date, and the launch date usually wins.

None of this is fixed by more internal review. It is fixed by watching people who have never seen the product try to use it.

What a clickable prototype is, and what it is not

A clickable prototype is a set of designed screens linked together so that someone can tap or click through a journey as if it were the real product. It looks close to finished. Behind it there is no database, no integration and no production code.

That is the point. It is realistic enough that users behave naturally, and cheap enough that you can change it the same day.

It is not:

• A specification of every edge case. It covers the journeys that matter most, not every error state.
• A test of performance or data. It will not tell you whether the system is fast or whether an integration works.
• Proof of demand. Users completing a task in a prototype shows they can use it, not that they will pay for it. Demand needs its own evidence.

Your options for checking a design before you build

There is more than one way to get evidence early. They answer different questions.

In practice the strongest approach combines them. Interviews and analytics tell you what to design for. A moderated prototype test tells you whether the design works. Internal review then confirms it fits the business.

How to run a prototype test that tells you something useful

A prototype test is only as good as its setup. A practical sequence:

1. Pick the journeys that carry the cost. Start with the tasks that drive revenue or generate support calls: signing up, booking, paying, submitting a request. Two or three journeys is enough for a first round.
2. Recruit people who match your users. Colleagues and friends are not substitutes. Small numbers work: a handful of sessions per round usually surfaces the main problems.
3. Give tasks, not tours. Ask users to achieve something ("Change your delivery address") rather than asking what they think of a screen. Then stay quiet and watch.
4. Record where people hesitate, not just where they fail. A user who eventually succeeds after a long pause is telling you the design is unclear.
5. Fix and retest quickly. Change the prototype between rounds. The second round confirms whether the fix worked or moved the problem somewhere else.

The timeline does not need to be long. Our own product and experience design work aims to put a clickable prototype in front of real users within the first two weeks, because that is when changes are cheapest.

Turning findings into something developers can build

Testing creates value only if the tested design survives the handover. Two things help.

Document decisions, not just screens. Developers need to know why a field moved or a step was removed, so they do not reintroduce the problem later.

Hand over a component library. When buttons, form fields, navigation and messages are defined once as reusable components, developers build faster and the product stays consistent as new features are added. It also means future changes can be tested against the same building blocks.

If you are planning the build itself, it is worth involving the development team before the prototype is final. They can flag designs that are expensive to build while there is still time to choose a simpler option.

When a prototype test is worth it, and when it is not

Prototype testing is not a ritual to apply everywhere. It pays back most when:

• You are building something new, or replacing an interface users already struggle with.
• The journey involves money, commitment or personal data, where hesitation leads to drop-out.
• Errors create downstream work: support calls, manual corrections, second visits.
• Development is the expensive part of the project, which it usually is.

It is less useful for small internal tools with a handful of trained users, or for minor visual changes to a journey that already performs well. In those cases, ship, measure and adjust.

For founders validating a new product, the prototype often doubles as a sales and investor tool: something concrete to show before the product exists. That is one reason design sits inside our MVP45 engagements rather than being treated as a separate phase.

A practical next step

Before your next build, list the two or three journeys where users most often get stuck or call for help. If any of them are about to be designed or rebuilt, prototype them first and watch five real users try them. What you see in those sessions will tell you more than another round of internal review, and it will cost far less than fixing the same problems after launch.