好的界面不是一个个孤立的页面，而是一套能复用、能生长的系统。本篇是 Trailhead「Systems Design with the Lightning Design System」模块的中文导读，围绕 Salesforce Lightning Design System（SLDS）讲解系统设计的思想：什么是系统设计、如何用"可承担性（affordance）"设计元素、如何识别宏观与微观设计模式，以及如何用规范（specs）、交互状态与指南把设计落成代码。
全文分为四个单元：第一单元建立系统设计的认知基础；第二单元以"按钮"为例，把系统设计原则应用到具体元素；第三单元学习宏观模式与微观模式，理解模式如何节省时间、提升效率；第四单元教你如何与工程师协作，用设计规范、六种交互状态与设计指南把设计意图准确传递出去。每个小节对应一页 PPT 幻灯片并附讲解视频。
01 系统设计入门（Get Started with Systems Design）
本单元建立系统设计的认知基础。学完本单元，你将能够：理解系统设计的核心关注点，并描述系统设计带来的好处。
正如系统变革学院创始人 Donella Meadows 所说："一个系统是一组相互连接的、被有条理地组织起来、以实现某种目标的东西。" 系统设计，就是把这句话应用到界面设计上。
什么是系统设计（What Is Systems Design?）
要理解 Salesforce 独特的设计系统 SLDS，得先理解系统设计（systems design）。系统设计就是设计并组合那些相互作用、以实现共同目标的元素，关注每个元素如何与整体用户体验相关联，目标是设计出满足系统需求中所述用户需要的系统。
用系统设计的方法来设计用户体验时，你关注的是可扩展性（scalability）：可扩展的元素有多个用途、支持多个视角、适配多个结构，然后把这些元素组合成完整的用户体验。
可复用的元素让设计师受益——通过复用现有的交互模式高效设计；也让新用户受益——因为能认出熟悉的元素而更快上手。元素在外观、用途和位置上的一致，帮助用户养成习惯，进而提升效率。
盖房子：一个类比（Building: An Analogy）
系统设计很抽象，不妨打个比方：盖房子。想想盖一栋房子的广度和范围——材料、建筑蓝图和施工工艺是如何协同，最终形成一个可居住的生活空间的。
再聚焦到一扇门上：你家门锁的说明书，其功能大概与数百万个别的门锁一致，所以没有必要去发明一种全新的把手和锁。久而久之，你学到最朴素的一课：用现有的方案解决常见问题，保持简单。
系统设计同理。它的基石是认识到：元素之间的关系，比单个元素本身更重要。这种效率还延伸到了开发者身上——当一组元素模式在应用的某个区域解决了问题，设计师可以复用这个模式，实现它的开发者也能复用已写好的代码，双方都省下时间去处理更复杂的问题。
用系统设计加持以用户为中心的思维
自 1986 年通过 ISO 标准引入以来，以用户为中心的设计（user-centered design）深刻改变了应用和网站设计，并催生了 Don Norman 所命名的用户体验（User Experience，UX）这一主流设计领域。
创造出色的用户体验，需要在两件事之间取得平衡：一是考虑人们习得的模式（微观和宏观）——它们来自广泛认可的 UX 最佳实践和你应用中的独特模式；二是确保用户能在单个页面或单个功能上完成一个明确的任务。
如果缺少系统设计的考量，你很容易掉进"忽视用户端到端体验"的陷阱。为保持全局视野，要聚焦两个关键问题：用户到达你的新页面或功能之前，在应用里做了什么？你如何利用相互连接的体验来放大设计？ 关注元素与整体体验之间的关系，才能产出打动人心的体验——这就是系统设计。
02 应用系统设计原则（Apply Systems Design Principles）
本单元把系统设计落到具体元素上。学完本单元，你将能够：用系统设计的方法来使用设计系统的元素，并把系统设计原则应用到为设计系统创建新元素上。
我们会以一个看似简单、实则充满门道的元素——按钮——贯穿始终，理解可承担性（affordance）如何塑造用户预期。
使用现有元素（Using Existing Elements）
按钮看似简单直接，但它恰恰凸显了元素在更大系统中的相互关联。用 SLDS 复用熟悉的组件（如按钮）很容易，但在动手之前，先要彻底理解全局，才能做出明智的决策。你需要理解按钮作为完整系统的一部分是如何工作的：
- 按钮执行的是哪类动作？
- 这类动作有哪些按钮类型可用？
- 它与用户在你的应用或其他平台见过的按钮，如何关联？
- 访问者能否认出这个按钮、明白它的用途？
- 按钮类型是否在视觉上反映了该动作的普遍程度或重要性？
自 2015 年第一个按钮加入 SLDS 1 以来，客户、伙伴与 Salesforce 设计师的持续反馈推动了它的演进。在系统设计中，观察元素如何被使用、倾听用户反馈，正是既有模式演化和发现新模式需求的方式——简言之，考虑全局及其与你工作的关系，考虑用户需求的层次。
为系统贡献新元素（Contributing New Elements）
有时你设想的元素尚不存在，需要自己创建。想象回到 SLDS 早期，还没有任何能"让用户采取行动"的 UI 元素。灵光一现——你提出了为 SLDS 创建一个新按钮的想法。设计系统里的按钮，首要目标是理解Salesforce 所有领域所需的动作类型。
最糟的做法是只关注自己的需求。如果你只为一个页面的某一个区域设计按钮，那就想得太窄了。无视人们会在你设计场景之外如何使用按钮，只会产出次优的体验。记住：当用户点击你的新按钮时，他们期望相似的按钮在整个应用里表现一致。
系统设计依赖能适配应用内不同用例的元素。我们希望人们能识别按钮的功能、结构与视觉设计和"使用按钮的预期结果"之间的联系——当元素长得像按钮，用户就期望它在整个应用里都像按钮一样工作。UX 圈子里，这叫做可承担性（affordance）。
可承担性（Affordance）
可承担性是元素中人们能认出、并能将其与"可采取的动作"关联起来的部分。在应用里，"设置"常被表示为齿轮，"邮件"常被表示为信封——设置和邮件其实都不需要齿轮或信封，但那些图标的特征暗示了其功能和用途。同理，按钮长得就像可以按、可以点、可以开关。
正如 Don Norman 所说："当可承担性被善加利用，用户只需看就知道该怎么做——无需图片、标签或说明。"
设计一个按钮时，要超越你正为之设计的场景，考虑它在应用里还可能被用在哪些地方，确保设计能容纳这些用途。有时你需要多种按钮类型——有些动作值得被突出推荐，有些则更相关、更有影响力。设计新按钮时，要纳入现有的按钮层级，考虑多种类型以突出重要性。
考量多样的用例会让设计更清晰，你会逐渐认清按钮所需的类型、状态和变体。针对每个已识别的用例去测试你的设计，验证你的设计决策。久而久之，用户学会这些可承担性，把它们变成高效的心智捷径。
03 识别设计模式（Identify Design Patterns）
本单元学习识别宏观与微观层面的设计模式。学完本单元，你将能够：区分宏观与微观的可复用体验、识别设计模式，并理解模式如何提升效率与生产力。
在 UX 设计中，模式（pattern）是针对反复出现的问题的可复用设计解决方案。SLDS 这类设计系统，就是这些模式的库。
什么是设计模式（What Are Design Patterns?）
可复用的模式出现在应用的宏观交互（macrointeraction）和微观交互（microinteraction）两个层面。
- 宏观交互：完成较高层次的任务，比如登录或创建新记录——就像是俯瞰整座城市的航拍视角。
- 微观交互：页面上你点击、点按或以其他方式操作的单个控件——就像是近距离观察城市里一栋房子门把手的运作方式。
宏观交互对应"更新记录页"这样的工作流，微观交互对应"记录页上编辑按钮的形状与位置"。两者共同构成了设计系统里的模式体系。
宏观模式（Macropatterns）
拿 Salesforce 里熟悉的"创建记录"举例。在宏观层面，Salesforce 里有三个地方可以创建记录：
- 该记录类型的导航下拉菜单里；
- 列出该类型所有记录的列表页上；
- 展示该记录类型详情的详情页上。
这不只是创建新联系人或新商机的方式，而是创建任何记录的方式。Salesforce 有大量标准记录类型，想象一下如果每种类型都有不同的创建方式，用户要花多少时间学习？这对生产力会有多大影响？
系统设计引导我们去考虑每一种记录类型，并找到一种对所有实例都适用的交互。这个设计之所以是宏观模式，是因为它可复用、适配多种记录类型、且是较高层次的交互。
微观模式（Micropatterns）
宏观流程搭好了舞台，微观模式则定义了实际交互。我们确切地看看"创建记录"这个动作长什么样：它的交互是什么？它提供了哪些可承担性？
虽然"微观"意味着小，但微观模式在整个应用中影响巨大——散布在应用各处的微观交互数量可能相当可观。用户依赖它们来录入数据、与你的应用沟通以完成任务，所以它们值得密切关注。
按钮状态（button states）——在视觉上指示如何与元素交互、以及元素当前状态的呈现方式——就是典型的微观交互。你会在本模块稍后学到更多关于状态的内容。
识别模式（Identifying Patterns）
模式是可复用的、能解决常见问题、可跨应用或系统重用的解决方案。在系统设计中，当我们有需求时，不会立刻开始设计，而是先搜索可用的模式——从本地开始，仅在必要时向外扩展：
- 你在应用中的专业领域：你对这里的设计方案已经熟悉，是否有能满足需求的交互？
- 其他同事的专业领域：向在应用其他领域工作的同事请教，他们有没有可复用的东西？
- 应用之外的世界：如果在应用或系统里都找不到合适的，才适合扩大搜索范围——别人为类似应用设计过什么方案？复用来自外部世界的方案时，用户能高效工作，因为他们认得出元素、会沿用别处养成的行为模式。
也可能存在一个独一无二、别处用不到的设计方案——但单个实例不算模式，因为没有被复用。而当一个方案被应用里多个地方采用（比如好几个功能都用模态对话框来创建记录），它就"毕业"成了模式，帮你为用户建立习惯、提升效率。
节省时间：效率与生产力（Saving Time）
系统设计关注创造和识别模式，让用户能快速达成目标。设计师必须谨慎，因为一个微小的设计决策，会给用户整体带来巨大的时间浪费。
Steve Jobs 谈过硬件启动速度："假设你能把开机时间缩短 10 秒，乘以 500 万用户，就是每天 5000 万秒……这值得去做，不是吗？" 他谈的是硬件性能，但道理同样适用于设计决策——偏离公认规范的设计决策，影响可能非常显著。
用户在使用应用时会形成习惯，他们直觉地、无意识地识别模式并产生预期。如果你的设计把登录框放到了别处，用户就无法依赖已有的登录认知，被迫学习新方式。单个用户可能只多花 3 秒，但 10,000 个用户就是 30,000 秒——超过 8 小时，整整一个工作日。算一笔账：3 秒 × 1000 用户 × 每周 100 次操作 = 每周损失 83 小时 20 分钟。
为了避免草率设计决策的连锁反应，请系统地处理宏观和微观设计决策——先找模式。我们不可能每次都做对，但运用设计原则，产出好体验的几率会高得多。
04 记录设计指南与规范（Document Design Guidelines and Specifications）
本单元教你如何把设计"写下来"。学完本单元，你将能够：创建详细的设计规范、描述六种最常见的交互状态，并写出有效的设计指南。
把设计变成能运行的代码，需要设计团队与工程团队紧密协作——而协作的桥梁，就是文档。
与工程师协作（Partnering with Engineers）
把设计变成应用里活生生的功能代码，需要设计团队与工程团队之间的强协作。如果你既是设计师又是工程师，那自然简单；如果不是，你就有一个实现你设计的工程伙伴。
把设计交给工程师时，应当伴随一次刻意的知识转移（knowledge transfer），让设计能按你的意图被构建出来。你把这些知识记录成规范（specifications）——通常简称 specs，它告诉工程师究竟要构建什么。
设计规范（Design Specifications）
设计规范记录设计的尺寸、颜色、排版与交互值，让工程师能把这些值用进代码。一份应用的设计规范描述每个元素的外观，明确其：
- 宽度与高度；
- RGB 或 HEX 颜色值；
- 字号与行高；
- 内边距（padding）与外边距（margin）；
- 交互（这部分记录在交互规范中）。
在这个硬件与偏好多样化的世界里，用户与设计的交互方式也各不相同：可能是键盘用户，用 Tab 键移动到元素；可能是鼠标用户，把光标移到设计上；也可能是触屏用户，用手指点按元素。交互规范就要覆盖这些不同方式。而任何元素交互规范的关键部分，就是它的交互状态。
交互状态（Interaction States）
交互规范展示设计如何随用户交互而变化。有六种主要交互状态，每个设计都必须为其写明规范：
- 默认（Default）：应用刚打开、尚未发生交互时的状态。
- 聚焦（Focus）：用户通过键盘或点击高亮了元素（仅交互元素有聚焦态）。
- 悬停（Hover）：鼠标光标移动到元素上方，提示用户该元素可交互。
- 禁用（Disabled）：元素通常可交互，但当前不可用。
- 按下（Pressed）：按下与释放之间——键盘按下键未松开、鼠标点击未松开、手指按下未抬起。
- 激活（Active）：元素处于选中状态，常见于菜单和列表。
除了这六种，你的设计可能还需要针对特定元素或设备的状态——可拖动的元素需要"拖动（dragged）"态，类似开关的元素需要"开/关"态，某些元素还需要"错误/成功/警告"三种通知状态。
无障碍指南（Accessibility Guidelines）
状态并不总是形状或颜色的变化。Web 内容无障碍指南（WCAG）要求设计让所有能力的用户都能使用，其意图很简单：让 Web 内容对所有人更易访问。
WCAG 2.0 中的 SC 1.4.1「颜色的使用」明确指出：绝不能让状态仅靠颜色来区分。把元素边框从灰色变成红色，不能作为指示错误状态的唯一方式——看不见颜色的人就不会知道有错误。在改变边框颜色的同时，给错误状态加上文字，就能帮助所有用户完成任务。
设计指南（Design Guidelines）
交互规范帮工程师正确编码，但设计师和工程师还需要知道一个设计的目的、它该用在哪、不该用在哪、如何使用，以及哪些变体支持哪些用例。这些更宽泛的细节由设计指南来承载。
设计模式指南（design pattern guidelines）描述宏观工作流（如创建记录）与微观元素（如按钮和输入框）的用法，有些还会说明为何要选择某个模式而非另一个。基础指南（foundation guidelines）——也叫品牌风格指南——定义应用的视觉风格，包括布局、排版、颜色、插画、图标、动效与品牌。
所有这些指南都需要结构。在一致的结构下，每条指南都应传达：用途、构成（anatomy）、用例、形态因素（如屏幕尺寸与触控功能）、最佳实践，以及无障碍。
记录设计的最佳方式之一是使用Do's 与 Don'ts（该做与不该做）：把"该做什么"的例子和"不该做什么"的例子并排放在一起，配合简短的文字说明，能帮助读者快速吸收规则。
毕业（Graduation）
一个优秀的模式库会随时间演进。理想情况下，你的工程伙伴会把每个模式及其元素构建成组件（component）。随着模式不断被编码固化，模式库就从"模式库"毕业（graduate）成了一个完整的设计系统。
现在你已经掌握了系统设计的基础，接下来可以去了解开发者如何把元素变成组件——参见 Lightning Design System Development for Designers 模块。
文章来源：Trailhead - Systems Design with the Lightning Design System