DESIGN TOGETHER
A design review checklist for product teams
A useful design review ends with a decision, an owner and a clear next step. Use this checklist to review a wireframe or interface against the user’s task, rather than collecting disconnected opinions about how it looks. It is a practical team worksheet, not a substitute for usability testing or an accessibility audit.
30-day complimentary access · no card required · secure email verification1. Set the question before sharing the screens
Write one decision the review must resolve: for example, whether an invited teammate can identify the project they are joining before accepting an invitation. Name the intended user, their starting point and what success looks like. State the design stage and constraints, including the device, permissions and any known technical limits.
Ask reviewers to inspect the same version. Separate decisions that are open from choices already constrained by the brief. Bring research or support evidence when you have it; label assumptions when you do not. A screenshot alone cannot explain the whole journey.
2. Review the task and every important screen state
Can a user tell where they are, what they can do and what happens next? Check the main action, the information needed before choosing it, and the route back if they change their mind. Read labels without relying on the designer’s explanation.
List the initial, loading, empty, success and error states that apply. Review long names, missing images and realistic content rather than only ideal sample data. For an invitation journey, check an expired link, an already accepted invitation and a signed-in account that does not match the invite. These are hypothetical review cases; choose states that fit your own product.
3. Include accessibility and narrow-screen checks
Check whether the task remains understandable on a narrow screen and with longer text. Confirm that essential information is not conveyed by colour alone, controls have clear names, and errors explain both the problem and a recovery action. Consider reading order, visible focus and where focus should move when a dialog opens or closes.
A wireframe can record these requirements, but it cannot prove that keyboard navigation, screen readers, contrast or zoom work in the implementation. Record those as checks for the working interface and include people who use assistive technology in research where possible. Do not mark accessibility complete on visual inspection alone.
4. Turn feedback into a decision record
Capture feedback as an observation, its consequence for the user and a proposed next step. “The project name is hidden until after acceptance, so the user cannot confirm the destination” is more actionable than “make this clearer.” Keep personal preferences separate from evidence and requirements.
Classify each item as a blocker, a question needing evidence or a later improvement. Assign an owner and a due date to work that will proceed. If reviewers disagree, record the competing assumptions and decide what prototype or user task could test them. Avoid silently treating a lack of comments as approval.
Copy this review record
Review question:
User and task:
Design version or link:
Evidence available:
Assumptions to test:
States checked:
Accessibility and responsive checks still needed:
Decision: proceed / revise / test first
Reason for the decision:
Action, owner and due date:
Open risks and next review date:
For example, a team reviewing a hypothetical invitation screen might decide to show the project name before acceptance, assign the content change to the designer, and test whether a new participant can identify the destination. That is a planned evaluation, not proof of a successful outcome.
YOUR NEXT WORKSPACE
Start with a worked onboarding journey
Use the flow-to-wireframe guide to prepare a concrete example before your next review. Then apply the checklist above to the decisions and recovery paths in that journey.
Read the onboarding guideYOUR NEXT WORKSPACE
Explore wireframing in Kanvixo
See how user flows and screen layouts fit into a shared product-design workflow. Review the available tools before deciding how to organize your team’s next project.
Explore online wireframing