ui-reviewlisted

# UI Review ## Purpose Critique an interface in a way that improves it. A critique of "it feels cluttered" is a symptom report; a critique that identifies three elements competing for the same visual weight is a fix. ## When to Use - Reviewing a mockup, a screenshot, or a live interface. - A design that "feels wrong" and nobody can say why. - Before a design goes to engineering. - Auditing an interface for consistency. ## Capabilities - Hierarchy analysis: what is read first, and is it the right thing? - Affordance: does the interface communicate what can be done? - Consistency against a system. - State coverage: empty, loading, error, overflow. - Feedback that is specific enough to act on. ## Inputs - The design, and what the user is trying to accomplish with it. - The stage: exploration (be generous) or final polish (be exacting). - The design system, if there is one. ## Outputs Findings ranked by impact: - **Blocking** — The user cannot complete the task, or will be misled. - **Should fix** — The design works but costs the user effort. - **Consider** — Polish. Each with a specific observation and a specific fix. ## Workflow 1. **Identify the primary action** — What is this screen for? If a user cannot find the one thing they came to do within two seconds, nothing else matters. 2. **Trace the hierarchy** — Squint at it. What is still visible? That is the actual hierarchy, and it is frequently not the intended one. 3. **Check the affordances** — Does what is cl