A prototype is a testable version of an interface that answers a specific question before any code is written: will people understand how to book, find the right button, get through the time-slot step. Fidelity follows the question: a sketch or wireframe is enough to test the logic of a flow, while perception and micro-interactions need a clickable high-fidelity prototype. Start not with screens but with a user flow, and finish by testing with five people from the target audience.
After this you will be able to
- Define the question a prototype must answer and pick a fidelity level for it
- Map a user flow with the main path and error branches before drawing screens
- Build a clickable 4–6 screen prototype in Figma with connections, transitions and an overlay
- Run a short test with five participants and recognize when it’s time to move to code
Know beforehand
Verified with
Figma Design (help.figma.com, 2026-10-11)
Checked against docs: October 11, 2026
Contents
Why prototype, and what it should test
Nielsen Norman Group puts it briefly: a user interface prototype is a hypothesis, and the most direct way to test it is to watch users work with it. Changing a prototype costs far less than rewriting shipped code. So a prototype isn’t “a pretty picture for the client” but a tool that answers a question before development.
The main mistake is prototyping “the whole app” without a question. Then nobody knows how many screens to draw, in how much detail, or what counts as success. A good question is specific and testable:
A vague question
- “Is the site easy to use?”
- “Do people like the design?”
- “Is everything clear?”
A testable question
- Can a client book the stylist they chose for the next free slot without help?
- Do people notice that a booking can be rescheduled, not just cancelled?
- Is it clear what to do when the chosen day has no free slots?
This guide walks through one flow end to end — booking a service at a salon or clinic: from a user flow to a clickable Figma prototype and a test with people.
Fidelity levels: sketch, wireframe, clickable, high-fidelity
Nielsen Norman Group describes prototype fidelity along three independent dimensions: interactivity (links and menus work by themselves, or a person simulates the response), visuals (how closely layout, spacing and hierarchy match the product) and content (real copy and navigation, or placeholders). A prototype can be detailed on one axis and rough on another — a clickable grey wireframe, for example.
Sketch
- Looks like
- Hand-drawn on paper or a whiteboard
- Tests
- The set of steps and what goes on each screen
- Won’t test
- Perception, text length, tap comfort
Wireframe
- Looks like
- Grey blocks, real structure, minimal styling
- Tests
- Hierarchy and block order, completeness of screens
- Won’t test
- Emotional response to visuals, legibility in real colors
Clickable (low/mid-fi)
- Looks like
- Wireframes linked with transitions
- Tests
- The whole flow: do people find the path, where do they get lost
- Won’t test
- Reaction to final visuals and micro-animations
High-fidelity
- Looks like
- Close to the finished product: colors, fonts, real copy, states
- Tests
- Perception, component clarity, legibility, trust
- Won’t test
- Real data, speed, server errors
Low fidelity — per Nielsen Norman Group
- Quick to prepare, leaving more time for design itself
- Can be redrawn during a test
- Participants criticize obviously unfinished work more freely
- But a person simulates responses — they can make mistakes and slow the flow
High fidelity — per Nielsen Norman Group
- Realistic response, so people stay in the flow
- Lets you test specific components and visuals
- The facilitator doesn’t drive the prototype and can focus on observing
- But it takes longer to build, and polished work is harder to critique
The scenario and user flow come before screens
Nielsen Norman Group separates two ideas. A user journey is the path to a high-level goal across channels, sometimes spread over weeks: saw an ad, asked in a messenger, came to the appointment. A user flow is the set of steps inside one product for a specific task, usually taking minutes: picked a service, a stylist, a time, confirmed. A prototype needs the flow: it records user actions and system responses.
- 01Service
- 02Stylist
- 03Date and time
- 04Contact details
- 05Booking confirmed
The main path is only half the flow. A prototype where everything always works tests only the obvious. Before drawing screens, add the branches:
Goal and entry point
Who the user is and where they come from: the home page, a map search, a link in a messenger. The entry point defines the first screen.
Main path
Steps in order, each with a user action and a system response: “picked a stylist → shown their free dates”.
Decision points
Where the user makes a choice: “any stylist” or a specific one, the nearest slot or picking from a calendar.
Errors and empty states
No free slots that day, an invalid phone number, the slot taken while the person was filling in their details.
Exit and return
How to go back a step without losing choices, how to cancel or reschedule after confirmation.
Prototyping in Figma: connections, transitions, overlays
Prototyping in Figma is available on every plan: anyone with edit access can build a prototype, and anyone with view access can play it. The work happens in the Prototype tab of the right panel; Shift+E toggles between Design and Prototype. Five concepts from the Figma Help Center you need to know:
Hotspot
- What it is
- The object people interact with: a button, a card, an icon
Connection
- What it is
- The blue arrow from a hotspot to its destination; interaction and animation are set on it
Trigger
- What it is
- What starts the transition: On click / On tap, While hovering, While pressing, On drag, After delay, Keyboard/Gamepad and others
Action
- What it is
- What happens: Navigate to, Back, Open overlay, Swap overlay, Close overlay, Scroll to, Open link, Change to
Flow and starting point
- What it is
- The network of linked frames on a page and its first screen; a prototype can have several flows
Screens
Create five top-level frames with the Phone preset, one per flow step. A destination can only be a top-level frame, not a nested object. Use component instances from the Figma basics lesson for buttons and cards.
First connection
In the Prototype tab, select the service card, drag the connection handle (the prototype node) on its bounding box and drop it on the “Stylist” screen. Figma makes the first frame the flow’s starting point automatically.
Interaction
In the connection settings: trigger On click, action Navigate to, animation Push or Slide In from the right — so moving forward reads as progress through the steps. For a back button, use the Back action.
Overlay
A time-slot calendar works well on top of the screen: draw it as a separate frame and give the connection the Open overlay action. In the overlay settings, pick a position and turn on Close when clicking outside and Add background behind overlay.
States without extra screens
If the button component is built from variants, add a connection between variants with the Change to action (for example, Default → Hover on While hovering). This interactive component works in every instance without duplicating screens.
Error branch
Add a “No free slots on this day” screen and an invalid phone number field state. If they need their own start, add another starting point: right-click the frame → Add starting point.
Play
Preview in the toolbar or Shift+Space plays the prototype inside the editor; Present (Ctrl+Alt+Enter on Windows, Command+Option+Return on Mac) opens it in a separate tab with the chosen device.
Transition animation is covered in detail in the guide to screen transitions. For testing a flow, what matters is not how pretty a transition is but what it means: forward through steps slides left, back slides right, a temporary layer appears on top.
Testing the prototype with users
Usability testing, as Nielsen Norman Group defines it, rests on three elements: a facilitator who runs the session without steering; tasks — realistic activities people might do in real life; and a participant — a real user or someone as close to one as possible. For a qualitative study of one user group, NN/g recommends five participants: enough to uncover most of the common problems.
A task without hints
Not “tap Book and choose a stylist” but “You want a haircut with Anna this Saturday afternoon. Book it.” The wording shouldn’t contain button labels from the screen.
A pilot run
Go through the flow yourself or with a colleague: a broken connection or the wrong screen mid-test throws participants off and spoils the data — NN/g recommends a pilot before real sessions.
Thinking aloud
Ask participants to say what they see, look for and expect. This is the main source of findings in a qualitative test.
Observation
Note where people stop, go back or tap the wrong thing. If they tap an element with no connection, ask what they expected to see.
Takeaways
After five sessions, put the problems in a table: step, what happened, how many participants, what changes. Fix them and retest if needed.
Present mode has useful options: Hide UI hides Figma’s interface, and Show hints on click highlights clickable areas when someone clicks outside a hotspot. Hints help in a presentation, but in a test they give away the answer — decide in advance whether to turn them on.
- One or two questions the test answers are written down
- Tasks use the user’s language, without button labels
- The prototype has had a pilot run and every connection goes where it should
- Error and empty-state branches exist, not just the happy path
- Participants come from the target audience, not the team
- Results are summarized in a “problem → frequency → fix” table
When the prototype has done its job and it’s time for code
A prototype stops paying off when the questions it was built for are answered and the new questions concern things a mockup can’t show. Guidelines:
Keep prototyping
- Participants get lost on one of the steps
- The team argues about step order or the set of fields
- Error branches haven’t been tested
- The client can’t picture the flow as a whole
Move to code
- People complete the flow without hints; only small copy fixes remain
- Questions are about real data: long names, hundreds of stylists, a slow network
- Real validation, screen reader accessibility and speed need testing
- Real metrics are needed: conversion, time to book
A clickable prototype can’t test performance, real server responses, or keyboard and screen reader use the way code can. For those questions, teams build a code prototype or an MVP — a minimal working version with real data. The prototype isn’t thrown away: linked to Figma components, it becomes the flow specification for developers.
Sources
- Nielsen Norman Group — UX Prototypes: Low Fidelity vs. High Fidelity
- Nielsen Norman Group — User Journeys vs. User Flows
- Nielsen Norman Group — Usability Testing 101
- Figma Help Center — Guide to prototyping in Figma
- Figma Help Center — Create overlays in your prototypes
- Figma Help Center — Create interactive components with variants