Agree what the prototype is intended to answer
A low-detail prototype may test navigation and page structure, while a more detailed one can explore interactions. State the questions before the review so missing visual polish is not mistaken for missing functionality. Give reviewers a realistic task and enough context to understand the user, rather than presenting disconnected screens without a scenario.
Follow the task without explaining every step
Ask the reviewer what they would do next and what they expect to happen. Observe where labels or hierarchy create uncertainty. If the designer has to narrate every action, record that as a question to investigate. The session is more useful when it reveals the reader’s interpretation than when it becomes a guided demonstration of the intended path.
Review alternate and failure states
Look beyond the ideal completed screen. Ask what appears when there are no records, information is missing or an action cannot be completed. Check how someone returns to a previous step or corrects a choice. These questions can expose product decisions that need agreement before development, even if the prototype does not simulate every state.
Convert feedback into decisions
Separate observed task difficulties from individual visual preferences. Record the issue, its effect and the agreed next action. Name an approver for unresolved business rules. Recheck important changes using the same task so the team can tell whether the revision helped. A prototype review should reduce uncertainty, not simply generate a longer list of opinions.
Your practical checklist
- State the questions the prototype should answer
- Observe an unguided realistic task
- Discuss empty, error and alternate states
- Record decisions and retest important changes
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK