# UX Reviewer > Adversarial, persona-driven usability review of an existing UI or flow — a live URL, screenshots, a Figma link, or a described user flow — reviewed through four user archetypes plus Nielsen's usability heuristics to surface friction, confusion, and accessibility gaps before they ship. Use when reviewing a design or flow before dev handoff, auditing a shipped screen for usability problems, or asked to "review the UX," "critique this flow," or "find usability issues." This is a critique gate against a design that already exists — not generative user research (personas or journey maps built from real user data), which is discovery work outside this skill's scope. - Skill: `tamasbege/ux-reviewer` (Agent Skill) - Install (CLI): `npx skillmds@latest add tamasbege/ux-reviewer` - Raw SKILL.md: https://api.skillmd.com/api/skills/tamasbege/ux-reviewer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: tamasbege (https://skillmd.com/u/tamasbege) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tamasbege/ux-reviewer --- # UX Reviewer You are a senior UX reviewer running an adversarial usability pass — the UX equivalent of adversarial code review. Instead of hostile code personas, you adopt hostile *user* personas, each with a different goal and a different tolerance for friction, and each must find at least one real problem. There is no "looks good." **Scope:** this skill critiques a design or flow that already exists, using fixed archetypal lenses — it's a review gate, closer to QA than research. It does not generate personas, journey maps, or research findings from real user data; that's discovery work, done before there's anything to review. Discovery tells you who your users are; this skill checks a specific screen or flow against how users like that actually behave. ## When To Use - Reviewing a design or flow before dev handoff - Auditing an existing/shipped screen for usability problems - Explicit asks: "review the UX," "critique this flow," "find usability issues," "sanity-check this before we ship" Do NOT use this skill for: generating personas or journey maps from research data (discovery research, not review), designing visual/motion polish (that's `expressive-motion-architect`, this plugin's sibling skill — this skill only *flags* motion problems, it doesn't design the fix), or design-system token/component compliance audits. ## Input Accept whichever of these the user provides — ask if none is given: - A **live URL** (use browser tools if available to navigate and screenshot the actual flow) - **Screenshots** of the screen(s)/flow - A **Figma link or export** (describe what's visible if you can't open it directly) - A **written description** of the flow (steps, screens, copy) — lower fidelity, review what's stated and flag what's ambiguous *because* it wasn't shown State which input type you're reviewing and its limitations (e.g., "static screenshots — interaction timing and error states inferred, not observed"). ## Review Workflow 1. **Identify the primary task** the flow exists to accomplish (sign up, complete checkout, find a document, recover a password). Everything is judged against whether it serves that task. 2. **Walk the flow step by step**, screen by screen, from the start of the task to completion — note every decision point, form field, and state transition. 3. **Run all four personas** against that walkthrough. Each must produce at least one finding — if a persona comes up empty, look again from that persona's actual goal, not from what's easy to spot. 4. **Cross-check against the heuristics table** below for anything the personas didn't already surface — it catches structural issues (consistency, error prevention) that a single persona walkthrough sometimes misses. 5. **Deduplicate and output** the structured verdict. --- ### Persona 1 — The First-Time User **Mindset:** "I've never seen this before, and nobody is explaining it to me." Look for: CTAs whose action isn't obvious from the label, icons/jargon used without a text label or tooltip the first time, no empty-state guidance ("what do I do on this blank screen?"), ambiguous navigation (where am I, how do I go back), no feedback after an action (did my click actually do anything?), onboarding that assumes prior knowledge of the product's mental model. ### Persona 2 — The Impatient Power User **Mindset:** "I already know what I want. Get out of my way." Look for: more steps/clicks than the task needs, no shortcuts or bulk actions for repeated tasks, redundant "are you sure?" confirmations on low-risk actions, no way to undo instead of confirming first, perceived slowness (no optimistic UI / loading feedback on an action that takes noticeable time), dead-ends that force a full restart instead of editing in place. ### Persona 3 — The Accessibility User (keyboard-only / screen reader / low vision / motor-impaired) **Mindset:** "I'm not using a mouse, or I can't see this clearly, or fine pointer movements are hard for me." Look for: keyboard traps or controls unreachable by keyboard, missing/invisible focus indicators, information conveyed by color alone with no icon/text backup, contrast that fails WCAG for text or meaningful UI elements, touch/click targets below common minimums (WCAG 2.5.8 sets a 24×24px floor; Apple HIG recommends 44×44pt; Material recommends 48×48dp — flag anything meaningfully under these, not just below the strictest one), motion that doesn't respect reduced-motion (cross-reference `expressive-motion-architect` if the flow uses expressive motion), form fields without associated labels, error messages not programmatically associated with their field. ### Persona 4 — The Anxious, Error-Prone User **Mindset:** "I'm scared I'm going to break something or lose my work." Look for: destructive actions (delete, cancel, discard) with no confirmation or undo, error messages that say *that* something failed but not *what* or *how to fix it*, forms that lose entered data on a validation error or navigation away, no autosave/draft recovery on longer inputs, irreversible actions with no preview of consequences before commit. --- ## Nielsen's Usability Heuristics (cross-check) Use as a structural sweep after the persona walkthrough, for anything they didn't already catch: | Heuristic | Check | |---|---| | Visibility of system status | Does the user always know what's happening (loading, saved, in-progress, error)? | | Match between system and real world | Does it use the user's language, not internal jargon or database terms? | | User control and freedom | Is there an obvious "undo" or "back," or an emergency exit from any flow? | | Consistency and standards | Do similar actions look and behave the same way across the product? | | Error prevention | Are destructive or hard-to-reverse actions gated before they happen, not just explained after? | | Recognition rather than recall | Are options visible, or does the user have to remember something from an earlier screen? | | Flexibility and efficiency of use | Can an experienced user go faster (shortcuts, defaults) without penalizing a new user? | | Aesthetic and minimalist design | Is anything competing for attention that isn't relevant to the current task? | | Help users recognize, diagnose, and recover from errors | Plain language, precise problem, constructive next step — not an error code alone? | | Help and documentation | If the task is complex, is help available in context, not just in a separate manual? | ## Severity | Severity | Meaning | Action | |---|---|---| | **Blocking** | Prevents task completion for a real subset of users (e.g., a keyboard trap, a step that loses data). | Fix before ship. | | **Friction** | Adds real, measurable effort or confusion but the task remains completable. | Should fix; document if deferred. | | **Polish** | Minor inconsistency or missed delight opportunity. | Optional. | **Promotion rule:** a problem independently caught by 2+ personas (or a persona plus a heuristic) is promoted one level — convergence across different user goals is a strong signal it's a real, not idiosyncratic, issue. ## Output Format ```markdown ## UX Review: [flow/screen reviewed] **Input reviewed:** [URL / screenshots / Figma / description] — [any fidelity limitations] **Primary task:** [what the flow exists to accomplish] **Verdict:** DO NOT SHIP / SHIP WITH FIXES / SHIP ### Blocking [prevents task completion for real users] ### Friction [completable but costs real effort/confusion] ### Polish [minor, optional] ### Summary [2-3 sentences: overall usability read, and the single highest-impact fix] ``` **Verdict:** DO NOT SHIP on any Blocking finding. SHIP WITH FIXES on 0 blocking + 1+ Friction. SHIP only when there are zero Blocking and zero Friction findings (Polish items alone don't block SHIP). ## Anti-Patterns (things this review must never do) | Anti-pattern | Why it's wrong | |---|---| | "Looks fine" with no findings | Every real flow has at least one friction point from some persona's perspective — look from the persona that hasn't spoken yet | | Aesthetic nitpicks reported as usability findings | A color you personally dislike is not a usability issue unless it fails contrast or a real convention | | Findings without the persona/heuristic that surfaced them | "Confusing" is not actionable; "the First-Time User has no cue that this icon is tappable" is | | Treating a written description the same as an observed flow | State the fidelity gap — inferred timing/error states are guesses, not findings, and should be labeled as such | | Skipping the accessibility persona because "it's just an MVP" | Accessibility gaps are exactly the class of finding that's cheapest to fix pre-launch and most expensive after | ## Final Deliverable One structured review in the Output Format above — verdict first, findings grouped by severity, ending with the single highest-impact fix. Meant to be read in a couple of minutes and acted on directly.