1.为什么需要战略思维而非路线图？——制定有效的设计系统策略

设计系统是一种产品。这种产品解决了以下具体任务：

• 确保一致性

• 缩短开发时间

• 等等

最常见的动机在于，开发新产品的初衷是希望其能与市场上现有的产品有所区别。毕竟，若用户倾向于选择市场上已有的、被认可的“原创”产品，那么为何还要耗费时间和精力去复制现有的解决方案呢？

在设计系统领域，有时可能需要复制现有的解决方案，因为某些原因导致这些方案无法直接提供。通常，设计系统是作为内部产品而构建的，即便公司对外发布了相关文档，也不保证能够直接应用该系统。

无论我们选择复制现有的解决方案，还是构建一个具有独特性的新设计系统，策略的制定都是必不可少的。

部分团队在缺乏充分支持的情况下着手构建设计系统，可能会面临制定详尽策略的困难。毕竟，设计系统在初始阶段通常是一个最小可行产品（MVP），它仅包含一些基本的需求。

• 设计师的 UI 组件库

• 在代码实现中体现 UI 组件库的部分

• 阐述基本设计原则的文档（常被忽略）

为了避免陷入“永恒的最小可行产品（MVP）”阶段并顺利过渡到下一阶段，我们需要从一开始就将设计系统视作一个产品，而非仅仅是一个项目。

在探讨产品策略构建时，我们可以找到众多现成的案例，甚至包括详尽的指导手册。然而，当讨论到设计系统时，这样的案例却相对匮乏。大多数情况下，我们所见到的都是遵循“标准设计系统”模式的方案，它们通常包含一些典型的组件和基本元素集（如标志、图标等）。

每家企业都有其独特的企业文化和业务需求。因此，设计系统应当体现公司的具体情况和需求。除了标准的组件和标记库之外，可能还需要根据特定需求添加其他元素。

2.发现

用户需求

与任何其他产品一样，设计系统同样拥有用户群体。因此，在制定策略时，最佳做法是先深入了解这些用户。这可以通过与设计师和开发人员进行一系列访谈来实现，并探索还有哪些其他利益相关者可能对使用设计系统感兴趣：

• 在设计和开发过程中，采用了哪些工作流程？

• 设计师与开发人员之间的协作机制是怎样的？

• 使用了哪些产品或框架（包括那些不可更改的部分）？

• 目前面临的主要挑战有哪些？

• 最关键的优先事项或需求是什么？

• 等等。

商业需求

设计系统的核心目标之一在于协助企业加速产品的创建和维护过程，并提高其效率。为了实现这一目标，我们需要与产品经理、项目负责人以及公司高层管理人员进行深入访谈，以获取以下信息：

• 公司未来的发展方向是什么？

• 公司有无计划推出新的产品或服务，并考虑整合哪些平台？

• 是否有进行品牌重塑的计划？

• 设计系统目前能够提供哪些支持，未来可能需要满足哪些需求？

• 竞争对手的发展方向如何？

• 是否有可能为专门的设计系统团队分配预算？

产品分析

对应用设计系统的产品（或多个产品）进行全面研究，涵盖设计、导航、代码实现等多个维度。同时，对比分析产品在实际应用中的外观表现与原始设计中的预期效果：

• 设计文件的分析研究：包括文件的结构、布局的组织方式等。

• 所使用的库的详细分析。

• 对现有文档的评估：涉及文档的完整性、质量以及更新流程的分析。

以及对代码的深入分析：

• 所使用的库（包括内部开发和外部引入的）。

• 架构的逻辑性及其在不同平台上实现的差异性。

• 组织资源的逻辑方法：如图标、标志等。

我们在当前阶段所积累的知识越丰富，对整个运作机制的理解越透彻，未来规划各项措施并预防潜在问题就会越加得心应手。重要的是，我们的视野不应仅限于主要产品，还应涵盖公司所开发和维护的所有附加应用程序和服务。这对于我们全面掌握所有的用户接触点很有帮助。

在此阶段之后，我们很可能需要一系列额外的访谈来澄清细节。

审查

如同进行任何复杂的产品研究一样，我们得到的输出是大量数据和见解的集合，这些需要进一步的分析和处理：

• 界定研究范围：确定目标用户群体以及可能利用设计系统的产品。

• 识别主要问题和瓶颈所在。

• 识别用户与产品交互的关键接触点。

• 准备基于实践案例和公司具体情况的建议。

随后，我们需要向管理层展示研究成果，收集反馈，并了解管理层是否有进一步推进的意向。

3.工作坊

在当前阶段，我们应当积极推动各利益相关方（包括设计师、工程师、管理层等）参与工作坊。

如果我们计划从零开始构建设计系统，可以首先从组件拆分的练习着手。

然而，设计系统的意义远不止于组件本身。此外，鉴于构建设计系统可能需要数月的时间，仅关注当前需求是远远不够的。我们必须认识到，设计系统需要随着核心产品（甚至可能是整个业务）的发展而不断成长。换句话说，我们需要明确我们想要为用户创造的产品类型。如果我们暂时抛开设计系统的特定语境，这个问题实际上是在开发任何新产品时都会遇到的典型问题。我们可以使用开发“常规产品”时所采用的传统方法来解答这个问题。

产品的使命和愿景

要解答上述问题，通常建议首先明确使命和愿景。

互联网上有许多关于如何制定使命和愿景的文章和指南。然而，对于使命和愿景的来源及其相互关系，人们往往存在不少混淆。

例如，《设计使命宣言——示例和提示》文章中指出：

“设计愿景陈述描绘了组织期望在未来实现的目标状态，而使命陈述则阐明了其当前的设计宗旨和实施路径。”

Pioneer , Goalist , Nippon Koei 等许多公司都这样做。在本文中，我将使用这种第二种方法，因为对我来说更自然、更清晰（请在评论中写下您更喜欢哪种方法以及原因)。

从我的角度来看，使命是公司经常写在海报（或T恤）上的内容。例如，在宜家，它听起来相当抽象：

“为大众创造更美好的日常生活”

几乎所有现代初创公司都采用这种表述方式。坦白而言，这种措辞往往缺乏具体性。

相比之下，愿景则更为明确。它阐述了核心的商业理念或公司所追求的目标（或产品应为用户带来的价值）。在设计领域，这类似于所谓的最终愿景。以宜家为例，其商业理念如下：

“提供种类丰富、设计精美、功能完备的家居用品，价格亲民，以使尽可能多的人群能够负担得起。”

这种表述方式清晰地描绘了宜家的理念及其与竞争对手的主要差异。

在我们的情形中，采用设计系统，我们同样可以遵循这一路径：从设定一个简洁而普遍的使命出发，并构建一个旨在实现该使命的愿景。

例如，我们可以设定一个普遍的使命：“简化我们产品团队的工作流程”。或者，使其更具针对性：“让我们的产品团队在产品构建过程中的工作更加高效”。

然而，我们可以从稍微不同的角度来审视这个问题。当我们讨论可访问性、动态性以及其他诸多方面时，这些并非仅与开发人员和设计师相关，更与我们公司产品的最终用户——消费者息息相关。基于此，我们可以对使命宣言稍作调整：“助力我们的产品团队为最终用户打造卓越的体验。”

这完全取决于你如何巧妙地构思出既优美又简洁的短语。无论如何，当使命宣言听起来振奋人心时，总是一件好事。例如，Atlassian 的使命宣言，至少在我听来非常鼓舞人心：

“我们的使命是释放每个团队的潜力”

愿景的设定较为复杂。为了让愿景不仅仅是海报上的一句华丽辞藻，我们需要它能够明确指出我们期望在设计系统中实现的具体目标。

让我们再次以宜家为例：

“提供多样化、设计精良且实用的家居产品，以亲民的价格，使尽可能多的人群能够负担得起。”

通过措辞，我们可以清晰地辨识出主要的要求或组件：

• 提供家居产品

• 种类广泛

• 设计精良

• 价格低廉以便更多人能够负担得起

这听起来像是公司对每个即将发布的产品所设定的验收标准。同样的逻辑也适用于设计系统的愿景制定。让我们来观察一些实例。

帮助交付高质量的界面，同时加速上市时间。通过使 UX 和 UI 在团队中的设计师和开发人员之间易于访问，来赋予创造力。通过人们喜欢使用的应用程序重塑企业和开源世界。

“Material 是由 Google 创建的设计系统，旨在帮助团队为 Android、iOS、Flutter 和 Web 构建高质量的数字体验

“Material Design 是一套可适应的指南、组件和工具系统，支持用户界面设计的实践案例。由开源代码支持，Material Design 简化了设计师和开发人员之间的协作，并帮助团队快速构建美观的产品。” 

“设计系统是一套标准，通过减少冗余来管理大规模设计，同时在不同页面和渠道之间创建共享语言和视觉一致性” 

上述示例实际上并非愿景的正式表述。然而，在我看来，它们完全有潜力被塑造成愿景。毕竟，这些表述中的要求都十分明确。在我的观点中，愿景陈述应当清晰地传达正在构建的设计系统的核心特征，这非常重要。否则，最终可能开发出与预期不符的产品。

4.倡议

规划阐述了目标与宗旨，这有助于实现使命，并达成理想的北极星愿景。在当前阶段，规划已经涉及到具体的资源：

• 标志

• 图标

• 表单元素

• 按钮

• 文档

• 用户消息

• 网格系统和断点

• 组件演示应用

• 等等

最好避免将单个组件单独视为一个倡议，这并不是因为“它在战略中太小，不足以构成一个倡议”，而是因为在处理组件时，更适宜将它们归类并分组为更大规模的倡议——即史诗级别的项目：

• 用户输入组件：包括文本输入框、文本编辑区、密码输入框等。

• 按钮类组件（包括所有外观类似按钮的元素）：如平面按钮、圆形按钮等。

• 用户提示信息：包括弹出式提示、横幅提示、全屏通知等。

通过在各自的组别中考虑组件，我们不仅可以关注设计决策的一致性，还可以进一步思考：

• 组件组合模式与模板：探讨组件如何协同工作

• 决策树模型

• 实践案例指南

• 文案创作技巧

• 等等

我们务必要铭记业务需求的重要性。毕竟，如前所述，系统设计的核心目标之一是协助企业更迅速、更高效地开发和维护产品。在考虑公司的产品开发策略、遵循最佳实践案例以及分析竞争对手所采用的方法的基础上，我们可以尝试预测未来可能需要的功能。

例如，若公司计划将其产品推向国际市场，我们可能需要考虑文案的本地化问题。

仅凭一份简略的举措列表是不足以周全规划战略的。由于某些举措可能归属于同一类别，而不同举措间又可能存在相互依赖性，因此需要明确标识这些关系，以便更好地掌握整体状况。我通常使用倡议卡的方法来进行管理：

倡议卡

在前述示例中：

• 倡议标题——揭示倡议的核心内容。例如，“语义化创意标签”。

• 描述——对倡议进行简洁的说明。比如，在标签标记的情况下，可以描述为“从硬编码的颜色值和颜色命名变量（如蓝色、灰色等）转变为与品牌色彩调色板相匹配的功能命名变量”。

• 愿景要求——明确倡议满足的愿景要求。对于每项倡议，我们都需确保其从愿景的角度来看是有意义的，以保持清晰的焦点，并避免在与使命/愿景不相关的事情上耗费精力。

• 行动计划——列出使倡议得以实施的具体行动项。例如，在“语义化核心标签”的情况下，可能需要处理命名规范、文档编制等事宜。

• 价值/机遇——倡议将为公司及用户带来哪些价值或机遇。

• 依赖性——本倡议依赖于哪些其他倡议？即在实施本倡议之前需要完成哪些工作。比如，如果我们讨论的是“暗色模式”倡议，可能需要将“语义化软件标签”作为其依赖项。明确依赖关系有助于我们了解以何种顺序推进各项倡议最为适宜。

策略

最终，策略制定环节最为有趣 ?

在这次工作坊中，我们需要设计、产品和开发领域的关键代表参与。主要目标是规划出首版以及后续迭代的蓝图。为简化流程，我通常采用一种简洁的分解方法：

• 短期（1.0版本）

• 中期（迈向下一阶段）

• 长期（终极目标）

在工作坊上，我们将根据优先级和依赖关系将倡议卡按类别进行组织。此外，还需讨论实施特定举措所需的资源。在构建设计系统时，最关键的资源无疑是人才和时间。我们不太可能一开始就组建一个完备的“梦幻团队”。因此，在规划短期或长期举措时，我们必须考虑它们需要什么样的团队配置，以及我们是否能够在恰当的时机拥有相应的团队。

例如，我们可以从一个小型团队着手，团队中包含数名设计师以及2-4名移动开发人员。相应地，如果我们的计划中包含网页开发或后端工作，在初期阶段我们可能还无法承担这些任务。同时，根据这些任务的紧迫性，我们可以判断在哪个阶段需要补充缺失的资源：是否可以将这些任务安排在中期（或更晚的阶段），或者是否需要与管理层探讨扩充团队的可能性。

策略周期

考虑到需要兼顾的众多因素，此阶段将涉及多轮会议，并可能需要更多参与者来深入讨论细节。具体来说，需要探讨以下议题：

• 技术细节讨论：需要确定所需框架（以及是否需要对现有架构进行重大修改），明确预期的开发环境，以及设计等相关问题。

• 探讨潜在的设计系统团队成员（包括潜在的领导者）。可能需要进行额外的招聘工作。

• 关键流程的梳理：包括团队工作流程、产品发布、实施过程、用户支持等。

• 确立衡量项目成功的标准至关重要。在项目启动之初就考虑集成分析工具到系统中，例如统计工具等，是一种明智的做法。这些数据将成为向管理层汇报的关键内容。

细节至关重要，缺少它们将导致难以制定清晰的路线图，并准确预测完成首期工作所需的时间。

路线图

目前，大多数产品团队采用敏捷开发方法。这通常意味着开发周期会根据当前产品需求进行调整，任务规划仅覆盖一个或两个冲刺周期。然而，在设计系统的情况下，我们需要采取瀑布式开发方法：提前数月进行规划。即便团队选择以冲刺方式工作，我们也需要为整个首个发布周期制定清晰的路线图。需要对每个计划及其包含的任务进行大致评估。

我们需要保持现实的态度：提前精确预测一个项目所需时间是相当困难的。不过，凭借充分的经验，我们能够进行大致的估算。在此基础上，我们可以为项目初期的几个月制定一个初步的计划。

5.提出策略

“归根结底，如果缺乏关键人物的支持（无论是掌握资金的高层管理者，还是实际使用产品的用户群体），任何战略都是没有意义的。因此，你必须能够推销你的战略。这通常意味着需要准备一个演示文稿。”——内森·柯蒂斯

尽管在战略规划上投入了大量精力，但如果管理层不予以批准且不提供必要的资源，整个项目仍有可能面临失败的风险。在这种情况下，计算设计系统的投资回报率（ROI）将极大地有助于推广这一理念。

目前，已有专门的计算工具和相应的公式用于估算设计系统的投资回报率。

投资回报率的计算方法在很大程度上取决于所采用的设计系统模型。例如，内森·柯蒂斯识别出三种主要的设计系统模型：

• 独立型——采用现有的开放性、现成的系统。这种方式能够实现快速启动，但在后期可能会遇到限制和灵活性问题。毕竟，初始系统是由第三方团队创建的，在这种情况下，很难保证所有需求都得到充分考虑。

• 集中型——由一个专门的内部团队工作室负责开发和维护设计系统，将其作为内部产品。这种模式有时被批评为设计系统团队与产品团队“脱节”，产品团队的需求并不总是被充分考虑。

• 联合型——由产品团队中的顶尖设计师和开发人员共同努力创建设计系统。

在我看来，将集中型和联合型相结合更为可取：

• 一个专门的团队负责创建和维护系统设计，这能够确保快速而高效的行动。

• 同时，与产品团队保持紧密合作（通过共同工作、贡献、定期流程等方式），可以有效避免“与实际需求脱节”的问题。