原文作者 Matt Bond ，正是知名的 Atlassian Deisgn System 的创建人，真正的元老本老。《设计体系》一书当中也有多处以 Atlassian 为例，印象非常深刻；唔还没有读过C版全书译文的朋友不妨一观（公众号“Beforweb”）。
斑斑无聊地在四周溜达了一圈，嚼碎几颗猫粮，声音在夜里越发清脆；继而跳上床，把手弯起来埋在胸前，内心毫无波澜地卧了下来，双眼渐渐眯成了缝。是蛮久没做过译文了哦。今天这篇做得还有点儿小兴奋。
Atlassian 设计体系元老的经验分享
2012年，我启动了一个副项目：对 Atlassian 当时12款软件产品的设计模式进行标准化定义工作。在那之后的三年里，这个副项目逐渐成长壮大，并成为了我的全职工作；经过一系列的版本迭代，这个项目最终成为了大家所熟知的 Atlassian Design System。期间，我还成立了设计平台团队（Design Platform Team），专门负责对设计体系进行管理维护，并将其运用于 Atlassian 产品套件的设计工作当中。
近些年来，行业里出现了越来越多关于设计体系的讨论，我也时常被问及相关的经验与洞见（注）。无论你在考虑为自己的产品创建设计体系，还是正在进行当中，或是曾经尝试但以失败告终，我都希望这些经验可以帮助到你。
译者注：包括接受《设计体系》一书作者的访谈；相关内容也体现在书中。
如今在 Asana，我又开始了新的设计体系构建之旅；回顾过往的经验，我发现它们同样有助于我们将团队与公司推向成功，从而体现出设计体系真正的价值所在。
1. 以小为始
第一个版本的 Atlassian 设计体系只包含20个静态 HTML 文件，由我桌下的那台 Mac Pro 充当服务器。没有模板，没有版本控制，我亲自动手为每一个组件编写 HTML，并将线上产品的 CSS 直接导入过来作为样式表。虽然这一版本更新起来非常困难，而且不具备扩展性，但它也足够向当时的团队展示设计体系的基本价值了；我因而得到支持，并得以将更多时间与精力投入其中，逐渐摸索到了正确的道路。
反之，如果从一开始就考虑到各种扩展性问题，那么我们很可能需要花费数倍的时间来完成起步阶段的跨越。如果你刚刚开始构建设计体系，建议你不要沉迷于无缝、完美的流程和机制，取而代之的是简单快速地起步，验证价值与方法，并保持迭代。
2. 重在质效提升，而非控制设计
如果你认为构建设计体系的目的在于防止其他人“犯错”，防止他们破坏掉只有你“有权”定义的规则，那么你们的体系构建工作很可能是在不正确的观念之下进行的。
设计体系的目标是提升团队的设计质效，帮助每一名设计师更加合理地进行设计决策。
你的工作并非将规则强加给他人并监督他们执行。反之，要将设计体系视为在公司内部实现“设计民主化”的工具。只有这样，人们才会有意愿参与其中并进行贡献。
务必记得，设计体系是一种强化工具，而非用于控制设计的监管手段。
3. 避免同步进行重设计工作
不要将设计体系的构建工作看作是产品重设计的契机。一边进行着体系化定义，一边对产品进行重设计，这会极大地拖慢工作进度。更合理的做法，是首先对产品当前的状况进行记录与清查，包括合理与不合理的模式在内；完成标准化定义之后，再回过头来进行优化工作。
在 Atlassian，我们曾经多次试图在设计模式文档的基础工作完成之前对产品进行重设计。诚然，设计模式的定义与文档化工作需要花费大量的时间，但以此为基础进行新一轮的设计迭代，整体进程会更加轻松和高效。
4. 跨职能寻求支持
设计体系的创建工作并非学校里的课业练习。如果最终无人使用，或是无法有效提升设计质效，那么我们的工作就是浪费时间。
只有让其他人了解你的工作并参与贡献，你才能得到越来越多的认同与支持。这一点对于设计体系工作非常重要。
2013年时，我们团队当中的设计师与工程师占比大约在1:15到1:20之间。直至如今，回想起这个数字，我仍然会感到惊悚；不过当时，我确实有试过将这种失衡的局面转化为工作中的优势，使工程师们更加认同设计体系相关工作。我会在新人入职当周做一些宣讲，每周有15人左右的样子；为了让他们从第一天起就能对设计体系的目标与价值有所了解，我会给他们讲一些往事，譬如我们的产品当中曾一度存在着44种下拉菜单，而如今已经标准化为一种，它的具体使用方式应该如何如何。
经过那一年的宣讲，加上 Atlassian 的规模几乎每年都会翻番，我总共帮助了将近500名新人了解了设计体系的重要性及使用方式。同时，这项工作还在潜移默化当中扩大了设计职能在整个企业文化当中的影响力。
5. 超越“设计规范”
设计体系不同于设计规范。创建一份包含了所有组件的 Sketch 文件或许相对容易一些，譬如所有的主操作按钮都有着相同的配色，或是统一使用8像素栅格等等。但应该在何时使用主操作按钮而非次级按钮？按钮中的文本应该采用哪种类型？主、次按钮同时出现时应该怎样布局？
设计体系必须针对这类规则性的问题提供解决方案，而不仅是记录规格规范。很多团队都忽视了这一点，致使设计体系的价值有所缺失。
正如前面提到过的，在2013年初，Atlassian 设计团队的规模（约13人）相比于开发团队（约300人）来说还相对较小。明确提供设计模式使用规范的好处在于，工程师可以在设计师人力不足时独立完成大量的页面构建工作。这意味着在很多时候，设计师无需打开 Sketch 制作高保真设计方案，大家可以通过白板和脑暴直接确定功能流程，或是将更多时间用于上游高层面问题的处理。
6. 少数人负责管理，多数人参与贡献
我们在 Atlassian 采用了集中式的设计体系管理机制，一方面允许每一名设计师参与贡献，一方面通过每三个月的轮岗制度从不同的产品团队当中抽调设计师与工程师加入我们的平台设计团队。在三个月的时间里，他们会对设计体系的维护工作进行大量的贡献；三个月后，他们回到各自的团队当中，成为设计体系的簇拥者与布道者。
有专人负责设计体系相关工作是非常重要的。这个人（通常指我）更像是设计师当中的产品经理，他需要维护整套体系，同时又要避免营造出让人抵触的工作氛围。始终不要忘记，我们的目标是提升设计质效，让每个人都成为更出色的设计师，并最终实现团队效能与产品质量的提升。
原文地址：MEDIUM.
译文地址：beforweb
作者：Matt Bond
译者：C7210
