深科技产品的设计系统：从控制台到固件工具的统一语言

一提到设计系统，人们想到的往往是消费级应用：按钮、颜色，以及 Figma 和代码中的组件库。

深科技产品对设计系统的需求更大，而不是更小，只是需要另一种设计系统。

安全或工业产品很少只是一个界面。它包括 Web 控制台、命令行工具、API、文档、给审计人员的报告，有时还有设备上的小屏幕。每个部分由不同团队构建，常常使用不同的工具。没有共同语言，同一个概念最终会有五个名字、三种颜色。

深科技有什么不同

词汇就是系统。 在消费级产品中，一致性主要是视觉上的。在深科技领域，最大的混乱来源是语言。它叫“设备”、“资产”、“节点”还是“端点”？一个发现是“严重”、“高”还是“重大”？就术语达成一致，并在控制台、CLI、API 和文档中统一执行，是设计系统在这里能做的最有价值的工作。

状态承载风险。 状态颜色和标签不是装饰，用户会依据它们采取行动。它们必须处处一致，绝不能只依赖颜色，其含义应像 API 一样被精确记录。

工程师是主要贡献者。 深科技领域的许多界面由工程师在没有设计师参与的情况下构建。设计系统必须为他们服务：清晰的规则、良好的默认值、容易正确使用而难以误用的组件。

数据密度是真实存在的。 专家需要高密度的表格、日志和图表。为宽松的营销页面设计的系统帮不了他们，需要的是在高密度下依然可读的模式。

1. 从术语表开始。 在组件之前，先定义领域对象、它们的状态和名称。把它放进代码仓库，放在代码旁边，让工程师能看到。

2. 使用语义化令牌。 按含义而不是按数值命名令牌：“status-critical”，而不是“red-600”。这是在 Web 控制台、终端配色和打印报告之间保持一致的唯一方法。我在《语义化令牌》中写过这一点。

3. 覆盖非视觉界面。 错误消息、CLI 输出格式、日志级别、报告模板和 API 错误码都是体验的一部分，也要为它们制定规则。

4. 内建无障碍。 对比度、键盘导航、焦点状态和文字替代应内置于组件中，让每个团队都能直接获得。参见安全工具中的无障碍。

5. 保持精简并强制执行。 一个处处被使用的小系统，胜过一个无人使用的大系统。Lint 规则、代码评审清单和模板，比一个漂亮的文档网站更有用。

深科技中的一致性不是为了看起来精致。它能减少错误，缩短新客户和新工程师的上手时间，让产品更易于审计、更值得信赖。

正如我在《设计系统已死。设计系统万岁。》中所说，工具每年都在变，但对共同语言的需求不会变。在复杂的技术产品中，这种需求只是更加明显。