0–5 min: classify the artifact
Decide whether the artifact is a sketch, exploration, system candidate, or engineering-ready spec.
Success checkNo one confuses ideation with implementation authority.
Design handoff guide · Updated 2026-06-28
Design QA Checklist: States, Responsive Specs, Accessibility, Assets, Tokens, Copy, Handoff, and Engineering Acceptance
A review checklist for deciding when a sketch, Figma frame, Penpot file, Sketch document, or DESIGN.md spec is ready for engineering handoff instead of another round of design polish.
Design QA fails when teams wait until implementation to discover missing states, ambiguous spacing, unowned assets, inaccessible colors, missing content rules, or stale token names. The fix is not a longer Figma comment thread; it is a shared acceptance checklist that designers and engineers can review before code starts.
This guide connects Excalidraw-style ideation, Figma Dev Mode, Penpot design tokens, Sketch handoff, and DESIGN.md-style agent-readable specs into a single gate: prove that the design artifact has enough states, constraints, tokens, content, assets, accessibility notes, and owner decisions to be safely implemented.
RepoDaily verdict
A design is engineering-ready when a developer can implement one component or flow without guessing. The QA gate should expose missing states, responsive behavior, accessibility constraints, token names, asset ownership, copy rules, and rollback decisions before the design becomes a ticket.
RepoDaily fixture evidence: fake handoff packet QA test
This is not a benchmark of Figma, Penpot, Sketch, Excalidraw, or any design tool. RepoDaily created a fake local design handoff packet to check whether the Design QA Checklist catches missing states, responsive rules, accessibility notes, token drift, asset metadata gaps, copy/localization gaps, acceptance-criteria gaps, and artifact classification before engineering starts.
| Evidence item | Fixture result | Why it matters | Limitation |
|---|---|---|---|
| Local handoff QA fixture | 8/8 expected QA checks passed. | Validates the checklist mechanics, not a vendor or design-tool ranking. | Small fake JSON handoff packet only; no real design file is imported. |
| State and responsive gaps | The incomplete packet misses hover, focus, disabled, loading, error, empty, success, tablet, and mobile; the fixed packet covers them. | A design should not become an engineering ticket when core states or viewports are implied. | The fixture checks metadata fields, not rendered screenshots. |
| Accessibility gaps | The incomplete packet misses focus order, keyboard behavior, labels, touch target, and reduced-motion notes; the fixed packet adds them. | Accessibility needs to be reviewed before implementation, not after code exists. | No automated WCAG scanner or browser test is run. |
| Token and asset gaps | The fixture flags raw hex/pixel values and missing icon owner/license/alt/export metadata, then verifies the fixed packet uses tokens and asset metadata. | Design QA must turn visuals into implementation-safe contracts. | Uses fake token names and a fake SVG asset. |
| Copy and acceptance criteria | The fixture flags missing error, empty, success, localization, and review criteria, then generates an acceptance checklist. | Engineers and coding agents need explicit stop conditions instead of “match design.” | Does not test a real product API or analytics implementation. |
- Read this as a RepoDaily self-test of the Design QA Checklist, not as a benchmark of any design tool.
- The test supports the page recommendation: design QA should catch missing states, responsiveness, accessibility, tokens, assets, copy, and acceptance criteria before engineering starts.
- The evidence is intentionally local and fake, so it proves checklist sanity rather than full design-system readiness.
Quick matrix
| QA surface | What to inspect | Good signal | Failure signal |
|---|---|---|---|
| States | Default, hover, focus, active, disabled, loading, error, empty, success | Every interactive element has named states and examples | Only a happy-path desktop frame exists |
| Responsive behavior | Breakpoints, reflow, min/max widths, truncation, density, device class | A developer can predict layout changes without asking the designer | Mobile and tablet behavior are implied but not drawn |
| Accessibility | Contrast, focus order, keyboard behavior, labels, touch target, motion, reduced motion | WCAG-relevant decisions are visible next to the design artifact | Color and motion choices are aesthetic only |
| Tokens and styles | Color, typography, spacing, radius, shadow, icon, motion tokens | The artifact cites token names or approved style names | Raw hex values and manual measurements drive implementation |
| Assets | Icons, images, logos, fonts, illustrations, alt text, licensing, export size | Assets have owner, export format, and usage context | Developers screenshot or manually crop assets |
| Copy and localization | Error text, empty-state text, labels, dates, currency, pluralization, truncation | Content rules are tied to states and locales | Copy is placeholder text in the final ticket |
| Engineering acceptance | API assumptions, data states, events, analytics, error boundaries, test cases | Design handoff includes acceptance criteria and stop conditions | The ticket says “match design” and nothing else |
Design QA readiness scorecard
Score one real component or flow before engineering handoff.
| Control | 0 points | 1 point | 2 points | Owner question |
|---|---|---|---|---|
| State coverage | Happy path only | Some states shown | All critical states named and reviewed | Which state is most likely to be missed in code? |
| Responsive rules | Single desktop frame | Mobile sketch exists | Breakpoints and reflow rules are explicit | What happens below the narrowest supported width? |
| Accessibility review | Not checked | Color contrast only | Contrast, focus, keyboard, labels, motion, and touch targets reviewed | Which WCAG risk is still unresolved? |
| Token alignment | Raw values only | Some style names | Approved tokens/styles are cited and exportable | Which token names should code consume? |
| Asset readiness | Assets embedded in mockups | Some exports attached | Asset formats, sizes, licenses, and owners are documented | Who owns asset updates after launch? |
| Acceptance criteria | Ticket points at design | Some notes in comments | Engineering-ready criteria and test cases are attached | What would make this implementation fail review? |
30-minute design QA test plan
Use this before sending a design artifact to engineering.
5–10 min: state pass
List every missing default, hover, focus, disabled, loading, error, empty, and success state.
Success checkThe critical state gaps are visible.
10–16 min: responsive and accessibility pass
Check breakpoints, reflow, contrast, focus, keyboard, labels, motion, and touch targets.
Success checkThe design has named accessibility and layout decisions.
16–22 min: token and asset pass
Record token names, style names, assets, export formats, licenses, and owners.
Success checkA developer does not need to copy raw values or crop assets manually.
22–30 min: implementation rehearsal
Ask an engineer or coding agent to explain the implementation steps and questions before code starts.
Success checkClarification questions become concrete QA fixes or acceptance criteria.
Design QA decision flow
- Start with one component family or user flow, not a whole product redesign.
- Classify the artifact: sketch/idea, design exploration, design-system candidate, or engineering-ready spec.
- Run the state checklist first; missing disabled, loading, empty, and error states are the fastest way to block implementation.
- Review responsive behavior, accessibility constraints, token names, assets, copy, and analytics before engineering starts.
- Ask one engineer to implement the smallest slice from the artifact; every clarification question becomes a QA defect.
- Promote the artifact only when the implementation criteria, owner, rollback path, and follow-up changes are explicit.
Scenario table
| Scenario | Minimum QA checklist | Stop if |
|---|---|---|
| Excalidraw sketch to product design | Translate the sketch into named components, flows, data states, and token candidates before implementation. | The sketch is still being treated as a production spec. |
| Figma frame to engineering ticket | Use Dev Mode/handoff artifacts, components, styles, comments, state variants, and acceptance criteria. | The engineer must infer behavior from static screenshots. |
| Penpot self-hosted design system | Check component naming, tokens, export fidelity, backups, and developer inspect workflow. | Self-hosting is solved but design QA still depends on tribal knowledge. |
| Sketch handoff to web implementation | Verify browser-based inspect, asset export, text styles, color variables, and token download expectations. | Mac-only design context blocks non-Mac engineering review. |
| DESIGN.md for coding agents | Convert design rules into explicit constraints and examples that an agent can cite while coding. | The spec is stale or conflicts with the current design file. |
| Design token change review | Run the token export checklist and show affected components, modes, and rollback path. | Token rename impact is unknown. |
Design QA risks
Happy-path bias
Teams review the prettiest frame and skip error, empty, loading, disabled, and focus states.
Responsive guesswork
Engineers invent breakpoints because design files only show one viewport.
Accessibility afterthought
Contrast, focus order, labels, keyboard behavior, and motion sensitivity are checked after code exists.
Token drift
A design looks consistent but uses raw values that do not map to production tokens.
Asset ambiguity
Icons, fonts, image crops, and illustrations ship without ownership or license review.
Agent misimplementation
Coding agents can implement stale or under-specified design rules with confidence if the spec is not explicit.
Implementation patterns
One-slice handoff
Run the checklist on one component family or flow before scaling it to the entire design system.
Clarification log
Every engineer question during implementation becomes a new QA item for the design artifact.
State table before ticket
Attach a state matrix to the ticket before code starts; do not let states live only in comments.
Token and asset manifest
List token names, asset names, export formats, licenses, and owners next to the design.
Accessibility notes beside visuals
Put contrast, focus, keyboard, and motion decisions beside the artifact, not in a separate forgotten doc.
Agent-ready spec mirror
Mirror final QA decisions into DESIGN.md-style instructions if coding agents will implement the change.
FAQ
Short answers for design and engineering teams preparing handoff.
Is Design QA the same as visual polish?
No. Visual polish asks whether a design looks finished. Design QA asks whether it can be implemented without guessing.
Where should Design QA live?
Close to the artifact and ticket: state table, token names, asset manifest, accessibility notes, and acceptance criteria should be reviewable together.
Can an Excalidraw sketch pass Design QA?
Usually no. It can start the conversation, but production handoff needs states, tokens, responsive rules, assets, content, and acceptance criteria.
How does this help coding agents?
Agents need explicit design constraints. A QA checklist reduces hallucinated spacing, stale tokens, missing states, and unsupported interactions.
Related radar
Related RepoDaily briefs
Penpot: Open-Source Design Collaboration Built for Designers and Developerspenpot/penpot · Design / Creative appFigma Explained: Collaborative Product Design, Design Systems, Plugins, and Developer Handofffigma/rest-api-spec · Design / Creative appSketch Explained: macOS-Native Product Design, Local Files, Plugins, and Developer Handoffsketch-hq/SketchAPI · Design / Creative appExcalidraw Explained: Open-Source Whiteboarding for Diagrams, Sketches, and Embeddable Visual Workflowsexcalidraw/excalidraw · Design / Creative appDESIGN.md: A Design System Format Built for AI Coding Agentsgoogle-labs-code/design.md · Library / Framework
Sources
Feedback
Did this page help you make a decision?
Anonymous feedback helps RepoDaily improve what is actually useful.