Why a clickable prototype saves you weeks

A clickable prototype is your app, designed and wired together screen by screen, that you can tap through on a phone before a single line of code exists. It saves weeks because mistakes show up while they still take an hour to fix: move a button, redo a screen, drop a step. Once the app is built, the same change means rewriting code, testing it again and shipping it again.

What it actually is

The screens are drawn in a design tool, Figma for example, and linked together: tap "Book," the calendar opens; pick a time, the confirmation appears. Figma calls these connections between hotspots and the screens they lead to, and it gives you a link you can send to someone so they can try it. On a phone it looks and behaves almost like a real app. Behind it there's nothing: no data gets saved, no notifications go out, no payments happen.

That's the whole point. As Nielsen Norman Group puts it, ripping up code is very expensive, and ripping up a prototype isn't.

What goes in it

Not every screen. You include the main paths, the ones the app exists for:

• the first contact: opening the app, the account, any permissions;
• the core action, start to finish (a booking, an order, a request);
• what the user sees afterward: the confirmation, the history, where to find what they did.

Settings, legal pages and edge cases can wait. A prototype with 15 to 25 well-linked screens tells you more than one with 80 half-finished screens.

How to test it

Testing is simpler than it sounds. Find someone who resembles your customer, hand them the phone and a task ("book yourself in for Thursday afternoon"), then stay quiet and watch. Where they hesitate, where they tap the wrong thing, where they ask "now what?": those are your problems.

How many people? Jakob Nielsen wrote back in 2000 that five users uncover about 85% of usability problems, and that the best results come from several small tests with fixes in between, not one big study. In practice: five people, fix things, then three to five more on the new version.

Where the time savings come from

• The client and the team see the same thing. A 20-page spec gets read ten different ways. A prototype gets tapped one way. "I thought that button was somewhere else" conversations end before development starts.
• Estimates get more accurate. Developers see exactly which screens and states exist, so they estimate what's actually being built, not what they imagined.
• Changes stay cheap. An extra signup step discovered in testing comes out of the prototype in minutes. Discovered after launch, it means a new release in the app stores and users who left in the meantime.

What a prototype won't tell you

A prototype doesn't test real speed, real data or what happens when the connection drops. It won't tell you whether people come back the next day, either. For that you need a first working version, as small as possible. What the prototype does tell you is just as useful: whether people understand the app and can do what they came to do.

For us, the clickable prototype is the stage right before code. You'll find the steps on our App Dev services page. On what belongs in a first release, we wrote about the MVP: the smallest app worth launching.