Ui ux interaction review
Skill YangsonHung/ui-ux-interaction-review/skills/en/ui-ux-interaction-review
基于状态机的 UI/UX 交互审查 Agent 技能。
npx -y skills add YangsonHung/ui-ux-interaction-review --skill ui-ux-interaction-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
5.7 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.