Back to Details

decision-ui

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Decision UI

决策UI

Build interfaces that reduce decision effort.
Do not begin from components. Do not begin from charts. Do not begin from a dashboard template.
Begin from the decision.
打造能够降低决策成本的界面。
不要从组件开始设计，不要从图表开始设计，也不要从dashboard模板开始设计。
要从决策本身出发。

1. Establish the decision contract

1. 确立决策契约

Before proposing UI, identify:
  • Actor — who is using the view?
  • Decision — what choice, prioritization, diagnosis or intervention must they make?
  • Time horizon — minutes, hours, days, weeks, quarters?
  • Consequence — what is at risk if they act late or incorrectly?
  • Evidence — which observations can change the decision?
  • Action — what can the actor actually do from or after this view?
Write one sentence:
The user opens this view because they need to decide [decision] before [time/consequence].
If this cannot be stated, ask for missing business context or explicitly mark assumptions.
在提出UI方案之前，先明确以下几点：
  • 参与者（Actor） — 谁在使用这个视图？
  • 决策（Decision） — 他们需要做出什么选择、优先级排序、诊断或干预？
  • 时间范围（Time horizon） — 分钟、小时、天、周、季度？
  • 后果（Consequence） — 如果他们行动延迟或出错，会有什么风险？
  • 依据（Evidence） — 哪些观测结果会改变决策？
  • 行动（Action） — 参与者在该视图中或查看后实际能做什么？
写一句话：
用户打开这个视图，是因为他们需要在**[时间/后果]之前决定[决策内容]**。
如果无法写出这句话，需要询问缺失的业务上下文，或明确标注假设前提。

2. Build the information hierarchy

2. 构建信息层级

Prefer this sequence:
  1. Attention — what requires attention now?
  2. Comparison — compared with what?
  3. Cause — why is it happening?
  4. Impact — what is exposed or at risk?
  5. Action — what can be done?
  6. Verification — what happened after action?
Do not force all six into a single page. Use them as a reasoning sequence.
For multi-step operational or diagnostic products, load 
references/decision-flow.md
before finalizing the information architecture.
"Cause" is a diagnostic question, not permission to state causality. Distinguish observed association, diagnostic evidence, working hypothesis and validated cause.
The primary visual mass belongs to the question with the highest decision value, not automatically to the largest number.
优先遵循以下顺序：
  1. 注意力 — 现在有什么需要关注？
  2. 对比 — 和什么进行对比？
  3. 原因 — 为什么会发生这种情况？
  4. 影响 — 哪些方面会受到影响或存在风险？
  5. 行动 — 可以采取什么措施？
  6. 验证 — 采取行动后发生了什么？
不要强行把这六个部分都塞进一个页面，把它们作为思考的顺序即可。
对于多步骤的运营或诊断类产品，在最终确定信息架构之前，请加载
references/decision-flow.md
。
“原因”是一个诊断性问题，不代表可以直接断言因果关系。要区分观测到的关联、诊断依据、工作假设和已验证的原因。
主要的视觉权重应该分配给决策价值最高的问题，而不是自动分配给数值最大的指标。

3. Treat metrics as evidence

3. 将指标视为决策依据

A KPI is not important because it is a KPI.
For every metric ask:
  • Which decision can this change?
  • What is the comparison basis?
  • What threshold or range changes interpretation?
  • Is freshness known?
  • Is uncertainty material?
  • Does the number require explanation, action, or neither?
Remove metrics that do not affect the current decision.
KPI不会因为它是KPI就重要。
对于每个指标，都要问：
  • 这个指标能改变哪个决策？
  • 对比基准是什么？
  • 什么阈值或范围会改变解读结果？
  • 数据的新鲜度是否明确？
  • 不确定性是否会产生实质影响？
  • 这个数字需要解释、需要采取行动，还是两者都不需要？
移除不影响当前决策的指标。

4. Choose visualization from the question

4. 根据问题选择可视化方式

Load 
references/chart-selection.md
.
Never choose a chart because the dashboard “needs variety.”
Charts must make the intended comparison perceptually easy. Prefer position and length over angle and area. Use tables for exact lookup. Use color to carry meaning, not decoration.
If the intended analytical question is unclear, do not invent chart diversity.
加载
references/chart-selection.md
。
绝对不要因为dashboard“需要多样性”就选择某种图表。
图表必须让目标对比在感知上更容易完成。优先使用位置和长度，而非角度和面积。需要精确查找时使用表格。用颜色承载含义，而非装饰。
如果目标分析问题不明确，不要为了图表多样性而凭空创造。

5. Compose before decorating

5. 先排版再装饰

Establish hierarchy using:
  • position,
  • scale,
  • whitespace,
  • alignment,
  • density,
  • contrast,
  • grouping,
  • typography.
Use borders, cards, shadows, gradients and containers only when they clarify structure or state.
Avoid equal-weight tiles unless the underlying decisions are actually equal-weight.
A page with twelve equally loud modules has no hierarchy.
通过以下方式建立层级：
  • 位置、
  • 比例、
  • 留白、
  • 对齐、
  • 密度、
  • 对比度、
  • 分组、
  • 排版。
仅当边框、卡片、阴影、渐变和容器能够明确结构或状态时才使用它们。
避免权重相同的卡片，除非对应的决策确实具有同等重要性。
一个有十二个同样醒目的模块的页面是没有层级的。

6. Connect insight to action

6. 将洞察与行动关联

If the UI identifies a problem, show the path to the next action.
Good:
  • investigate cause,
  • compare affected cohorts,
  • open impacted order/account/asset,
  • change threshold,
  • assign owner,
  • approve/reject,
  • acknowledge,
  • simulate trade-off,
  • verify recovery.
Bad:
  • display anomaly,
  • color it red,
  • leave the user to hunt through navigation.
如果UI识别出了问题，就要展示下一步行动的路径。
好的做法：
  • 调查原因、
  • 对比受影响的群组、
  • 打开受影响的订单/账户/资产、
  • 修改阈值、
  • 分配负责人、
  • 批准/拒绝、
  • 确认知悉、
  • 模拟权衡、
  • 验证恢复情况。
不好的做法：
  • 只显示异常、
  • 标成红色、
  • 让用户自己在导航里找解决路径。

7. Design state, not only the happy screenshot

7. 设计所有状态，而非仅理想状态截图

Cover relevant:
  • loading,
  • empty,
  • stale,
  • partial,
  • delayed,
  • disconnected,
  • error,
  • permission-limited,
  • no-action-required,
  • acknowledged,
  • resolved,
  • overridden states.
For operational data, freshness and trust are part of the interface.
要覆盖相关的状态：
  • 加载中、
  • 空状态、
  • 数据陈旧、
  • 部分加载、
  • 延迟、
  • 断开连接、
  • 错误、
  • 权限受限、
  • 无需操作、
  • 已确认、
  • 已解决、
  • 已覆写状态。
对于运营数据而言，新鲜度和可信度是界面的一部分。

8. Preserve accessibility

8. 保障可访问性

Load 
references/accessibility.md
when implementing or auditing an interface.
Critical priority, status, comparison and action must not depend on color alone, hover alone, or a pointing device. Preserve semantic tables where tabular relationships matter. Keep a text-accessible summary of decision-critical chart meaning. Respect focus order, zoom/reflow and reduced-motion needs.
Accessibility does not require making expert interfaces artificially sparse. It requires that hierarchy and action remain perceivable and operable.
在实现或审计界面时，请加载
references/accessibility.md
。
关键优先级、状态、对比和行动绝不能仅依赖颜色、仅依赖悬停效果或仅依赖指针设备。在存在表格关系的地方保留语义化表格。为决策关键的图表含义保留文本可访问的摘要。遵循焦点顺序、缩放/重排和减少动效的需求。
可访问性并不要求把专业界面做得刻意稀疏，而是要求层级和行动始终可感知、可操作。

9. Responsive reconstruction

9. 响应式重构

Do not shrink the desktop grid.
On smaller screens:
  1. preserve the primary decision,
  2. preserve the most important comparison,
  3. collapse secondary evidence,
  4. move dense tables to focused views,
  5. keep critical actions reachable,
  6. recompose rather than merely resize.
不要直接缩小桌面端的网格。
在更小的屏幕上：
  1. 保留核心决策、
  2. 保留最重要的对比、
  3. 折叠次要依据、
  4. 将密集表格移至专属视图、
  5. 保证关键操作触手可及、
  6. 重新排版而非仅仅调整大小。

10. Run the anti-pattern pass

10. 运行反模式检查

Load 
references/anti-patterns.md
.
At minimum reject:
  • KPI card walls,
  • decorative chart variety,
  • redundant summary layers,
  • gauges without meaningful threshold logic,
  • unexplained red/green semantics,
  • dashboards with no visible action path,
  • filters that exist because “dashboards have filters,”
  • equal emphasis for unequal business consequences.
加载
references/anti-patterns.md
。
至少要排除以下问题：
  • KPI卡片墙、
  • 装饰性的图表多样性、
  • 冗余的摘要层、
  • 无有效阈值逻辑的计量表组件、
  • 未解释的红/绿语义、
  • 没有可见行动路径的dashboard、
  • 仅仅因为“dashboard都有筛选器”而存在的筛选器、
  • 对不同业务后果给予同等重视。

11. Produce a decision-first handoff

11. 产出决策优先的交付物

For BUILD or REFRAME, return:
  1. Decision contract
  2. Primary hierarchy
  3. Screen composition
  4. Visualization choices and why
  5. Interaction / diagnostic navigation
  6. States and exceptions
  7. Responsive behavior
  8. What was deliberately removed
For AUDIT, rank findings by structural impact:
  • P0: wrong decision model / missing critical action or evidence
  • P1: hierarchy, comparison or visualization obscures interpretation
  • P2: interaction, state or responsive weakness
  • P3: craft and visual refinement
Do not spend the review on corner radius while P0/P1 problems remain.
对于构建（BUILD）或重构（REFRAME）需求，返回以下内容：
  1. 决策契约
  2. 核心层级
  3. 页面排版
  4. 可视化选择及理由
  5. 交互 / 诊断导航
  6. 状态与异常情况
  7. 响应式行为
  8. 刻意移除的内容
对于审计（AUDIT）需求，按结构性影响对发现的问题进行分级：
  • P0：决策模型错误 / 缺失关键行动或依据
  • P1：层级、对比或可视化阻碍理解
  • P2：交互、状态或响应式存在缺陷
  • P3：细节打磨与视觉优化
在P0/P1问题还存在的情况下，不要把评审时间花在圆角这类细节上。

House rules

内部规范

If 
house-style.md
exists, load it after this file.
House rules may change visual language, density, component system and implementation preferences. They may not override decision clarity, truthful visualization, accessibility, or state integrity.
如果存在
house-style.md
，请在本文件之后加载它。
内部规范可以调整视觉语言、密度、组件系统和实现偏好，但不能凌驾于决策清晰度、真实可视化、可访问性或状态完整性之上。