Design Review Template for User Research

At minimum, once per project at the wireframe stage and once at high-fidelity. For complex features, add a concept review early (before wireframes) and a final review before handoff. Teams running weekly design syncs can fold reviews into that cadence. The goal is incremental feedback, not a single high-stakes presentation. The [design sprint template](/templates) builds reviews into each day of the sprint.

The designer, the PM, and one engineer who will build it. Optionally add a second designer for peer critique and a QA engineer for edge case spotting. Keep the group to 3-6 people. Larger groups produce less useful feedback because individuals feel less responsibility to contribute.

Three rules: (1) feedback must reference user impact, not personal preference, (2) the facilitator redirects "I don't like..." to "What problem does this cause for the user?", and (3) decisions are logged and owned, so disagreements are resolved with clear accountability rather than circular debate.

Include stakeholders only at concept or final review stages. Including them at wireframe stage invites premature commitment to visual details. At concept stage, they validate the problem framing. At final stage, they approve the direction. In between, the design team needs room to explore without executive anchoring. Use the [stakeholder management guide](/stakeholder-guide) for more on managing stakeholder involvement.

A design critique is peer-to-peer feedback among designers, focused on craft quality (typography, layout, interaction patterns). A design review is cross-functional, focused on whether the design solves the stated problem within constraints. This template serves design reviews. For a pure critique among designers, you can simplify by removing the Decision Log and focusing only on the Feedback Framework. ---