distill

从设计中移除不必要的复杂性，展现核心要素，并通过彻底简化营造清晰感。

应在复杂性固化到产品之前进行提炼。最好的简化方式往往是一开始就避免过度构建。

必须完成的准备工作

阅读 frontend-design，并遵循其中的上下文收集流程。复用已有上下文，只针对影响重大的信息缺口提问。

当简化依赖于减少可见选项、记忆负担或过早引入的复杂性时，请参阅 认知负荷。 当杂乱的根源在于优先级被弱化、章节缺乏节制或标签与数值不够清晰时，请参阅 层级检查清单。 当简化意味着要决定哪些控件应优先呈现、弱化、合并或移除时，请参阅 操作层级。 当简化意味着要通过改进结构、默认值、约束、预览和行内反馈，来移除辅助文案、重复标签、引导说明或解释性文字时，请参阅 自明式界面设计。

---

评估当前状态

分析设计显得复杂或杂乱的原因：

1. 找出复杂性的来源：

   • 元素过多：按钮相互争抢注意力、信息冗余、视觉杂乱
   • 变化过多：颜色、字体、字号、样式种类过多且缺乏明确目的
   • 信息过载：所有内容同时呈现，没有渐进式展示
   • 视觉噪声：不必要的边框、阴影、背景或装饰
   • 层级混乱：重点不明确
   • 功能蔓延：选项、操作或后续路径过多

2. 找到核心：

   • 用户的主要目标是什么？（只能有一个）
   • 哪些是真正必要的，哪些只是锦上添花？
   • 哪些内容可以移除、隐藏或合并？
   • 哪 20% 的内容能带来 80% 的价值？
   • 用户现在就能从中受益的最小可用版本是什么？
   • 哪些部分是核心要素、装饰性内容或愿景性内容？

如果无法从代码库中弄清其中任何一点，请直接询问用户，澄清你无法推断的内容。

至关重要：简化并非要移除功能，而是要消除用户实现目标时遇到的障碍。每个元素都必须证明自己存在的价值。

制定简化计划

制定彻底的精简策略：

• 核心目的：这项设计唯一要实现的目标是什么？
• 必要元素：实现该目标真正需要什么？
• 渐进式展示：哪些内容可以等到需要时再显示？
• 整合机会：哪些内容可以合并或整合？

Tesler 定律（由谁承担复杂性？）

某些复杂性是领域本身固有的。真正的设计决策在于：由系统吸收这些复杂性，还是强迫用户手动处理。

优先通过以下方式将不必要的复杂性转移到产品中：

• 智能默认值
• 预填数据并记住偏好设置
• 在需要时提供行内指导
• 推荐路径和建议设置
• 自动处理重复的设置和格式化工作

保留高级功能，但不要让每位用户在完成基本任务之前都必须面对全部复杂性。

最小可交付范围

• 定义能够带来实际用户价值的最小版本
• 将可交付的核心功能与锦上添花的内容及未来设想区分开来
• 不要让可选功能阻碍有用版本的交付

迭代规则

• 轻量设计
• 尽早构建
• 在真实使用暴露问题后再改进
• 功能尚未存在之前，避免在抽象层面解决所有边缘情况

重要：简化很难。它要求舍弃好点子，为出色的执行腾出空间。务必果断。

简化设计

从以下维度系统性地降低复杂度：

信息架构

• 从功能入手，而非外壳：先简化实际任务流程，再重新设计导航或界面框架
• 缩小范围：移除次要操作、可选功能和冗余信息
• 渐进式展示：将复杂内容隐藏在清晰的入口之后（折叠面板、模态框、逐步引导流程）
• 合并相关操作：合并相似按钮、整合表单、归类相关内容
• 明确层级：一个主要操作、少量次要操作，其余内容设为第三级或隐藏
• 消除冗余：如果内容已在别处说明，就不要在这里重复

视觉简化

• 缩减调色板：使用 1–2 种颜色加中性色，而不是 5–7 种颜色
• 限制字体样式：最多使用一个字体系列、3–4 种字号、2–3 种字重
• 移除装饰：去掉不服务于层级或功能的边框、阴影和背景
• 扁平化结构：减少嵌套，移除不必要的容器——卡片内不要再嵌套卡片
• 移除不必要的卡片：基本布局不需要卡片；改用间距和对齐
• 统一间距：采用一套间距尺度，移除任意设置的间隔

布局简化

• 线性流程：尽可能用简单的垂直流程替代复杂网格
• 移除侧边栏：将次要内容移至正文中，或将其隐藏
• 充分利用宽度：充分使用可用空间，避免复杂的多栏布局
• 统一对齐方式：选择左对齐或居中对齐，并保持一致
• 留出充足空白：让内容有呼吸感，不要把所有内容挤在一起

交互简化

• 减少选择：减少按钮和选项，让后续路径更清晰（选择悖论确实存在）
• 智能默认值：自动处理常见选择，只在必要时询问
• 吸收系统复杂性：优先采用推断、记忆状态和合理自动化，而不是让用户学习隐藏规则
• 行内操作：尽可能用行内编辑替代模态流程
• 减少步骤：注册能否从三步缩减为一步？结账流程能否简化？
• 明确的行动号召：只提供一个显而易见的下一步，而不是五个相互竞争的操作

内容简化

• 缩短文案：把每句话删减一半，然后再删一次
• 使用主动语态：“保存更改”，而不是“更改将会被保存”
• 移除术语：始终优先使用通俗语言
• 便于浏览的结构：使用短段落、项目符号和清晰的标题
• 只保留必要信息：删去营销套话、法律术语和模棱两可的措辞
• 移除重复文案：标题不要重述引言，不要重复解释；内容只说一次
• 先调整结构，再做解释：如果交互依赖辅助文本才能完成，应先改进分组、默认值、限制条件或行内示例，再重写辅助文本

代码简化

• 移除未使用的代码：清理无效 CSS、未使用的组件和孤立文件
• 扁平化组件树：减少嵌套层级
• 整合样式：合并相似样式，并一致地使用工具类
• 减少变体：组件是否真的需要 12 种变体？还是 3 种就能覆盖 90% 的情况？

切勿：

• 移除必要功能（简洁 ≠ 功能缺失）
• 为了简洁而牺牲无障碍性（仍需使用清晰的标签和 ARIA）
• 把内容简化到让人看不懂（晦涩 ≠ 极简）
• 移除用户做出决策所需的信息
• 完全消除层级（有些内容理应突出显示）
• 过度简化复杂领域（复杂度应与实际任务的复杂度相匹配）
• 如果一开始就能交付更精简且实用的版本，就不要先过度构建，再进行简化
• 让锦上添花的功能阻碍核心功能交付
• 在构建并使用基本流程之前，就为所有理论上的边界情况设计方案
• 如果产品本可自行处理，就不要把可以避免的配置和规则跟踪工作转嫁给用户

验证简化效果

确保简化提升了易用性：

• 更快完成任务：用户能否更快地达成目标？
• 降低认知负担：用户是否更容易理解该做什么？
• 依然完整：所有必要功能是否仍然可用？
• 层级更清晰：最重要的内容是否一目了然？
• 性能更好：更简单的设计是否加载更快？

记录移除的复杂性

如果移除了功能或选项：

• 记录移除原因
• 考虑是否需要提供其他访问入口
• 记录需要留意的用户反馈

记住：你拥有出色的品味和判断力。简化是一种自信的表现——知道应该保留什么，并有勇气移除其余部分。正如 Antoine de Saint-Exupéry 所说：“完美，不是在没有什么可添加时，而是在没有什么可删减时达成的。”