How to review a prototype
To review a prototype, open it on the device it's designed for, step through the key flows as a real user would, and write notes pinned to the specific element you mean — not descriptions like 'the button near the top.' Separate whether the idea is right from whether the execution is right; they need different conversations. The most common mistake is giving visual feedback first when the flow hasn't been approved yet.
Open it on the right device first
If the prototype is a mobile app, open it on your phone — not your laptop. A design that looks fine on a 27-inch iMac can break or feel cramped on a 390px iPhone screen, and you won't catch that reviewing on the wrong surface. For Figma prototypes, open the presentation link in Chrome or Safari, not the Figma desktop app — the app adds its own chrome that changes how spacing feels. Ask the designer which device they designed for, then match it.
Step through one flow at a time, as if you're a new user
Don't explore freely on a first pass — complete a specific task the way a new user would. If it's a checkout flow, try to buy something. If it's an onboarding sequence, create an account. Note where you hesitate or click the wrong thing — those moments are the most useful signal. Save aesthetic opinions (colours, fonts, spacing) for a second pass after the flow is approved. Reviewing typography before the checkout flow works is a fast way to burn a revision round on the wrong problem.
Separate 'wrong idea' from 'wrong execution'
The most useful distinction in prototype feedback: is the concept wrong, or is it right but executed poorly? 'Users shouldn't have to create an account before checkout' is a product decision. 'I got confused about whether the button saved my progress' is a layout or copy fix. These need different responses. Mixing them — 'this whole section doesn't feel right' — makes both harder to act on. One note per issue, labelled as concept or execution.
Pin notes to the exact element, not a description of it
The difference between useful and useless prototype feedback is usually specificity. 'The CTA in the checkout frame is too small' pinned to the actual button is actionable. 'The button near the bottom of screen 3 feels off' in an email thread requires the designer to translate your words back into coordinates — and they'll sometimes get it wrong. Click the element you mean and type the note there. In Figma presentation mode you need a free account to comment; on a shared frame export (PNG or PDF), use a review tool that lets you annotate as a guest.
Send all your notes in one round, not as they come to mind
Drip feedback — one Slack message now, an email at 3pm, a voice note the next morning — is harder to act on than a single consolidated pass. Review the whole prototype, write your notes, then send them together. That way the designer sees the full picture before revisions start. The one exception: if you find something that invalidates the rest of the review (the whole checkout flow is wrong), flag it early and ask whether to keep going or wait for a revised version.
If the designer has shared their prototype frames as a Drafty link, you can click the exact element and leave a note pinned right there — no Figma account, no screenshot. Every note threads in one place; the designer sees what you pointed at without any translation. Open the link, click the thing you mean, type your note.
Open a live demoQuestions
- What should I look for when reviewing a prototype?
- Review in this order: flow first (can a new user complete the task?), then layout and hierarchy (is the next step obvious?), then copy and labels (does the language make sense?), then visual polish. Reviewing in the wrong order — starting with colours and fonts before the flow is approved — wastes revision rounds.
- Do I need a Figma account to review a prototype?
- To click through a Figma prototype, no — the designer can share a presentation link that anyone opens in a browser. To leave a comment directly in Figma, yes — you need a free Figma account. If you don't want to sign up, ask the designer to export the key frames as PNGs and share them in a review tool that accepts guest comments.
- How detailed should prototype feedback be?
- Specific enough that the designer knows exactly which element you mean and what to do differently. 'The loading state is missing on the submit button' is good. 'It feels a bit slow' is not — the designer doesn't know where to look. One issue per note, with the element named or pointed at.
- How do I give feedback on a prototype without being vague?
- Describe what you experienced, not what you felt. 'I clicked the Save button and wasn't sure if the form submitted' is specific; 'this section feels off' is not. User-experience language — what happened, what you expected, what surprised you — is naturally more precise than aesthetic language.
- What's the difference between reviewing a prototype and user testing?
- User testing measures whether real users can complete tasks — it's observational and the facilitator tries not to help. A prototype review is a stakeholder or client giving design feedback — the goal is to catch problems and approve or redirect before a revision. Both are useful; the right time for a client review is before a usability study, not after.
- How many rounds of prototype review is normal?
- Two to three revision rounds is typical for a first build — one for the flow, one for layout and copy, and sometimes one for polish. More than three rounds on the same feature usually means the first round of feedback wasn't specific enough, or the concept was in flux when the prototype was built.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.