---

name: figma-design-qa description: "Runs a pre-handoff QA checklist on a Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, or validate a Figma file is ready to build. Produces a structured QA report covering file hygiene, component usage, accessibility, and handoff readiness with explicit pass/fail status per item. Optimised for Opus 4.7 and newer models."

Figma Design QA Skill

Runs a systematic pre-handoff QA check on a Figma design — catching issues that cause engineering back-and-forth before they become expensive.

Not quite this? Use figma-design-brief when the design does not exist yet and needs a brief; use figma-design-review when you want a holistic design review rather than a check against the spec; use figma-design-critique-pm when you are judging product outcomes rather than implementation fidelity.

Required Inputs

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).

• Feature or screen being QA-d (describe what has been designed)
• Platform (iOS / Android / Web)
• Design system (custom / Material / HIG / None)
• Handoff tool (Figma Inspect / Zeplin / Storybook / Direct link)
• QA depth (quick 15 min / standard 30 min / thorough 60 min)

Programmatic Helper

Contrast ratios cannot be eyeballed. The AA line sits at 4.5:1, and #777777 on white is 4.478 (fails) while #767676 is 4.54 (passes) — no amount of looking at a screenshot separates those. Compute them:

npx --yes notugly fix "#8ab4f8" "#ffffff"     # ratio, APCA, and the nearest passing colour
npx --yes notugly onepager <url> --out review.html   # every pairing, printable
npx --yes notugly vision                      # which colours merge for colour-blind viewers

notugly fix returns the ratio, the APCA lightness contrast, and the closest colour to the one already chosen that passes — same hue, same chroma. Paste those numbers into the tables below rather than estimating them.

Deterministic, zero dependencies, and no model call — so it costs nothing to run and gives the same answer every time.

QA is a pass/fail activity, so every contrast row needs a number and a verdict. For a deployed build, npx notugly check <url> exits non-zero on a failure, which makes it usable directly in CI rather than only by hand.

Output Structure

QA Report: [Feature] | [Date] | [Platform] Overall status: Ready / Minor fixes needed / Not ready

Section 1: File Hygiene

• All layers named semantically (no "Rectangle 12")
• No unused/hidden layers in final frames
• Components from library (not detached copies)
• All text uses text styles (not manual font settings)
• All colours use styles or variables (not hex overrides)
• Frames named to match screen map
• No leftover prototype wires to wrong frames

Section 2: Component Usage

• All buttons use library component
• All inputs use library component
• All icons from approved icon library
• No custom components that should be in library
• Variants used correctly (right size, state, type)

Section 3: Content and Copy

• No placeholder text (Lorem ipsum) in final designs
• All copy reviewed and approved
• Realistic content used (not "User Name")
• Long text edge cases tested
• Error messages are human-readable
• Empty states have copy and CTA

Section 4: States and Coverage

• Default, Loading, Empty, Error, Success states
• Interactive elements have hover/active (web)
• Disabled states designed where applicable

Section 5: Accessibility

• All text meets WCAG AA contrast (4.5:1 body, 3:1 large)
• UI components meet 3:1 contrast against background
• Touch targets minimum 44x44pt iOS / 48x48dp Android
• Focus states for keyboard/switch navigation (web)
• Information not conveyed by colour alone
• Icons have text labels or accessible names annotated

Section 6: Handoff Readiness

• Dev annotations on non-obvious interactions
• Spacing uses Auto Layout (not absolute positioning)
• Images/assets exported at correct resolutions
• Design matches approved requirements
• Link to prototype included

Issues Found

For each fail: [Issue] — Blocking / Fix before handoff / Fix in next iteration

• What: [Specific layer/screen/element]
• Fix: [Exact action needed]
• Owner: [Designer/PM/Both]

Handoff Decision

Status, signed off by, date.

Quality Checks

• All 6 sections completed
• Every fail has a specific description and fix action
• Blocking issues separated from minor ones
• Handoff decision is explicit

Anti-Patterns

• Do not produce a partial QA — every checklist category must be evaluated, not just the ones that are obviously problematic
• Do not leave the handoff decision ambiguous — the output must explicitly state pass, pass with conditions, or fail
• Do not skip accessibility checks — colour contrast, tap target size, and screen reader labels are required, not optional
• Do not report issues without specifying which screen or component they appear on
• Do not approve a design if any component is detached from the library without a documented reason

Example Trigger Phrases

• "QA this Figma design before handoff"
• "Run a pre-handoff check on [feature] design"
• "Is this Figma design ready for engineering?"
• "Do a design QA on [screen/feature]"
• "What needs fixing before we hand this off?"