前言 在快速发展的行业中，设计系统已成为企业应对复杂业务场景的关键工具。为了构建一个成熟的设计系统，需要从生产、消费和监测三个关键模块出发，进行系统的规划和实施。本文将结合百度搜索设计系统近期针对「生产和消费」环节的升级改版经验，分享如何通过场景化重构资产，建立秩序，提升内在一致性，并增强资产的消费体验。 文中介绍的方法不仅有助于设计系统的建设者有效规划设计资产，还能帮助业务设计师在日常项目中对组件进行高效应用和合理创新。此外，本文还将深入探讨更多设计系统的干货内容。 一、项目背景 百度搜索在移动时代初期，通过划分垂类团队，深耕垂类特性，以满足不同垂类下用户对内容精细化消费的诉求。这一阶段的设计资产具有以下特点：
- 组件资产与业务强绑定，业务独立维护；
- 业务创新频繁，组件样式新增多、合并少；
- 设计系统内在逻辑不健全，主要为各业务组件的快速录入封装。 这种建设方式是一种样式归纳性思维，通过初期快速归纳收集，满足业务高速发展的需要。但随着业务的成熟和发展，各垂类团队横向协作愈加频繁，对组件复用提效与保持产品体验一致性的诉求越发明显，这种建设思维便会暴露出它的劣势。 二、项目方案
- 明确目标 基于百度搜索设计系统现状，其核心问题是资产规范性不足。设计师和工程师通过调用组件或阅读规范，实现对设计系统的消费。因此，一个业务级的设计系统应具备完备的设计资产、提供高效的消费体验以及具有良性的迭代模型。
- 解决方案
- 明确目标：通过场景化重构资产，建立秩序，提升内在一致性，增强资产的消费体验。
- 解决方案：
- 资产规范：制定明确的设计规范，确保组件变体健全；
- 高效消费：优化消费途径，简化消费路径，提高用户体验；
- 迭代模型：中台与业务同频，业务组件优化可实现资产的沉淀回流。 通过这些措施，可以有效地解决设计系统中存在的问题，提高资产的易维护性和可拓展性，保证在业务成熟期能够更高效地赋能团队协作，增强产品体验一致性。 在设计系统的发展过程中，实现业务赋能最大化的前提在于拥有完备的资产作为基础。因此，我们设计了三个阶段的迭代发展策略： 统一化阶段的目标是夯实基础，重构设计资产的底层建设逻辑，明确资产适用场景，提升可拓展性和易维护性。这一阶段的核心是确保资产的规范性和易用性。 工程化阶段致力于整合资产代码，提升资产消费效率，并建立设计中台与业务之间的良性循环。通过这种方式，可以确保设计系统的高效运行和持续改进。 工具化阶段探索了设计系统工具化的形态，以及AI大模型结合的机会，以丰富消费途径，实现业务交付的不同阶段下全方位提效。这一阶段的目标是通过技术创新，提高设计系统的智能化水平，从而更好地满足业务需求。 在“统一化”阶段，我们提出了提升资产规范性和易用性的目标。为了实现这一目标，我们需要对设计交付链路上的问题进行合理解决。首先，可以基于现状，从“资产生产 → 资产消费”的链路出发，对目标进行拆解。 接下来，我们将探讨如何重构底层逻辑，转变视角。面对设计系统中常见的问题，如组件归类和形态差异，我们可以借鉴“样式归纳”的视角进行分析。这种分析方法通过对已知组件进行共性和差异性罗列，然后求同存异，将共性较多的设计稿归纳为某一类组件；并分别定义其组件能力和使用场景。然而，当各业务线成熟时，这种设计系统无法满足跨业务复用的情况，且缺乏内在逻辑的归纳思维，也无法对持续发散的业务创新形成有效收拢。这时，我们需要转变视角，探索场景化演绎思维。 在场景化演绎思维中，我们关注用户行为的变化。随着环境和媒介的不断变化，人类可实施的行为动作并没有太多变化。同时在日常产出时，我们的设计意图基本是围绕如何让用户在某场景下用某种行为达成目标来开展的，之后这些产出物又被封装为可复用的组件。由此可以倒推，将组件的本质抽炼为：帮助用户在特定行为场景下，通过某个组件，以某种方式，达成目的。而组件交互与样式的变化，底层所承载的设计意图都是为了在这个特定的场景下，优化用户的行为，提升场景体验。 在设计资产的构建过程中，我们常常需要跳出传统的业务场景，将注意力集中在用户行为的本质动作上。通过这种方式，我们可以更直接地理解组件如何服务于不同的宏观用户行为场景，并以此为基础，逐步展开对不同变体的探索和演绎。 首先，理解组件的本质是关键。一旦我们明确了组件服务于哪种用户行为场景，接下来的任务就是探讨这些组件在样式上的相似性——它们是否仅仅是为了满足业务场景的表现需求。通过这种方式，我们可以将这些资产分类到不同的组件类型中，从而得到MVP版的设计资产及其衍生变体。 这种“场景演绎”的思维模式是一种根本性的思考方式，它从内向外发散，通过深入挖掘组件的本质来推导出它们能满足的用户场景需求。这种视角不仅有助于我们在构建设计系统时提高其通用性，还能有效降低维护成本。 接下来，我们来探讨在实际工作中应该如何演绎推理变体以及建立秩序。首先，我们需要确定在构建设计系统时应当遵循的原则和方法。每个组件理论上都可以衍生出多种变体，那么在构建设计系统时，我们应当达到何种程度的灵活性和适应性？ 以Tab组件为例，我们可以拆解其在不同场景下的行为，通过三步来讲解组件场景演绎的方法： 第一步：明确最基础的行为场景以及达成目标的最基础方式。例如，当我们知道Tab组件的主要目的是帮助用户切换内容时，我们可以细化主行为场景，并演绎出在各个细分场景下，如何通过优化体验来提升用户的行为。 第二步：演绎变体，衍生行为场景，优化达成方式。这一步涉及从对象、空间、时间等维度细化行为发生的场景，并从操作体验、认知体验、情感化体验等维度优化达成方式。 第三步：获得变体与适用场景，建立秩序。通过这样的场景拆解与演绎，一个完整的组件便被建立完成。对于每一种变体，我们都有清晰的适用场景认知。因此，可以向业务开发者和设计师提供合理的使用建议。 同时，采用这种演绎的方式建设组件后，每个组件的能力定位会更加明确，资产的建设也会变得更加精简，不易产生冗余。对于每种组件在搜索场域下具备的能力与发展方向，我们也能有清晰的预判。 在设计系统的场景拆解过程中，我们采用了层层递进的拆解方式，从宽泛到具体、从广义到具象。这种拆解方法不仅帮助我们清晰地预判了设计系统的缺失，也为后续的设计工作提供了明确的方向。 首先，我们将所有设计资产按照这种方式进行重构归类，得到了一张有序的设计系统全局场景演绎规划图。这张图可以帮助我们更好地预判设计系统的缺失，从而更有效地规划设计工作。 其次，我们需要综合考虑业务需要与建设成本来评估某个资产在当前阶段需要满足的程度。通过这种方式，我们可以确保设计系统在不同阶段都能实现资源利用最大化。 接下来，我们需要考虑消费场景的易用性。为此，我们对规范文档进行了优化整合，为设计系统后续内容工程化打下了基础。 第一步，我们实现了资产层级的扁平化。通过将组件按更细的颗粒度进行分组呈现，并建立目录导览页，平铺所有组件的跳转链接，我们提升了组件触达效率。 第二步，我们统一了文档结构。考虑到之前的文档由不同设计师撰写，我们在撰写习惯与表达用语上有所差异，这增加了开发者阅读时的理解成本。因此，我们将组件文档结构与话术进行了统一，将组件按变体类型进行统一分类，再分别讲解其对应的交互与样式参数，从而进一步提升消费时组件变体的触达效率，以及减少不相关信息的干扰。 第三步，我们内容场景化。在文档开篇以及每个变体下，我们建议了适用场景，以提升开发者的使用准确率。 通过以上实践方法，我们在今年上半年成功地转变了设计思维，运用行为场景演绎的方式使设计系统变得更加清晰、易维护和可拓展。同时，我们也保证了服务的产品体验一致性，降低了用户使用成本。此外，我们还通过优化消费场景帮助开发者更易理解，提高了资产生成与资产消费的匹配程度。整体来看，我们的实践方法取得了显著的效果。 本文探讨了一种创新的场景演绎方法，这种方法本质上是一种场景化的设计思维。其核心在于抽象场景特征，通过这些特征实现设计资产与业务场景之间的有效匹配。 首先，对于资产建设者而言，他们正向通过拆解行为场景来获得场景特征，从而更好地匹配业务场景。而对于资产消费者，则是逆向通过提炼业务场景，进而匹配行为场景，发现资产变体的不足，从而完善设计系统。 由此可见，这种方法不仅适用于系统级组件级的推演，也可以用于日常业务需求的创新与业务组件提炼中。每个组件的本质是服务于单一的行为场景，因此在日常需求中，需要设计师先对用户流程进行梳理。在需求的若干个业务场景中，对每一个业务场景，做最优的行为路径设计，再通过提炼每个行为路径下，涉及到的行为场景及其场景特征，去匹配现有设计资产：如改版需求，可以判断已应用的组件变体是否很好的帮助用户达成了目标，从而依托业务场景思考更适用的组件变体；如新需求，可以判断现有的场景特征，是否可以匹配已有的设计资产，以及已有的设计资产是否可以被进一步优化。 六、设计系统后续展望 本文分享了如何通过「场景演绎」的方法重构资产，为其建立秩序，提升内在一致性；当然从整个设计系统的长期建设层面来看，当前对资产的系统化重构与文档结构化的建设只是开始，绝非终点。在真实的协作流程中仍然会面临两大问题：
- 设计中台与业务沉淀如何保持同频？业务设计师在真正的资产消费链路中往往具有很强业务诉求，需要对部分资产基于业务进行定制，甚至需要建立独立品牌风格。这些不可避免的会导致业务设计师需要独立维护一套子级设计资产，同时下游的前端也需要基于业务对资产进行二次开发。这容易导致业务场景的变更无法及时同步设计中台；同时通用资产的迭代更新也无法快速覆盖到业务场景中，导致对业务赋能效果打折扣，这些长期而言不利于设计系统健康迭代。
- 原有资产消费路径不便捷。虽然在本次升级中优化了规范文档的阅读体验，但其实它仅仅是整个资产消费链路中的一小部分。整体看设计师仍然需要在规范文档、Sketch 组件 UIkit 与需求设计稿之前反复横跳切换；同时在交付过程中，也无法将设计资产同前端开发者建立共同语言的链接，从而不利于设计系统对业务落地的深度提效。 要解决这两个问题，需要推动设计系统工程化、提升资产消费链路灵活性，这其中的关键则是：在上游建立中台与业务之间同源可扩展的 Design Token。 在下游，我们致力于提供可串联设计与研发资产消费的工具分发平台，同时提升协作沟通效率的信息中转站。近期，我们已经按照这一思路开始了“设计系统工程化与工具化”的升级改造工作。这部分内容后续有机会也会和大家见面分享。