---
name: figma-ui-audit
description: Review a specified Figma frame or component system and produce traceable UI findings. Use for hierarchy, spacing, typography, component consistency and accessibility design reviews.
---

# Figma UI audit

Draft v0.85 by Mukund Sharma. Review criteria and the findings contract are written; connected-file calibration and edge-case evaluation remain in progress.

## Establish scope and access

Use the supplied file and node as the review boundary. Read the selected frame and relevant components through the available Figma integration. If access is unavailable, state the limitation and use supplied screenshots only for observations they support. Do not infer variable bindings, component usage or interaction behavior from pixels.

## Inspect three tracks

1. Interface: identify the primary task, reading order, typography, alignment, spacing and action hierarchy. Compare similar elements before calling a difference inconsistent.
2. System: inspect available component, variant, variable and token evidence. Distinguish deliberate exceptions from accidental drift. Missing access is not evidence that a design system does not exist.
3. Access: assess available contrast evidence, text sizing, target dimensions and proposed focus/error states. Runtime semantics, keyboard behavior and reflow require implementation checks; mark them unverified in a Figma-only audit.

## Produce actionable findings

For each issue provide a stable finding ID, exact frame/component or node reference, observed evidence, user impact, severity and a concrete recommendation. Rank blockers to task completion before visual polish. Keep preferences separate from usability issues. Avoid duplicating one root issue across many components; list the affected instances under one finding.

## Review before reporting

Check whether the proposed fix preserves the component's intended variants and other states. Flag uncertain findings for inspection. Do not make file edits unless the user requests implementation. A read-only review does not authorize changing the source design.

## Output contract

Begin with the overall task risk, then provide prioritized findings and a short list of checks that need runtime or missing-file evidence. Each finding must identify its location, severity, evidence, impact and recommended action. End with what is already working when that helps the reviewer preserve it.

## Draft validation still pending

Calibrate severity against reviewed examples, inspect large nested component systems and test incomplete-access handling. Do not present this draft as a validated accessibility or compliance audit.