The short answer
A focused prototype review gives reviewers one task, a fixed build, and specific questions. Use the time to observe the flow, identify blockers, and decide the next changes. The 15-minute agenda below is a suggested format to adapt, not a promise that every review fits that time.
1. Prepare one task and a stable build
Choose the decision this review should inform. “Can a first-time owner invite a teammate?” is focused enough to explore. “What do you think of the app?” invites a broad inventory of preferences that may be hard to act on in one session.
Share a build link, fictional sample data, and the starting state. Record a build identifier or commit when available. Avoid changing the prototype during the session: comments on two different versions can sound contradictory even when both observations are accurate. Note simulated behavior before anyone starts.
Review goal: can a first-time owner invite a teammate?
Build: [review URL and version]
Start: project overview with no teammates
Task: invite a teammate and explain how you know it worked
Questions: is the action clear; can an invalid email be corrected?
Simulated: the prototype does not send real invitations
Output: agreed blockers, owner, and next review point2. Use the time to observe and decide
As a starting agenda, spend two minutes aligning on the task and prototype limits, seven minutes observing the flow, four minutes grouping issues, and two minutes agreeing on next steps. Adjust the allocation to the task; a complex workflow may need a longer session.
Let the reviewer attempt the task before explaining the interface. Record where they hesitate and what they expected to happen. If the facilitator supplies every next step, the session mostly tests the facilitator’s explanation. Ask neutral follow-up questions that help distinguish a confusing label from a missing capability.
- Minutes 0–2: confirm the task, audience, and prototype boundaries.
- Minutes 2–9: attempt the flow and capture observations.
- Minutes 9–13: distinguish blockers, questions, and lower-impact polish.
- Minutes 13–15: assign decisions, owners, and a follow-up build.
3. Separate observations from proposed solutions
Capture what happened before debating the fix. “The reviewer selected Cancel while trying to continue” preserves evidence. “Make the button blue” is one possible response. The decision may instead involve wording, order, hierarchy, or a missing explanation.
Keep unresolved product questions visible. A prototype review can reveal a confusing permission model, but it cannot settle the business rule by changing the screen alone. Assign someone to resolve that rule before asking a builder or coding agent to implement a visual workaround.
4. End with a small accepted change set
Choose the changes that matter for the next build and assign a review owner. Include the affected screen, the intended outcome, and an observable check. Park unrelated ideas in a separate list so the accepted work retains a clear scope.
If you use CRRT, review the collected visual comments and hand the accepted corrections to your coding agent. After implementation, repeat the original task on the new build. A useful follow-up states what changed, what was checked, and which question the team will review next.
Common questions
Can this agenda replace user research?
No. It structures a focused prototype review. It does not establish that the reviewers represent your users or that the findings generalize to a wider population.
What if the review uncovers more work than the time allows?
Record the remaining observations and choose a narrower next decision. Extend or schedule another session when the flow needs deeper investigation.
Sources & further reading
Written with AI assistance. Tool references checked against the linked documentation on November 2, 2026. Examples are starter templates to adapt and review in your own project.