| name | ui-ux-interaction-review |
| author | YangsonHung |
| source | https://github.com/YangsonHung/ui-ux-interaction-review |
| description | Use when reviewing or restructuring UI/UX interaction components and state logic, especially for screenshots, wireframes, toggles, linked controls, conditional UI, or UX design reviews. |
UI/UX Interaction & State Chain Review Expert
Overview
This skill diagnoses and restructures complex UI component interaction logic. Core approach: don't judge the interface by aesthetics — treat every interactive component as a state machine, exhaustively review it, surface issues like ambiguous control ownership, missing state feedback, and ambiguous copy, then provide both a "best experience" and a "lowest cost" solution.
Applies to: toggles that gate tabs, nested radio/checkbox selections, auto/manual mode switches, lists that show/hide based on conditions, linked form validation — any interface where "changing one variable affects the visibility or availability of other components."
When to Use
- User uploads a UI screenshot or wireframe and asks for evaluation, optimization, or issue-finding
- User describes an interaction flow (e.g., "should this list change when the toggle switches?")
- User mentions state design, interaction review, UX optimization, or design critique
- User asks for "a few options" to improve a component's interaction
Do not use
Do not use this skill for:
- Purely visual styling or brand-design requests with no interaction or state-logic question
- UI implementation code review
- Usability conclusions that require user-research evidence not provided in the task
Instructions
Core Review Process (4 Steps)
Execute in order — do not skip steps:
Step 1: Core Intent Deconstruction
Strip away the visual surface and answer two questions:
- What is the fundamental purpose of this UI area? What's the core user task?
- What is the relationship between components? Is there a "controlling vs. controlled" hierarchy hiding behind what looks like a parallel/independent relationship?
Common misjudgment: mistaking a "control relationship" for a "parallel relationship." For example, an "Auto/Manual toggle" and a "model list" look like two independent controls, but the toggle actually determines whether the list is operable — they are hierarchical, not parallel.
Step 2: Full State Machine Enumeration
Compute the Cartesian product of all control variables to map every possible interface state, then check each state for two kinds of gaps:
- Information Gap (unknown state): In a given state, is the system's outcome clearly fed back to the user? (e.g., in Auto mode, which option got selected — is that visible at all?)
- Operational Gap (unauthorized control): In a given state, does something that looks clickable actually do nothing, or is something active that shouldn't be? (e.g., in Auto mode, list items still appear clickable)
Step 3: Cognitive Friction Review
- Copy ambiguity: Does toggle/button text create confusion between "current state" and "destination state" when it changes? (Recommendation: fix the label text and let the toggle's On/Off position express the state, rather than changing the label itself.)
- Visual metaphor: Does grayed-out reliably mean disabled? Does highlighted reliably mean active? Does it match physical intuition?
- Interaction depth: Can a "two-layer radio selection" be flattened into "one layer" to reduce the click chain?
Step 4: Multi-Tier Solution Output
Always provide at least two solutions — never just one:
- Solution A (best experience): Follow Progressive Disclosure — restructure the information hierarchy, hide irrelevant content, and show controls only when needed.
- Solution B (lowest cost): Keep the existing layout/framework unchanged; patch the logic with disabled overlays, state locks, tooltips, or highlight badges to keep page height/structure stable (no layout jump).
Weigh solutions against three dimensions: development cost, transition/motion stability, and visual cleanliness.
Output Format
Structure the output exactly as follows:
### 🔍 Current Diagnosis & Core Conflicts
- **Component Hierarchy Conflict**: [who controls what, where the cross-wiring is]
- **State Machine Logic Gap**: [missing feedback or ambiguous control in a specific state]
- **Cognitive Friction Point**: [ambiguity in copy or visual metaphor]
### 💡 Solution A: [Name] (Best Experience)
- **Core Approach**: [one sentence]
- **Interaction Behavior**:
- State 1: [progressive disclosure details]
- State 2: [corresponding change]
- **Advantages**: [...]
### 💡 Solution B: [Name] (Low Cost & Robust)
- **Core Approach**: [one sentence]
- **Interaction Behavior**:
- State 1: [gray-out/overlay/lock rules]
- State 2: [logic for restoring active state]
- **Advantages**: [...]
### 📐 Advanced Micro-Optimization Suggestions (Optional)
- **Copy Standards**: [how to unify and lock text]
- **Micro-animations / Feedback**: [tooltips, breathing highlights, etc.]
Notes
Underlying Methodology (for reference — no need to expand in output)
- First Principles: Ask the underlying purpose before judging the surface.
- State Machine Logic: Enumerate all state combinations and check for gaps, rather than only reviewing the "happy path."
- Cognitive Friction Minimization: Fix copy, keep visuals intuitive, flatten hierarchy.
- Progressive Disclosure: Hide what shouldn't be shown to keep the interface clean; pair with a low-cost fallback for cases constrained by dev timeline or layout stability.
- Distinguish observed facts from inferred behavior, and list missing business rules instead of inventing them.
