Prepare the website prototype review before sharing the link.
A useful review also records which parts are still sketches and which decisions are ready to approve. Without that frame, feedback often becomes a collection of color preferences and conflicting instructions.
State what the prototype demonstrates: perhaps homepage hierarchy, service navigation, a contact flow, or a mobile menu. Name what is not yet built, such as final copy, live forms, integrations, or responsive edge cases. A reviewer who thinks every visible element is finished may criticize a placeholder or assume a click will trigger a real workflow.
Give each person the same short set of tasks. Ask them to find a service, explain what it includes, locate a relevant industry page, or begin an inquiry. Include at least one phone-sized review if that is a common way customers visit. A prototype can reveal confusion in the page order even before the visual details are final.
Observe first, discuss second.
Let a reviewer attempt the task without a designer narrating the interface. Note the first click, pauses, backtracking, and any words the reviewer uses to describe a section. Then ask what they expected to happen. A task that succeeds only after someone explains the design has not yet succeeded for a new visitor.
Separate the observation from the proposed fix. “I could not tell which service was for my situation” is evidence. “Put six equal cards above the fold” is one possible solution. Record both, but solve the observed problem before committing to the suggested layout. The design team may have a simpler route that preserves the whole page system.
Collect feedback in one decision record.
Ask stakeholders to identify the page, task, issue, evidence, and severity. Name who can approve the final choice. A business owner may decide offer accuracy, a content owner may verify claims, and a designer may choose the implementation that meets the approved direction. If everyone can independently override every detail, the prototype will not converge.
Group feedback by visitor impact. A broken route to contact is more urgent than a preferred corner radius. An inaccessible control is a blocker. An unsupported client result must be removed or sourced before approval. Capture taste differences too, but do not let them hide functional or factual gaps.
Review the right fidelity at the right time.
A wireframe can test order and meaning. A visual prototype can test hierarchy, brand direction, and interaction concepts. A working build can test actual responsive behavior, keyboard focus, form routing, loading, and content editing. Do not ask a static design file to prove implementation quality it cannot show.
When the work reaches a functioning build, move from prototype feedback to the website pre-handoff QA checklist. That later check tests delivery and ownership, not only the design direction.
When feedback changes the approved page structure, revisit the acceptance criteria and the affected template family. A seemingly small change to a shared component may alter dozens of pages. Identify that impact before treating the comment as a one-page tweak.
Close the loop with a decision.
At the end, record what passed, what will change, who owns the change, what evidence will show it worked, and what remains intentionally open. Send reviewers the revised artifact and decision record, not a fresh blank request for reactions. One focused second look should test the changes, not restart the entire direction debate.
If you need a clearer review process, UI/UX design can define task-based feedback and web design can turn an approved direction into page families. Talk to a Specialist about the visitor task your current prototype has not made clear.
