---
name: dkeken/design-qa
source: https://app.decimal.ai/s/dkeken-design-qa@1/SKILL.md
source_sha256: b746939d4111
---

# Design — Design QA

Verify the built prototype actually matches the intended design + requirements. Catch drift before it ships. Unlike `design-audit` (open-ended critique of any UI), QA is a *conformance check against a known source of truth* — it answers "does this match what we agreed to build?"

## When to use
- A prototype is built and you need to confirm it matches the mockup/spec before review.
- Final gate before `design-share` or dev handoff.
- "Does it match the design?", "conformance check".

## When NOT to use
- No spec/reference to compare against → that's open critique → `design-audit`.
- Nothing built yet → build it first.

## Inputs
- The **built prototype** (local URL or path).
- The **source of truth**: reference image/mockup, `./design/context.md`, `./design/ideate/*`.
- **Acceptance/success criteria** (from context).

## Workflow
1. **Capture** the implementation via a browser-automation tool — screenshots of key screens *and* states (loading/empty/error/success).
2. **Visual conformance** — compare to the reference: layout, type scale, spacing rhythm, palette, radii/shadows, iconography. Note every drift with the expected vs actual value.
3. **Behavioral conformance** — walk the flow: do interactions, states, and navigation match the intended UX?
4. **Requirements conformance** — does it satisfy the goal + success criteria from context? Any scope item missing?
5. **Accessibility sanity** — contrast, focus order, target size, keyboard reachability (flag what needs manual AT testing — automated checks aren't full WCAG).
6. Write `./design/qa.md`: PASS items + prioritized fix list (severity × effort) + a verdict.

## Output: ./design/qa.md
```
prototype: http://localhost:5173   source: ./mocks/onboarding.png + context.md
visual:
 ✓ layout matches  ✗ body type 14px (spec 16px)  ✗ accent #7C3 (spec #6366F1)
behavior:
 ✓ happy path  ✗ no error state on empty name (spec requires inline error)
requirements (vs success criteria):
 ✓ 3-step wizard  ✓ progress saved  ✗ missing "skip" affordance (scope v1)
a11y:
 ✗ CTA contrast 3.1:1 (<4.5)   manual: screen-reader pass still required
verdict: NOT READY — 4 fixes (2 HIGH: error state, contrast). Loop to design-prototype.
```

## Quality bar
- Compared against the **locked source of truth**, not personal taste.
- Every miss cites which source it violates (mock / context / success criteria) + expected vs actual.
- A11y findings distinguish automated checks from what needs manual AT validation.
- A clear verdict: READY, or NOT READY with the blocking items named.

## Common pitfalls
- **QA by opinion** — drifting into "I'd prefer..." instead of "spec says X, build shows Y".
- **Skipping states** — only checking the happy path; error/empty/loading are where drift hides.
- **Passing HIGH drift** — don't green-light something with blocking visual/behavioral mismatches.
- **Overclaiming a11y** — automated contrast/focus ≠ full WCAG conformance; say so.

## Handoff
PASS → `design-share`. FAIL → loop the fix list back to `design-prototype` (or `design-image-to-code` for visual drift), then re-QA. Don't share stakeholder-facing prototypes with unresolved HIGH items without explicitly flagging them.

## Tooling
Needs a **browser-automation tool** to capture screens/states for comparison. Without one, do a code-level + manual review and flag that visual conformance is unverified.