BoardSnap is an iOS app that reads whiteboard photos and produces clean summaries and action items in about ten seconds. This design review template structures the formal gate between design and engineering — requirements coverage, open issues, a structured decision, and handoff action items — on a whiteboard that BoardSnap documents.
Use this at the end of a design phase, before handing off to engineering. The design review is a gate — it produces a binary decision: this design is ready to build, or it isn't. It's distinct from a design critique (which is exploratory) and is the final quality check before a design becomes code.
Budget 45–60 minutes. Reviewers should be: the product owner, an engineering representative, and at least one designer who didn't create the design being reviewed.
Two columns: requirements from the spec or user stories on the left, coverage status on the right (covered / partially covered / not addressed). For each requirement, the reviewer verifies the design addresses it. Requirements not covered become action items before the design can be approved.
Write the edge cases that must be designed for: empty states, loading states, error messages, timeout handling, and accessibility requirements. For each: is it designed? Write yes, partial, or missing. Missing edge cases don't get to engineering — they come back as bugs.
Write every question, inconsistency, or design gap identified during the review. For each open issue: is it a blocker (must be resolved before engineering starts) or a non-blocker (can be resolved in parallel)? Classify every issue before the review closes.
The review produces one of three decisions: Ship (design is ready, no blockers), Revise and Re-review (design has blockers that require another review pass), or Revise and Ship (design has non-blockers that can be resolved without another full review). Write the decision on the board. Get verbal agreement from all reviewers.
If the decision is Ship or Revise and Ship: write the handoff action items. Which assets need to be prepared? Which specs written? Which open issues need to be resolved by whom before engineering starts? Every handoff item has an owner and a date.
Share the design file 24 hours in advance. Reviewers should arrive with notes. The review should not be the first time reviewers see the design — first-time viewing produces reactive feedback, not systematic review.
Read each requirement aloud. As a group, determine whether the design addresses it. Write the status. Don't interpret 'partially covered' as 'good enough' — if it's partial, name specifically what's missing and whether it's a blocker.
Don't assume edge cases are covered because they weren't mentioned in the design walkthrough. Go through the edge case list on the board and verify each one. Empty states and error states are the two most common gaps — check these first.
This is the review's most important discipline. An unclassified open issue will become a vague 'follow-up' that delays engineering. Every issue is either a blocker or it isn't — make the call.
Read the decision out loud. Ask everyone in the room: 'Do you agree?' If one person disagrees, the decision is Revise — not Ship. Write the decision on the board before anyone leaves.
BoardSnap reads requirements coverage, edge cases, open issues, the decision, and handoff action items. The output is the formal design review record — the decision is documented, blockers are listed, and handoff items are dated tasks.
Design review decisions made in a meeting and written in a document two days later are decisions that get revised. A design review decision made at a whiteboard, written in the room, and snapped with BoardSnap is a decision that's documented before anyone's memory rewrites it.
The BoardSnap output is the review record. It's shareable, dated, and specific — the decision, the blockers, and the handoff items are all there. Engineering doesn't start until the record exists.
A design critique is iterative and exploratory — it happens during the design process and guides the next iteration. A design review is a formal gate — it happens at the end and produces a ship/revise/reject decision. Critique is open-ended; review is decisive. You may run five critiques during a design process and one formal review at the end.
The product owner must approve. An engineering lead must confirm the design is buildable as specified. An accessibility specialist should verify edge cases for inclusive design. The designer who created the work should be present to clarify decisions but does not approve their own work — that's a conflict of interest.
That disagreement is itself a blocker. If the PM says it's not a blocker and the engineering lead says it is, the engineering lead's judgment about buildability is the deciding factor. If the product person says a requirement isn't covered and the designer thinks it is, get a third opinion from a neutral reviewer before calling the decision.
The free tier includes one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on each review board.
No exporting, no transcription. Snap the board, get the action plan.