distill

从设计中移除不必要的复杂性，揭示核心要素，并通过彻底简化带来清晰度。

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

强制准备

用户通过 /distill 启动此工作流。此技能激活后，加载 $frontend-design — 其中包含设计原则、反模式和上下文收集协议。继续之前，请遵循该协议 — 如果尚无设计上下文，必须先加载 $setup。

如果简化依赖于减少可见选项、记忆负担或过早引入的复杂性，请参阅认知负荷。 如果杂乱的问题实际上在于优先级被拉平、分区缺乏克制，或标签与值不够清晰，请参阅层级检查清单。 如果简化意味着要决定哪些控件应突出、弱化、合并或消失，请参阅操作层级。

---

评估当前状态

分析哪些因素让设计显得复杂或杂乱：

1. 识别复杂性来源：

   • 元素过多：按钮彼此争抢注意力、信息冗余、视觉杂乱
   • 变化过多：颜色、字体、尺寸、样式过多且缺乏目的
   • 信息过载：所有内容同时可见，没有渐进式披露
   • 视觉噪声：不必要的边框、阴影、背景、装饰
   • 层级混乱：不清楚什么最重要
   • 功能膨胀：选项、操作或后续路径过多

2. 找出核心：

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

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

关键：简化不是移除功能，而是消除用户实现目标时遇到的障碍。每个元素都必须证明其存在的价值。

制定简化计划

制定一套彻底的精简策略：

• 核心用途：这应该完成的唯一一件事是什么？
• 必要元素：实现该用途真正需要什么？
• 渐进式披露：哪些内容可以等到需要时再显示？
• 整合机会：哪些内容可以合并或集成？

特斯勒定律（由谁承担复杂性？）

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

优先将不必要的复杂性转移到产品中，例如：

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

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

最小可发布范围

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

迭代规则

• 轻量设计
• 尽早构建
• 在真实使用暴露问题后再优化
• 在功能尚不存在时，不要试图在抽象层面解决所有边缘情况

重要：简化并不容易。要为卓越的执行腾出空间，就必须对好点子说不。务必果断。

简化设计

从以下维度系统地移除复杂性：

信息架构

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

视觉简化

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

布局简化

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

交互简化

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

内容简化

• 缩短文案：把每句话删减一半，然后再删减一次
• 使用主动语态：写“保存更改”，而不是“更改将被保存”
• 移除术语：始终优先使用通俗语言
• 便于浏览的结构：使用短段落、项目符号和清晰的标题
• 只保留必要信息：移除营销套话、法律术语和模棱两可的表述
• 移除重复文案：标题不要复述引言，不要重复解释；说一次就够

代码简化

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

绝不要：

• 移除必要功能（简单 ≠ 没有功能）
• 为了简化而牺牲无障碍性（仍然需要清晰的标签和 ARIA）
• 把内容简化到难以理解的程度（神秘 ≠ 极简）
• 移除用户做决策所需的信息
• 完全消除层级（有些内容理应更醒目）
• 过度简化复杂领域（复杂度应与实际任务的复杂度相匹配）
• 如果一开始就能交付更精简且有用的版本，就不要过度构建后再简化
• 让锦上添花的功能阻碍可交付的核心功能
• 在构建并使用基本流程之前，就为每一种理论上的边缘情况做设计
• 当产品本可自行处理时，把可避免的配置和规则跟踪工作推给用户

验证简化效果

确保简化提升了易用性：

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

记录移除的复杂性

如果移除了功能或选项：

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

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