Ui ux interaction review cn
Skill YangsonHung/ui-ux-interaction-review/skills/zh-cn/ui-ux-interaction-review-cn
基于状态机的 UI/UX 交互审查 Agent 技能。
npx -y skills add YangsonHung/ui-ux-interaction-review --skill ui-ux-interaction-review-cnAssembled 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
当用户需要审查或重构 UI/UX 交互组件与状态逻辑,并提供 UI 截图、原型图、组件交互描述,或提到交互逻辑、状态设计、开关/Tab/联动、体验优化、设计走查、UI 审查时使用。
SKILL.md
5.0 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it
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、呼吸灯等]
注意事项
底层方法论(供参考,无需在输出中展开)
- 第一性原理:先问本质目的,再看表象。
- 状态机逻辑:穷举状态组合,检查断层,而非只看"常见路径"。
- 认知摩擦最小化:文案固定化、视觉符合直觉、层级扁平化。
- 渐进式呈现:不该看的时候不展示,保持界面干净;同时给出低成本折中方案应对开发排期或版式稳定性约束。
- 区分已观察事实与推断行为;缺少业务规则时列出待确认项,不得自行编造。
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.