关于 decision-ui
decision-ui 是一项围绕用户决策来构建设计界面的技能。它指导信息层级、证据、行动、状态、无障碍设计和响应式布局，而非从图表或仪表板模板入手。
主要功能
- 01明确决策及其背景
- 02按层级组织证据
- 03根据分析问题选择图表
- 04将发现与后续行动相连
- 05考虑界面状态与无障碍需求
- 06为小屏幕重新编排布局
适用场景
- 01规划以决策为核心的运营视图
- 02审查仪表板的层级与行动缺口
- 03为特定比较选择可视化方式
- 04检查响应式布局及异常状态
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/decision-ui确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
house-style.mdreferences/accessibility.mdanti-patterns.mdchart-selection.mddecision-flow.md详细介绍
决策界面
构建能降低决策成本的界面。
不要从组件入手。不要从图表入手。不要从仪表盘模板入手。
从决策入手。
1. 明确决策契约
在提出 UI 方案之前，先确定：
- 角色 — 谁在使用此视图？
- 决策 — 他们必须做出什么选择、优先级排序、诊断或干预？
- 时间范围 — 分钟、小时、天、周还是季度？
- 后果 — 如果他们行动太晚或判断有误，会有哪些风险？
- 证据 — 哪些观察结果可能改变决策？
- 行动 — 使用此视图时或之后，角色实际可以采取什么行动？
写成一句话：
用户打开此视图，是因为他们需要在 [时间/后果] 之前决定 [决策]。
如果无法写出这句话，请询问缺失的业务背景，或明确标注假设。
2. 构建信息层级
优先采用以下顺序：
- 关注点 — 现在有哪些事项需要关注？
- 比较 — 与什么相比？
- 原因 — 为什么会这样？
- 影响 — 哪些方面正面临风险或影响？
- 行动 — 可以采取什么措施？
- 验证 — 采取行动后发生了什么？
不要强行把这六项全部塞进一个页面。将它们作为推理顺序使用。
对于多步骤的运营或诊断类产品，在确定信息架构之前，先加载 references/decision-flow.md。
“原因”是一个诊断问题，并不意味着可以直接断言因果关系。应区分观察到的关联、诊断证据、工作假设和已验证的原因。
最主要的视觉区域应突出决策价值最高的问题，而不应自动留给数值最大的指标。
3. 将指标视为证据
KPI 并不会仅仅因为是 KPI 就很重要。
针对每个指标，询问：
- 它能影响哪项决策？
- 比较依据是什么？
- 什么阈值或范围会改变对它的解读？
- 数据的时效性是否明确？
- 不确定性是否会产生重大影响？
- 这个数字需要解释、需要采取行动，还是两者皆不需要？
移除不会影响当前决策的指标。
4. 根据问题选择可视化方式
加载 references/chart-selection.md。
切勿为了让仪表盘“看起来丰富多样”而选择图表。
图表必须让目标比较一目了然。优先使用位置和长度，而非角度和面积。精确查询使用表格。让颜色传达含义，而非用于装饰。
如果目标分析问题不明确，不要刻意增加图表种类。
5. 先排布，再装饰
通过以下方式建立层级：
- 位置，
- 尺度，
- 留白，
- 对齐，
- 信息密度，
- 对比度，
- 分组，
- 字体排版。
只有在边框、卡片、阴影、渐变和容器能帮助说明结构或状态时，才使用它们。
除非底层决策的权重确实相同，否则应避免使用权重相同的区块。
一页上有十二个同样醒目的模块，就等于没有层级。
6. 将洞察与行动关联起来
如果 UI 识别出问题，就要展示后续行动的路径。
好的做法：
- 调查原因，
- 比较受影响的群组，
- 打开受影响的订单/账户/资产，
- 更改阈值，
- 指定负责人，
- 批准/拒绝，
- 确认已知晓，
- 模拟权衡结果，
- 验证是否恢复。
不好的做法：
- 显示异常，
- 将其标成红色，
- 让用户自行在导航中寻找后续操作。
7. 设计各种状态，而不只是理想场景截图
涵盖相关状态：
- 加载中，
- 空状态，
- 数据过时，
- 数据不完整，
- 延迟，
- 连接中断，
- 错误，
- 权限受限，
- 无需采取行动，
- 已确认，
- 已解决，
- 已覆盖。
对于运营数据，时效性和可信度也是界面的一部分。
8. 保留无障碍性
实现或审查界面时，请加载 references/accessibility.md。
关键优先级、状态、比较和操作不得仅依赖颜色、悬停或指向设备。表格关系重要时，应保留语义化表格。图表中对决策至关重要的含义，应提供可通过文本访问的摘要。遵循焦点顺序、缩放／重排和减少动态效果方面的需求。
无障碍性并不意味着要刻意让专家界面变得稀疏，而是要求层级和操作始终清晰可辨且可操作。
9. 响应式重构
不要缩小桌面网格。
在较小屏幕上：
- 保留主要决策，
- 保留最重要的比较，
- 折叠次要证据，
- 将密集表格移至专注视图，
- 确保关键操作触手可及，
- 重新组合布局，而不只是调整尺寸。
10. 执行反模式检查
加载 references/anti-patterns.md。
至少应排除：
- KPI 卡片墙，
- 装饰性的图表种类，
- 冗余的摘要层，
- 缺少有效阈值逻辑的仪表盘，
- 未解释的红／绿语义，
- 没有明确操作路径的仪表盘，
- 仅因“仪表盘都有筛选器”而添加的筛选器，
- 对业务后果不同的事项赋予同等强调。
11. 提供以决策为先的交付内容
对于 BUILD 或 REFRAME，返回：
- 决策约定
- 主要层级
- 屏幕构成
- 可视化选择及理由
- 交互／诊断导航
- 状态和例外
- 响应式行为
- 有意移除的内容
对于 AUDIT，按结构影响对发现的问题排序：
- P0：决策模型错误／缺少关键操作或证据
- P1：层级、比较或可视化妨碍理解
- P2：交互、状态或响应式方面的不足
- P3：工艺与视觉润色
P0／P1 问题尚未解决时，不要把审查重点放在圆角上。
内部规则
如果存在 house-style.md，请在此文件之后加载。
内部规则可以调整视觉语言、信息密度、组件系统和实现偏好，但不得凌驾于决策清晰度、可视化真实性、无障碍性或状态完整性之上。