Before you have an onboarding flow, a customer area or a checkout built, there is a cheap step that often gets skipped: the clickable prototype. A handful of linked screens that you click through as if they were the real product, to see whether someone understands where to go. People skip it because "the developers are starting anyway", and they pay for it three sprints later.
I am writing about it because this is how I designed the product at Moonworkers, my own company: starting from its users, with personas, wireframes, a design system in Figma and a lot of back and forth. And because my engagements have taught me that the tool matters less than two things: how many directions you show, and how finished they look. Here is how I go about it now.
01What a clickable prototype helps you decide
A prototype is a hypothesis you put to the test, far more than a cut-down version of the product. Kara Pernice at Nielsen Norman Group puts it plainly in her piece on prototype fidelity: the most direct way to test that hypothesis is to watch users work with it.
Before I open Figma, I write down the question the prototype has to answer, in one sentence. For example: "Does a new user understand what information they need to provide before they can carry on?" or "Can the three sign-up steps fit on a single screen?". If you cannot write it, the prototype will turn into a demo, and a demo settles nothing.
It is the same discipline I apply in my content machines: the brief blocks the writing until the angle and the promise are written down. Without that lock, you produce straight away, in generalities, and find out afterwards that there was no question.
The UK government's Service Manual, in its page on making prototypes, follows the same logic: prototype to explore, share and test before you build, make several quickly and throw away the ones that test badly. Throwing things away is part of the job.
02Low or high fidelity: choose based on the question
Fidelity is how closely the prototype resembles the final product. It covers three things: interactivity, visuals and content. A prototype can be very faithful on one and not on the others.
A low fidelity prototype means grey screens, summarised copy, sometimes paper. You can change it between two test sessions. According to the same Nielsen Norman Group article, people are more willing to criticise it, and designers are less attached to it. It is the right format for a structural question: in what order, how many steps, what goes where.
A high fidelity prototype has the real content, the real colours and instant responses to clicks. People behave almost as they would with live software. It is the right format for testing a specific journey, how readable a form is, or whether a regulatory message is understood.
Choose based on the question rather than on how far along the project is. A structural question can be tested in grey, even late on. A wording question needs the real words, even early.
03Three directions at the same level of finish
If I had to keep one thing from my engagements on this subject, it would be this: showing several mock-up directions at the same level of finish unblocks a decision. A mock-up presented on its own gets judged against whatever each person has in mind, and everyone has something different in mind. The discussion then circles around the mock-up instead of settling anything.
The level of finish matters as much as the number. Put a polished direction next to a sketched one and the polished one will win, simply because it looks finished. With three clickable prototypes at the same level, you finally compare ideas rather than the time spent on each. You can then refine them together from there.
Usability research describes this method under the name parallel design. Therese Fessenden's article at Nielsen Norman Group reports a study in which four versions were created in parallel: the version that merged the strongest ideas from all four was 70% more usable than their average. The same article recommends at least three alternatives, five at most, and cheap ones: a few days each.
I do not take the figure as a promise. What I take from it is that the losing direction often brings something to the winning one.
04Building the prototype in Figma, step by step
I use Figma, as I did for the design system at Moonworkers. The design and the prototype live in the same file, and the people reviewing it comment directly on the shared link.
The method I follow
- Write the test question and the journey to cover, from the first screen to the expected outcome.
- Draw only the screens in that journey, plus one or two realistic error states (a rejected field, an unreadable document).
- Link the clickable areas to the next screens. Figma's prototyping guide calls these connections, each with a trigger (click, hover, drag) and an action (navigate to another frame).
- Set one starting point per flow. A file can hold several flows: I make one per direction, so each gets its own shareable link.
- Bring all three directions to the same level: same copy, same content, same visual finish. This is the step people rush, and the one that matters most.
- Click through the whole journey yourself, then have someone who has never seen it do the same, before the first test.
If the prototype is shared online, I follow the advice in the GOV.UK Service Manual: put it behind a password, so nobody mistakes it for the real service.
05Testing it with five people
You do not need fifty testers, or even software. Nielsen Norman Group has put a paper prototyping demonstration on its YouTube channel: simulated screens, low then higher fidelity, tested on a website, a mobile phone and a kiosk. The video was filmed in 2011, and NN/g notes that the method still holds.
On the number of people, Jakob Nielsen, in a widely quoted Nielsen Norman Group article, shows that a test with five people finds around 85% of usability problems, and that three small tests of five are worth more than a single test of fifteen. What counts is fixing things between rounds.
With several directions, I show two or three versions to each person, changing the order from one person to the next, as the parallel design article recommends. Otherwise the first direction seen starts with an advantage, or a handicap.
During the session I say very little. I give a task ("create your account and invite a colleague"), watch where the person hesitates, and note the exact spot. When they click an area that leads nowhere, I ask what they expected to find. That answer is often worth more than the rest of the session.
06What a prototype will not tell you
A prototype has limits, and I prefer to say so from the start.
It does not test the engineering, and you will only find out during development. A screen that appears instantly in Figma can take four seconds in production because it queries three systems. Nor does it test real data: a forty character name, a foreign address, an account with no history. Those cases show up in acceptance testing, which I cover in my acceptance testing and go-live checklist.
It does not replace the specification. Once a direction is chosen, you still have to write down what happens behind every button, which I explain in the piece on the integration specification. And the prototype does not get recycled into code: GOV.UK says so bluntly, you do not copy prototype code into production.
Finally, it takes time. Three directions at the same level is three times the work of one. For a simple page or an admin screen used by two people, I do not bother: a mock-up and a conversation are enough.
07Where to start next week
If you have interface development planned in the coming weeks, start small:
- write down the question the prototype has to settle, in one sentence;
- choose the fidelity based on that question;
- prepare at least two directions, ideally three, at the same level of finish;
- find five people who resemble your users and book an hour with each;
- note what gets in the way, fix it, then run another small round.
If you would like an outside view of a journey before development starts, that is part of what I do in my consulting and build work. Happy to talk it through.