【译文】如何冲破设计系统的界限

原文：How to push the limits of a design system · Shopify UX

作者：José Torre

译者：李瑞东

翻译小帮手：李泽嘉 @urcharles7（公司的交互实习生）

本文 2022 年 8 月 12 日首发于 Medium · 查看原文 

为了跟上需求，设计系统需要不断发展。讽刺的是，设计系统的进化似乎有点像先有鸡还是先有蛋的问题。

如果不知道产品业务需要什么，专门负责设计系统迭代的团队就无法进一步发展。另一方面，大多数业务设计团队只在系统的现有规范和组件内完成工作，这不利于进一步推动系统的发展。这样看上去像是僵住了，大家都在停滞不前。

我们 Polaris 团队（译者注：Polaris 是 Shopify 的设计系统）想打破这种僵局，所以采取了行动……

跨越鸿沟

为了防止 Polaris 变得失去创造力，我们必须更接近产品。因此，我们开始了一项名为 PolarisLab 的计划。在几周的时间里，围绕一个特定的主题，与产品团队发起并参与了一系列工作坊和会议。目标很简单，就是要设计系统团队与产品团队紧密合作，以便：

1. 帮助团队找到解决问题的最佳方案；
2. 找到设计系统不断发展迭代的方法。

我们的首先聚焦在 Layout 组件上。因为我们开始注意到越来越多的页面似乎不是专门为解决一个问题设计的。相反，页面的设计来自设定好的多个模板之中（以页面布局组件的形式）。这些模板是相当通用的，但并不总是解决一个单一问题的最佳方案。

过度使用这样的模板可能会使页面看起来在视觉上一致，但会让用户感觉到没有重点和枯燥乏味。

刻板地遵循设计系统提供的模板，使得会出现让内容来适应页面布局，而不是内容主导布局。这使得浏览一个页面变得困难，需要用户花费大量的精力去弄清楚需要的内容在哪里，以及下一步该做什么。

我们还注意到，由于我们的 Layout 组件过于死板，导致团队经常脱离 Polaris 来做一些细微的布局调整，这就导致了代码层面工作量的增加。

我们已经明确了想要解决问题的，甚至已经有了行动的代号，但我们缺少最重要的部分——团队。

寻找团队

我们希望找到那些有兴趣与我们的团队合作改进 Layout 的团队，而且是热衷于发展 Polaris 设计系统的团队。幸运的是，公司里有很多这类型团队。

我们联系到了 7 个不同的团队，在了解到他们的问题空间和最近的工作排期后，我们决定与做 B2B 客户业务的团队合作，因为他们满足了所有条件：

1. 能够有效地解决问题 ✅
2. 该案例有可能对其他团队产生影响和启发 ✅
3. 能够在紧迫的截止日期前交付 ✅
4. 对开始工作超级兴奋 ✅

不久后我们明确了项目的目标，并开始了合作。我们设定的工作流程并不复杂：

第一步：了解问题

第二步：发散和探索

第三步：收拢和校准

第四步：重复第二步和第三步，直到满意为止

第五步：推进实现方案！

了解问题

通过一系列的 Workshop 及相关活动，我们对这个问题有了更好的了解。

我们首先要求团队做一个现状收集。简单地把一系列的截图和设计放在 FigJam 上，然后让我们去了解业务设计师当时遇到问题，以及他们做的解决方案。

我们都发现了这个 B2B 客户页面大多是聚合了企业客户有关的所有内容，但它在帮助商家快速了解这个特定客户方面做得并不出色。内容缺乏清晰的层次，所以最终效果不理想。

为了开始了解这个问题，并更好地了解页面里什么最重要。我们写下了这个页面里用户所有可能想要完成的工作。然后我们反复调整排序，以确定优先级和重要程度。这是我们最终得出的的结论：

1. 观察购买行为；
2. 手动为客户下订单；
3. 快速访问到地点和联系人；
4. 评估不同地点之间的销售情况；
5. 针对不同地区更改服务条款；
6. 查看操作日志。

通过小组讨论后，我们都认可了这个优先级排序。然后我们又尝试代入商家的身份去假设他们的目的，以确保我们目标一致，达成共识。然后投票选出了一个最接近目标的假设，那就是：

“如果显示的信息集中在一个页面上，商家将能够更方便地完成任务。我们可以通过完成一项特定任务所花费的时间来衡量。”

上述这些工作并不意味着产生实际的可交付的方案，而是让每个人都能够：

1. 更了解业务背景，让每个人都在对这个案例有相同的认识；
2. 开始对内容进行更细致的的优先级排序。因为我们不能仅通过移动元素来实现更有目的性的布局。我们需要从信息层开始，并在此基础上进行构建。

为了让大家更进一步，接下来是用草图来构思问题可能的解决方案。这里的目标不一定是找到解决方案，而是为今后的探索定下了基调。

我们鼓励每个人参与到 Workshop 的同事都尝试去画点草图，不管你是工程师还是设计师。有些人在 Figma 上画，但大多数人只是抓起一张纸和一支笔，一旦完成，就拍张照片，然后贴进 FigJam。

通过让同事们自由地画草图，不受设计工具或 Figma 组件库的限制，我们更有可能创造性地解决这个问题，而不一定要遵循预先存在的模板。

在画了一会儿草图后，每个人都分享了他们的想法，我们发现了一些有趣的事情。在画草图的时候，人们开始把客户在页面里可能想要完成的工作作为一个整体来考虑，而不是把注意力放在个别内容上，然后按照模板把它们组合在一起。

这是一个好的开始，因为商家会体验到整个页面，我们就应该这样去做设计。

在每个人分享之后，我们讨论并投票选出了最有希望的想法，这将是后续工作的基础。

发散和收拢

由于大部分探索是设计先行的，我们后续还通过几次包含一名产品经理和几名工程师的 Workshop 来协调和讨论。我们在会议前花了一些时间完善方案，拿到会议上讨论并一起看看有没有可以做得更好的地方。

Workshop 之后，设计师们根据讨论的结果继续细化方案。我们想跳出设计系统的界限，但最终解决方案必须符合 Polaris 风格，这是一个很难去达到平衡的事情。对于我们引入的任何新元素，我们必须再三斟酌，要了解它是否能融入 Shopify 里面，并且可以复用到其他团队里。

当我们探索信息的不同组织方式时，我们意识到拥有一个完善的 Grid 设计基础准则是相当重要的，它可以确保不同页面之间有一定程度的一致性，即使信息的组织方式不同。

我们不仅是把页面作为一个整体来看，为了建立层次结构，我们还必须深入去找到更好地利用颜色、空间和文字排版的方法。我们通过有策略地运用颜色，突破字体规范探索更大的字号，来给最重要的元素增加了视觉权重。使它们与其他元素形成鲜明对比，并吸引人们的眼球。

我们还减少了页面中卡片的数量，更多地依靠空间来分组和分离信息。

随着我们的方案逐渐成熟，我们开始与产品和研发部门讨论方案。最终我们经过讨论和方案对齐后，找到了一个多方都认可的解决方案。

通过重新设计，我们使商家能够更轻易地快速了解一个 B2B 客户。

与其简单的在网页上堆砌信息，指望着商家费尽力气去获取想要的信息，我们干脆重新梳理了一遍网页的内容。我们强调重要的信息，弱化只需要低频获取的信息。最终，让获取重要的事情变得简单，同时保留获取其他所有信息的触点。

作出妥协

然而方案的推进并没有那么美好。我在开始时提到过 Deadline 迫在眉睫，我们只能将解决方案分步交付。

在推行某个方案时，很少有不需要做出一些妥协的，特别是当 Deadline 很紧迫时。这是产品开发过程中很常见的现象，但这并不意味着要在设计质量上做出妥协。

而为了能够做到这一点，你需要了解技术的限制是什么及其原因。

这正是 B2B 团队所做的。例如，在页面中引入新的数据指标和数据洞察是很难的，但他们没有放弃这个想法，而是争取引入任何可以实现的东西，因为他们知道这对商家来说是非常有用的，可以在未来迭代和改进它。

创建可扩展的解决方案

与此同时，我们已经开始在 Polaris 团队中探索新的 Layout 设计准则。在整个协作过程中，我们了解到我们的原本布局组件限制太多，所以我们构建了一个 Grid 布局组件，让我们更容易地构建自定义布局，同时不会脱离设计系统。

团队想要创新，但设计时需要有一定的规则来约束，有时候甚至要依据设计系统已提供的模板。

这次合作让我看到，我们并不缺乏创新的动力和能力，缺乏的是一个目标。当你不知道该做成什么样子时，通常都会呆在舒适圈内，这是会让人上瘾的。

让系统团队积极探索新方式和与他们合作，能够得到新的做法。但这只是一次性的，不可扩展的。所以我们需要找到方法将这种做法纳入到设计系统中，让其他业务和团队的设计师也能复用。

Grid 布局组件是处理「设计创新」和「遵循规范」之间平衡的的一个很好的例子 — — 能够让设计师在 Polaris 内创新。

从技术上讲，团队可以不用 Polaris 来实现任何东西，但这导致了不一致性、不规范的体验设计和许多冗余的代码。这使系统更难维护、更新和扩展。

Polaris 是一个工具。我们利用它来发挥我们的优势，但我们不能忘记维护和发展它。就好比如果一把刀变钝了，你不需要去买一把新的，而是要把它磨利。

这次合作很有趣，同时也很有影响力。因为我们在产品和系统上做了改进。

我们不仅一起发布了一个新的布局，而且我们还确立了从整体上改进设计系统的方法。看到这项工作被刊登在 Shopify Editions 上是特别荣幸的。我真想快点看到 B2B 业务实现完整的设计方案之后的效果，以及其他团队使用我们建立的 Grid 布局组件。

如何开始？

如果像 B2B 团队一样，你想推动你的设计系统向前发展，我可以推荐两种方法中的一种。

选项 A：与设计系统团队合作

如果你正在研究一个问题，希望能突破原有的界限，并看到影响整个产品的设计模式的可能性，请考虑与你的设计系统团队联系。

设计系统团队会想要极力避免出现单一的解决方案，但他们很可能倾向于如何让设计系统更好用。特别是这件事对整个公司内的其他团队有可能存在的好处时。

为了证明这一点，我可以告诉你，我已经与另一个团队合作去解决另一个问题。我希望像这样的合作越来越多，因为这种合作确实能给产品和团队带来很多好处。

可惜的是，我知道一个设计团队未必能和所有人合作。但这不应该阻止你创新，还有另一种方法…

选项 B：动员你的团队

其实在与产品团队合作时，我们设计系统团队的主要工作是启发和支持。

这也是我分享这个研究案例的原因。向你展示我们做了什么，我们是如何做的，以及为什么这样做。希望这能启发你，同时也给出了一些可以复用的方法。

要记住的关键一点是，在孤岛上创新真的很难，所以寻找与你有同样热情的合作伙伴。如果你需要快速尝试，不妨用我创建的模板去实际尝试一下前文描述到的 Workshop。

当你完成后，别忘了为设计系统「赋能」噢！