本文共 6977 字，预计阅读 18 分钟
译者推荐：本文探讨了设计系统战略的构建方法，强调了应将设计系统视为产品而非项目。作者从用户需求、业务分析、产品研究等多个维度，详细阐述了战略规划流程。文章不仅提供了理论框架，还分享了实践建议，包括团队组织、发布规划等内容，是一份面向设计系统团队的实用指南。
1.为什么需要战略思维而非路线图？——制定有效的设计系统策略
设计系统是一种产品。这种产品解决了以下具体任务：
最常见的动机在于，开发新产品的初衷是希望其能与市场上现有的产品有所区别。毕竟，若用户倾向于选择市场上已有的、被认可的“原创”产品，那么为何还要耗费时间和精力去复制现有的解决方案呢？
在设计系统领域，有时可能需要复制现有的解决方案，因为某些原因导致这些方案无法直接提供。通常，设计系统是作为内部产品而构建的，即便公司对外发布了相关文档，也不保证能够直接应用该系统。
无论我们选择复制现有的解决方案，还是构建一个具有独特性的新设计系统，策略的制定都是必不可少的。
部分团队在缺乏充分支持的情况下着手构建设计系统，可能会面临制定详尽策略的困难。毕竟，设计系统在初始阶段通常是一个最小可行产品（MVP），它仅包含一些基本的需求。
设计师的 UI 组件库
在代码实现中体现 UI 组件库的部分
阐述基本设计原则的文档（常被忽略）
为了避免陷入“永恒的最小可行产品（MVP）”阶段并顺利过渡到下一阶段，我们需要从一开始就将设计系统视作一个产品，而非仅仅是一个项目。
在探讨产品策略构建时，我们可以找到众多现成的案例，甚至包括详尽的指导手册。然而，当讨论到设计系统时，这样的案例却相对匮乏。大多数情况下，我们所见到的都是遵循“标准设计系统”模式的方案，它们通常包含一些典型的组件和基本元素集（如标志、图标等）。
每家企业都有其独特的企业文化和业务需求。因此，设计系统应当体现公司的具体情况和需求。除了标准的组件和标记库之外，可能还需要根据特定需求添加其他元素。
2.发现
用户需求
与任何其他产品一样，设计系统同样拥有用户群体。因此，在制定策略时，最佳做法是先深入了解这些用户。这可以通过与设计师和开发人员进行一系列访谈来实现，并探索还有哪些其他利益相关者可能对使用设计系统感兴趣：
在设计和开发过程中，采用了哪些工作流程？
设计师与开发人员之间的协作机制是怎样的？
使用了哪些产品或框架（包括哪些不可更改的部分）？
目前面临的主要挑战有哪些？
最关键的优先事项或需求是什么？
等等。
商业需求
设计系统的核心目标之一在于协助企业加速产品的创建和维护过程，并提高其效率。为了实现这一目标，我们需要与产品经理、项目负责人以及公司高层管理人员进行深入访谈，以获取以下信息：
产品分析
对应用设计系统的产品（或多个产品）进行全面研究，涵盖设计、导航、代码实现等多个维度。同时，对比分析产品在实际应用中的外观表现与原始设计中的预期效果：
以及对代码的深入分析：
所使用的库（包括内部开发和外部引入的）。
架构的逻辑性及其在不同平台上实现的差异性。
组织资源的逻辑方法：如图标、标志等。
我们在当前阶段所积累的知识越丰富，对整个运作机制的理解越透彻，未来规划各项措施并预防潜在问题就会越加得心应手。重要的是，我们的视野不应仅限于主要产品，还应涵盖公司所开发和维护的所有附加应用程序和服务。这对于我们全面掌握所有的用户接触点很有帮助。
在此阶段之后，我们很可能需要一系列额外的访谈来澄清细节。
审查
如同进行任何复杂的产品研究一样，我们得到的输出是大量数据和见解的集合，这些需要进一步的分析和处理：
随后，我们需要向管理层展示研究成果，收集反馈，并了解管理层是否有进一步推进的意向。
3.工作坊
在当前阶段，我们应当积极推动各利益相关方（包括设计师、工程师、管理层等）参与工作坊。
如果我们计划从零开始构建设计系统，可以首先从组件拆分的练习着手。
然而，设计系统的意义远不止于组件本身。此外，鉴于构建设计系统可能需要数月的时间，仅关注当前需求是远远不够的。我们必须认识到，设计系统需要随着核心产品（甚至可能是整个业务）的发展而不断成长。换句话说，我们需要明确我们想要为用户创造的产品类型。如果我们暂时抛开设计系统的特定语境，这个问题实际上是在开发任何新产品时都会遇到的典型问题。我们可以使用开发“常规产品”时所采用的传统方法来解答这个问题。
产品的使命和愿景
要解答上述问题，通常建议首先明确使命和愿景。
互联网上有许多关于如何制定使命和愿景的文章和指南。然而，对于使命和愿景的来源及其相互关系，人们往往存在不少混淆。
例如，《设计使命宣言——示例和提示》文章中指出：
“设计愿景陈述描绘了组织期望在未来实现的目标状态，而使命陈述则阐明了其当前的设计宗旨和实施路径。”
衍生阅读：
《设计使命宣言——示例和提示》https://www.uxpin.com/studio/blog/design-mission-statement/
这种表述将愿景置于战略金字塔的顶端:
使命、愿景和价值观模板 https://www.figma.com/templates/mission-vision-values-template/
还有一种替代方法，将使命置于金字塔顶端：
使命 https://goalist.co.jp/en/mission/
Pioneer , Goalist , Nippon Koei 等许多公司都这样做。在本文中，我将使用这种第二种方法，因为对我来说更自然、更清晰（请在评论中写下您更喜欢哪种方法以及原因)。
从我的角度来看，使命是公司经常写在海报（或T恤）上的内容。例如，在宜家，它听起来相当抽象：
“为大众创造更美好的日常生活”
几乎所有现代初创公司都采用这种表述方式。坦白而言，这种措辞往往缺乏具体性。
相比之下，愿景则更为明确。它阐述了核心的商业理念或公司所追求的目标（或产品应为用户带来的价值）。在设计领域，这类似于所谓的最终愿景。以宜家为例，其商业理念如下：
“提供种类丰富、设计精美、功能完备的家居用品，价格亲民，以使尽可能多的人群能够负担得起。”
这种表述方式清晰地描绘了宜家的理念及其与竞争对手的主要差异。
在我们的情形中，采用设计系统，我们同样可以遵循这一路径：从设定一个简洁而普遍的使命出发，并构建一个旨在实现该使命的愿景。
例如，我们可以设定一个普遍的使命：“简化我们产品团队的工作流程”。或者，使其更具针对性：“让我们的产品团队在产品构建过程中的工作更加高效”。
然而，我们可以从稍微不同的角度来审视这个问题。当我们讨论可访问性、动态性以及其他诸多方面时，这些并非仅与开发人员和设计师相关，更与我们公司产品的最终用户——消费者息息相关。基于此，我们可以对使命宣言稍作调整：“助力我们的产品团队为最终用户打造卓越的体验。”
这完全取决于你如何巧妙地构思出既优美又简洁的短语。无论如何，当使命宣言听起来振奋人心时，总是一件好事。例如，Atlassian 的使命宣言，至少在我听来非常鼓舞人心：
“我们的使命是释放每个团队的潜力”
愿景的设定较为复杂。为了让愿景不仅仅是海报上的一句华丽辞藻，我们需要它能够明确指出我们期望在设计系统中实现的具体目标。
让我们再次以宜家为例：
“提供多样化、设计精良且实用的家居产品，以亲民的价格，使尽可能多的人群能够负担得起。”
通过措辞，我们可以清晰地辨识出主要的要求或组件：
提供家居产品
种类广泛
设计精良
价格低廉以便更多人能够负担得起
这听起来像是公司对每个即将发布的产品所设定的验收标准。同样的逻辑也适用于设计系统的愿景制定。让我们来观察一些实例。
帮助交付高质量的界面，同时加速上市时间。通过使 UX 和 UI 在团队中的设计师和开发人员之间易于访问，来赋予创造力。通过人们喜欢使用的应用程序重塑企业和开源世界。https://eos-mission.webflow.io/
“Material 是由 Google 创建的设计系统，旨在帮助团队为 Android、iOS、Flutter 和 Web 构建高质量的数字体验。https://m2.material.io/design/introduction
“Material Design 是一套可适应的指南、组件和工具系统，支持用户界面设计的实践案例。由开源代码支持，Material Design 简化了设计师和开发人员之间的协作，并帮助团队快速构建美观的产品。” https://m3.material.io/
“设计系统是一套标准，通过减少冗余来管理大规模设计，同时在不同页面和渠道之间创建共享语言和视觉一致性” https://www.nngroup.com/articles/design-systems-101/
上述示例实际上并非愿景的正式表述。然而，在我看来，它们完全有潜力被塑造成愿景。毕竟，这些表述中的要求都十分明确。在我的观点中，愿景陈述应当清晰地传达正在构建的设计系统的核心特征，这非常重要。否则，最终可能开发出与预期不符的产品。
4.倡议
规划阐述了目标与宗旨，这有助于实现使命，并达成理想的北极星愿景。在当前阶段，规划已经涉及到具体的资源：
标志
图标
表单元素
按钮
文档
用户消息
网格系统和断点
组件演示应用
等等
最好避免将单个组件单独视为一个倡议，这并不是因为“它在战略中太小，不足以构成一个倡议”，而是因为在处理组件时，更适宜将它们归类并分组为更大规模的倡议——即史诗级别的项目：
用户输入组件：包括文本输入框、文本编辑区、密码输入框等。
按钮类组件（包括所有外观类似按钮的元素）：如平面按钮、圆形按钮等。
用户提示信息：包括弹出式提示、横幅提示、全屏通知等。
通过在各自的组别中考虑组件，我们不仅可以关注设计决策的一致性，还可以进一步思考：
组件组合模式与模板：探讨组件如何协同工作
决策树模型
实践案例指南
文案创作技巧
等等
我们务必要铭记业务需求的重要性。毕竟，如前所述，系统设计的核心目标之一是协助企业更迅速、更高效地开发和维护产品。在考虑公司的产品开发策略、遵循最佳实践案例以及分析竞争对手所采用的方法的基础上，我们可以尝试预测未来可能需要的功能。
例如，若公司计划将其产品推向国际市场，我们可能需要考虑文案的本地化问题。
仅凭一份简略的举措列表是不足以周全规划战略的。由于某些举措可能归属于同一类别，而不同举措间又可能存在相互依赖性，因此需要明确标识这些关系，以便更好地掌握整体状况。我通常使用倡议卡的方法来进行管理：
在前述示例中：
倡议标题——揭示倡议的核心内容。例如，“语义化创意标签”。
描述——对倡议进行简洁的说明。比如，在标签标记的情况下，可以描述为“从硬编码的颜色值和颜色命名变量（如蓝色、灰色等）转变为与品牌色彩调色板相匹配的功能命名变量”。
愿景要求——明确倡议满足的愿景要求。对于每项倡议，我们都需确保其从愿景的角度来看是有意义的，以保持清晰的焦点，并避免在与使命/愿景不相关的事情上耗费精力。
行动计划——列出使倡议得以实施的具体行动项。例如，在“语义化核心标签”的情况下，可能需要处理命名规范、文档编制等事宜。
价值/机遇——倡议将为公司及用户带来哪些价值或机遇。
依赖性——本倡议依赖于哪些其他倡议？即在实施本倡议之前需要完成哪些工作。比如，如果我们讨论的是“暗色模式”倡议，可能需要将“语义化软件标签”作为其依赖项。明确依赖关系有助于我们了解以何种顺序推进各项倡议最为适宜。
策略
最终，策略制定环节最为有趣 😅。
在这次工作坊中，我们需要设计、产品和开发领域的关键代表参与。主要目标是规划出首版以及后续迭代的蓝图。为简化流程，我通常采用一种简洁的分解方法：
短期（1.0版本）
中期（迈向下一阶段）
长期（终极目标）
在工作坊上，我们将根据优先级和依赖关系将倡议卡按类别进行组织。此外，还需讨论实施特定举措所需的资源。在构建设计系统时，最关键的资源无疑是人才和时间。我们不太可能一开始就组建一个完备的“梦幻团队”。因此，在规划短期或长期举措时，我们必须考虑它们需要什么样的团队配置，以及我们是否能够在恰当的时机拥有相应的团队。
例如，我们可以从一个小型团队着手，团队中包含数名设计师以及2-4名移动开发人员。相应地，如果我们的计划中包含网页开发或后端工作，在初期阶段我们可能还无法承担这些任务。同时，根据这些任务的紧迫性，我们可以判断在哪个阶段需要补充缺失的资源：是否可以将这些任务安排在中期（或更晚的阶段），或者是否需要与管理层探讨扩充团队的可能性。
策略周期
考虑到需要兼顾的众多因素，此阶段将涉及多轮会议，并可能需要更多参与者来深入讨论细节。具体来说，需要探讨以下议题：
技术细节讨论：需要确定所需框架（以及是否需要对现有架构进行重大修改），明确预期的开发环境，以及设计等相关问题。
探讨潜在的设计系统团队成员（包括潜在的领导者）。可能需要进行额外的招聘工作。
关键流程的梳理：包括团队工作流程、产品发布、实施过程、用户支持等。
确立衡量项目成功的标准至关重要。在项目启动之初就考虑集成分析工具到系统中，例如统计工具等，是一种明智的做法。这些数据将成为向管理层汇报的关键内容。
细节至关重要，缺少它们将导致难以制定清晰的路线图，并准确预测完成首期工作所需的时间。
路线图
目前，大多数产品团队采用敏捷开发方法。这通常意味着开发周期会根据当前产品需求进行调整，任务规划仅覆盖一个或两个冲刺周期。然而，在设计系统的情况下，我们需要采取瀑布式开发方法：提前数月进行规划。即便团队选择以冲刺方式工作，我们也需要为整个首个发布周期制定清晰的路线图。需要对每个计划及其包含的任务进行大致评估。
我们需要保持现实的态度：提前精确预测一个项目所需时间是相当困难的。不过，凭借充分的经验，我们能够进行大致的估算。在此基础上，我们可以为项目初期的几个月制定一个初步的计划。
5.提出策略
“归根结底，如果缺乏关键人物的支持（无论是掌握资金的高层管理者，还是实际使用产品的用户群体），任何战略都是没有意义的。因此，你必须能够推销你的战略。这通常意味着需要准备一个演示文稿。”——内森·柯蒂斯
尽管在战略规划上投入了大量精力，但如果管理层不予以批准且不提供必要的资源，整个项目仍有可能面临失败的风险。在这种情况下，计算设计系统的投资回报率（ROI）将极大地有助于推广这一理念。
目前，已有专门的计算工具和相应的公式用于估算设计系统的投资回报率。
投资回报率的计算方法在很大程度上取决于所采用的设计系统模型。例如，内森·柯蒂斯识别出三种主要的设计系统模型：
独立型——采用现有的开放性、现成的系统。这种方式能够实现快速启动，但在后期可能会遇到限制和灵活性问题。毕竟，初始系统是由第三方团队创建的，在这种情况下，很难保证所有需求都得到充分考虑。
集中型——由一个专门的内部团队工作室负责开发和维护设计系统，将其作为内部产品。这种模式有时被批评为设计系统团队与产品团队“脱节”，产品团队的需求并不总是被充分考虑。
联合型——由产品团队中的顶尖设计师和开发人员共同努力创建设计系统。
在我看来，将集中型和联合型相结合更为可取：
本文无意成为一部终极指南，而是提供一系列实用的技巧。如果这些技巧对您有所帮助，我将感到非常高兴。
感谢您的阅读！让我们保持联系！您可以通过 LinkedIn 与我取得联系，并在 Dribbble和 Medium 上关注我，以获取更多设计相关的优质内容。
作者：Sepeda Rafael
译者：李泽慧
审核：李泽慧
编辑：林庭婷
本文翻译已获得作者的正式授权（授权截图如下）
- END -
注：交互设计学堂公众号接受投稿啦，如果你有好的原创设计类文章，可联系客服。别让灵感溜走，快来投稿吧~~
