The companion organizes a 40-minute critique, filters four typed feedback records and compares written specifications A and proposed B. Switching to B marks the older A comments for recheck. An availability toggle demonstrates how missing design material pauses the discussion. The next step is to inspect the proposed return path.
Scope one task before collecting feedback
This original example reviews a fictional volunteer sign-up flow. Goal G1 is: review and edit earlier-entered details after seeing the volunteer role.
The written specification for prototype A has Step 1 for name/email and Step 2 for role selection, with no Back control. Proposed prototype B adds a Back control with preserved Step 1 fields. These are written design specifications, not rendered screenshots or executed usability tests.
Before a real critique, send participants the design and identify its version and the task to review. If they cannot see the design, use the time to clarify the missing material and reschedule the design judgment.
Nielsen Norman Group's critique guidance supports defining scope, supplying designs before discussion, keeping time, relating feedback to goals and documenting follow-up. For the volunteer flow, the schedule below reserves five minutes to read back the next work.
Use a 40-minute agenda that leaves time for readback
| Minutes | Segment | Required output |
|---|---|---|
| 0–5 | Scope and evidence check | G1, version and artifact availability |
| 5–13 | Walkthrough | What A specifies, with source references |
| 13–25 | Goal-linked feedback | Typed feedback rows tied to G1 |
| 25–35 | Triage | Propose, Test or Defer plus unresolved evidence |
| 35–40 | Readback | Named next work and required confirmation |
The durations are 5 + 8 + 12 + 10 + 5 = 40. Do not use all 40 minutes for discussion and then add a readback outside the timebox. Park a larger question with its source and proposed follow-up rather than dropping its uncertainty from the record.
Separate what the specification says from what users might do
Give each comment a short ID and distinguish observations, hypotheses, questions and proposed changes:
| ID / type | Version and goal | Statement | Evidence status |
|---|---|---|---|
| O1 / Observation | A / G1 | A's written specification has no Back control | Supported by the supplied fictional A specification |
| H1 / Hypothesis | A / G1 | A user may need to revise a name after seeing roles | Untested; no participant observation supplied |
| Q1 / Question | A / G1 | What happens to Step 1 values during a return? | Needs artifact behavior and test evidence |
| C1 / Proposed Change | Proposed B / G1 | Prototype Back with preserved Step 1 fields for review | Proposal; no approval or tested usability supplied |
O1 is not evidence that real users failed. H1 is not an observed problem count. C1 describes the next design exploration; it does not authorize a production release.
Keep the evidence source ID in each row. If A changes, earlier feedback stays attached to the older version and becomes pending recheck for the new one. Do not silently transfer an observation to B just because the flow has the same title.
Choose the next design task
Use Propose when you want to explore a revision, Test when the next question needs a prototype or observation, and Defer when it falls outside this critique. The buttons stage those labels; discuss ownership with the team afterward.
For C1, prepare a prototype of B that returns to Step 1 with the earlier values preserved. In the next review, try changing those values after selecting a role and compare that experience with G1.
At readback, name the version and the next question: does the proposed Back control return to Step 1 with the earlier values intact? Agree who will prepare or test that behavior. The sample buttons label next work; they do not record anyone accepting that assignment.
Use the typed review
Start with version A and inspect O1, the observation that its supplied written specification lacks Back. Filter Hypothesis to see H1 without treating it as a participant result. Choose proposed B to inspect the suggested return path and preserved fields; the older A rows remain attached to A and require recheck before reuse.
Toggle Artifact unavailable to see the evidence hold. Restore availability before discussing whether the specification addresses G1. The triage labels describe next work. Propose, Test and Defer do not confirm a person’s ownership, a usability outcome or a release decision. Confirm the owner and the next review date with your team after choosing the work.
Copy this prompt
Build a design meeting companion for a fictional volunteer sign-up flow. The page should help participants compare written specifications and discuss feedback during a forty-minute critique. It is not an interactive sign-up prototype.
Use goal G1: review and edit earlier-entered details after seeing a volunteer role. Specification A has Step 1 for name and email and Step 2 for role selection, with no Back control. Proposed B adds Back and preserves the earlier fields. Place Version A and Proposed B buttons beside the specification and an artifact-availability toggle.
Show the agenda as 5 minutes for scope, 8 for walkthrough, 12 for feedback, 10 for triage and 5 for readback. Below it, display four feedback cards. O1 is an observation about A's missing Back control. H1 is an untested hypothesis that a user may need to revise a name after seeing roles. Q1 asks what happens to Step 1 values on return. C1 proposes prototyping Back with preserved fields in B.
Add All, Observation, Hypothesis, Question and Proposed change filters. Filtering changes visibility only. When B is selected, mark A comments as historical and needing recheck. Do not present the written B specification as a tested user result.
Propose, Test and Defer buttons label next work. Leave actual owner confirmation and outcomes unrecorded. When the artifact is unavailable, show an evidence hold and prevent triage from implying a design judgment. Reset restores A, all comments and availability.
Return one self-contained HTML file with a clear agenda, roomy feedback cards, readable labels and a responsive stacked layout. Use click handlers for the controls.
Rehearse the readback
Filter to Question and read Q1 aloud: what happens to the earlier values on return? Then choose Proposed B and identify the behavior that still needs to be tried in a prototype. NOS can render the HTML companion for this critique rehearsal. Finish by agreeing who will prepare the return path and what the next review should observe.