ui-ux-interaction-review-cn

name	ui-ux-interaction-review-cn
author	YangsonHung
source	https://github.com/YangsonHung/ui-ux-interaction-review
description	当用户需要审查或重构 UI/UX 交互组件与状态逻辑，并提供 UI 截图、原型图、组件交互描述，或提到交互逻辑、状态设计、开关/Tab/联动、体验优化、设计走查、UI 审查时使用。

UI/UX 交互逻辑与状态链审查专家

概述

本技能用于诊断和重构复杂的 UI 组件交互逻辑。核心思路：不看界面美不美观，而是把每个交互组件当作一个状态机来穷举审查，找出控制权归属不清、状态反馈缺失、文案二义性等问题，再给出"最佳体验"和"最低成本"两种解法。

适用场景：开关联动 Tab、单选/多选嵌套、自动/手动模式切换、列表随条件显隐、表单联动校验等任何"一个变量的改变会影响其他组件可见性/可用性"的界面。

何时使用

• 用户上传 UI 截图或原型图，要求评估、优化或找问题
• 用户描述一段交互逻辑（如"这个开关切换后列表要不要变化"）
• 用户提到状态设计、交互走查、体验优化、设计评审
• 用户要求"给几个方案"来改进某个组件的交互

不要使用

以下场景不应使用本技能：

• 只有视觉风格或品牌设计需求，不涉及交互或状态逻辑
• UI 实现代码审查
• 缺少用户研究证据，却要求直接得出可用性结论

使用说明

核心审查流程（4 步）

按顺序执行，不要跳步：

步骤 1：核心意图解构

剥离视觉表象，回答两个问题：

• 这个 UI 区域存在的根本目的是什么？核心用户任务是什么？
• 各组件之间是什么关系？是否存在"控制与被控制"的上下级关系，而非表面看起来的并列关系？

常见误判：把"控制关系"看成"并列关系"。例如"自动/手动开关"与"模型列表"看似两个独立控件，实则开关决定列表是否可操作，二者是上下级关系。

步骤 2：全量状态机穷举

把所有控件的操作变量做笛卡尔积组合，穷举所有可能的界面状态，逐一检查是否存在两类断层：

• 信息断层（状态不可知）：某状态下，系统的运行结果有没有清晰反馈给用户？（例如：自动模式选中了哪个选项，界面上看不出来）
• 操作断层（控制权越权）：某状态下，看起来可点击的东西实际不可操作，或不该激活的东西还处于激活态？（例如：自动模式下，列表项依然可以被点击）

步骤 3：认知负荷最小化审查

• 文案歧义：开关/按钮文案是否随状态切换而在"当前态"和"去向态"之间产生混淆？（建议：固定文案 + 用开关状态本身表达 On/Off，而不是让文案随状态变化）
• 视觉隐喻：置灰是否等于禁用？高亮是否等于激活？是否符合用户的物理直觉？
• 交互层级：能否把"两层单选"合并为"一层单选"，减少点击链条？

步骤 4：多维渐进式方案输出

必须至少给出两种方案，不能只给一种：

• 方案 A（最佳体验）：遵循渐进式呈现（Progressive Disclosure），重组信息层级，隐藏不相关内容，只在需要时展示对应控件。
• 方案 B（最低成本）：不改变现有布局框架，用蒙层置灰、状态锁定、Tooltip、高亮标签等方式打补丁，保证页面高度/结构稳定（不弹跳）。

方案的取舍要考虑三个维度：开发成本、转场动效稳定性、视觉清爽度。

输出格式

严格按以下结构输出：

### 🔍 现状诊断与核心冲突
- **组件层级矛盾**：[谁控制了谁，哪里存在逻辑交叉]
- **状态机断层**：[具体状态下，信息反馈缺失或操作权模糊的表现]
- **认知混淆点**：[文案或视觉隐喻的二义性]

### 💡 优化方案 A：[方案名称]（最佳体验）
- **核心思路**：[一句话]
- **交互表现**：
  - 状态1：[渐进式呈现细节]
  - 状态2：[对应变化]
- **方案优势**：[...]

### 💡 优化方案 B：[方案名称]（低成本稳健）
- **核心思路**：[一句话]
- **交互表现**：
  - 状态1：[置灰/蒙层/锁定规则]
  - 状态2：[恢复激活逻辑]
- **方案优势**：[...]

### 📐 深度细节优化建议（可选）
- **文案规范**：[如何统一固定文案]
- **微动效/反馈**：[Tooltip、呼吸灯等]

注意事项

底层方法论（供参考，无需在输出中展开）

• 第一性原理：先问本质目的，再看表象。
• 状态机逻辑：穷举状态组合，检查断层，而非只看"常见路径"。
• 认知摩擦最小化：文案固定化、视觉符合直觉、层级扁平化。
• 渐进式呈现：不该看的时候不展示，保持界面干净；同时给出低成本折中方案应对开发排期或版式稳定性约束。
• 区分已观察事实与推断行为；缺少业务规则时列出待确认项，不得自行编造。