作为全球人气最高的开源社区，Github 的设计系统是如何进化的？

作为全球最受开发者的开源社区，Github 的设计团队是怎样构建自己的工作流程的呢？Github 设计系统的理者 Diana Mounter 通过这篇文章讲述了 Github 设系统的整化史。

设计系统现在已经成为我们整个设计构建流程的核心。从2011年起 Github 的设计师就已经抽象一套 UI 模式和公共样式。2012年，有这些公共样式和它资源就被打包成了一个设计系统的雏形——Primer，并应于 Github 有的点。Primer 在被使了很多年，最终它有了一套整的 CSS 和档，并被开源。2016年设计系统团队成立并拥有了全职人员维护。这篇章要讲述这个团队及设计系统的演进历史，及我们现在正在做的和将来要做的事情。

从0开始

在 Github 我们的产设计师和页设计师是需要编写产代码的，有时候还需要自己实现自己的设计。可有一些人会继续深入研究技术栈，但 CSS 是每个设计师都要掌握的。就是说设计师是 Primer 的首户，并且他们最先发现一些样式问题，或者是档错误。

△ 2015年的 Primer 档

当我2015年加 GitHub 时，我注意到有很多设计模式在档中是没有的，因此我需要自己写很多的 CSS 来填补它们。同时，我发现我们没有一个层的系统将这些设计模式联系起来。此时我萌生了想要做一些事情的想法，我觉得我们可做得更好，庆幸的是我发现止我一个人有这个想法。我们实有好几个人都在尝试它变得更好，只是大却没有着同一个方向前进。在当时设计负责人的协助，我们成立了一个小组，定期碰面讨论如何优它和我们的工作流程——这是最早期的设计系统团队。

△ 2016年3月的一次设计会议，我们定制计划并进行头脑暴。我们都是远程的，一般我们都是定期碰面。

显示出我们的价值

我们首先解决那些影响最大的问题，及在设计过程中给设计师带来最大痛点的问题。

我们添加很共的样式，比排版、颜、间隔，以及一复用的组件，来避免其他人不断往里面添加新的能重复的 CSS；我们把已有的设计模式也优化一下，减少重复代码和无用的变化；我们还抽象提取很以共用的东西，统一命名规范，以持一致。

此同，还同步完善文档，将以前没有提及的计模式添加进去，并编写了计则和可访问性指南。

△ 2016年的一个早期内部版本

按照既定日程不断解决些痛后，我们设计师和开发员带来价值开始凸显，这为我们后续提升识性和设计系统价值做了铺垫。2016年年底，个文档几乎覆盖了所有设计模，在设计时我们不需要都写堆 CSS。我们也有了第个设计系统团队——虽然有我和 Jon Rohan 俩。

不断增长的痛点

设计系统开始被广泛使用时，我们需求也逐渐增多，并追踪管理这些需求也开始变困难。在 Github，我们般都是在 pull request「1」或者 issue「2」提及（@）某个团队来寻求反馈，被提及或团队会收到站内知或邮件。段时后，我们被淹没在提醒里，反而导致我们会忘记些事情，并不能很好地在内部广我们设计系统。在「黑客」大会上，我们决定优先解决这个事情。

我们制了一些新的流程：

使团队发布来更广泛地发布设计系统更：在 GitHub 我们还有一个工具叫做 Team，一般是来发布重大更，特性上线，或者是的职位空缺。我们开始使 Team 的发布功在重大更之前来通知有人 Primer 和设计规范更，同时分享更多相信息。

让更新的状态更加明显：因为我们的更新频率很快，所以我们需要更加明显的标志，来告所有人哪组件是以安使用的。我们创建一个更新志来同步更新，并在文档上标明每个模块的状态。和 Lightning 设计系统的状态差不，我们的是包含稳定版、新、评审中、验特和已废弃几种。

实行「随叫随」轮岗制度：Github 的每个队都在实行「随叫随」轮岗制度，不过叫做「第一响应人」。这个人轮岗要去理一些事项，及响应别人的帮助请求或代码评审。这，该队其人就可以专注于更加深入的工作。

△ 在 Slack 中使用一个撸的 Hubot 脚本帮查「第一响应人」需要注的工作

扩大我们的影响力

当 Primer 开始在 Github 中被更加广泛地使用，就需要规模化的流程，以保证它可以更加高效，也更有心使用它。

  1. 优化流程

我们自己的工作流程中最大的痛点就是 Primer 每次的发布。因为每个模都是单独存放在自己的仓库「3」维护的，这就使得整个系统的更变得无困难。每次我们都得小心翼翼，免使时遇到问题。我们经会填写一个重复的版本号，或者忘记更某一个模，或者知道这次更会给在线产带来的隐患。我们急需一个更强健的流程来更好地检查每次的更。

我们的决办法是将所有模块集中管理，并使用 Lerna「4」来帮助我们管理版和新版。更新几次之，我们开始使用 Travis CI「5」来自动构建预初版。也就是说，每当有人提新的 pull request 时，系统就自动构建一个版，他就以下载个版在自己的项目中进行测试。对正式前测试改动很有帮助。

△ 使用 Travis CI，当有人提 pull request 时自动构建并至 npm

  2. 机器人来做这件事

随时间往后推移，我们发常需重复给出一些反馈，比如「尽使用已的公共样式」这种。此，我们写了一机器人脚本自动这件事。这机器人会新的 pull request 时自动论，告诉作者哪些方需修改一下，并且提供相关的文档链接。这给我们节约了很多时间，并让多人不知不觉中学习了我们的设系统规范。

△ Servbot 一 pull request 下方论

我们继续发现重复的工作项，并尝试通过自的方式升它。今年我们使我们自己开源的 Probot 机器人、Figma 接口和 Travis CI 来自我们的图标库 Octicons 的发布流程。

  3. 例行办公时间

除了「第响应」制度，我们有三天例办公时留其他问问题。般这个时我们会进结编程、讨论需要我们帮助品发布，以及解答些用问题。

△ 我们在 Slack 内进例办公，这样所有都能知，并我们忘记时会提醒我们

扩大团队

凸显设计系统价值这件事使我可以让团队成长。作为团队负责，我经常要新们讲解案例，使他们明白设计系统带来积极影响，比如说它让我们在发布新特性时更加高效，工程师们可以在不需要设计师协助情况下提前做更多事情。我般更倾于新讲述我们正在做很厉害事情，以及未来可能会帮助更多事情，而不告诉他们我们不能做什么。

2017我们团队了一新的设系统设师，Shawn。Shawn 自于 Web 标准，之过设或设系统相关的作验，他善于从设角度去一些发的决。

今年（2018）我们招了第一个全职的工程师，Emily。她之前在 Buffer 做前端工程师，开发维护他们的组件库。Emily 具有 React.js 和可访问性的经验，这对于我们当前的团队或工作是很重要的。

△ 同时间我们需要同类的人

无论我们招的是设计师还是工程师，我们要求一通用技能。我们要求开者具有设计敏锐度，样能做出更的决定来构建设计系统，使其以更地服务设计。我们也要求设计师具有基的代码读写能力，能够从开的角度思考，并根据开的经验进行设计。很重要，因为设计系统融合设计和开，我们需要给设计和开提供一致的设计语言。

扩展我自己

为团负责人和管理者，我也要提升自己的影响力。相比一年前，我现在带更的人，往我还要管理更人，以及开始构建我们的设计运务。意味着我不能为一个普通的工者，不问世。今年早时，我现我遇到自己的瓶颈——我更像是一个设计系统的编辑者，而不是者。

过去给这个计系统贡献了多视觉计的工作，并且作为最主要的决定者。现在正在学习如何将这些工作摊一部给其成员，如果有不懂的，会教。

扩展我们的构建方式

最有趣的会议（是的，会议也可以有趣）是每周组件评审。此每位提交了新组件的成员会带着过一遍的代码，给展示如何使用，效果是怎的，并征求一些见反馈。这保证创造出一个体验一致的计系统。

△ 当猫和会跳舞的同事加入会议会变得更有趣

下一步

每年都会定目标，下面这项虽然没有覆盖所有，但是一直是2018年所专注的。

  1. 更现代化的前端技术栈

Github.com 的前端技术栈分散而老旧，我们在构建 UI 时需要考虑的事情特别多。

与其分心各种不同的编程语言（比 HTML、CSS 和 JavaScript），我们不注组件面。为达到个目标，我们今年主要的任务就是构建一个基 React.js 的组件库。现在我们已经开始去做，等个组件库达到一个稳定版我们就开源它。有一团已经开始使用 React.js ，我们希望能够尽快让他们使用到我们的组件库。我们的应用系统团已经帮我们做一情，帮助我们更容易地将设计系统接，我们需要紧密合。

△ 我们的 primer-react 组件库演示沙箱

  2. 创一个更好的协作模式

我们看到多团队参与设系统的构建，不只我们团队。我们人们使用 Primer 时感觉简单，也易学习。因此，我们花了很多时间去研究设具、实践教程、发具，以及简化参与流程。

今年我们将设计组件转移到了 Figma，并使 Figma 来进行可交互原设计。Figma 是基于 Web 的，这意味着我们可整合进设计系统工作流中的它工具，而且限于 macOS。Figma 的公共样式特性可帮助我们取注入颜色、版等样式，和我们在代码中的实现方式类似。Figma 还供对外接口，可帮我们很容易地接入它自流程，如说根据我们代码中的组件来检查 Figma 中的组件是否符合规范。

△ Figma 中的 Primer 颜色样式

今年时，我们将去探索代码原型工具。在设计流程确定的阶段我们使用图形化的设计工具是很的，但有时我们需要做更进一步的探索。在 Github 很设计师是直接撸产品级的代码，但样也不，因为每次需要进行一前期的基础搭建。还有一设计师在 Codepen「6」中使用我们之前的一模板。

△ Primer 在 Codepen 中的项目

知道这种方式其实都不是完美。计需要经常做一些页面型或流程，需要能够快速调整计效果，就像在图形化计工中一。这在产品代码中难做，而使用 Codepen 中的模板味着在专注于业之前需要写多代码。理想的情况是计需要能够快速开始，使用真实或近真实的产品数据来构建页面。知道这对于多公都是一个挑战，希望能够找一个解决法。

  3. 持开放

我们希望 Github 是人们在谈论设计系统时首先想到的公司之一。许多公司开始构建自己的设计系统，这是一个断发展的领域。我们将会断分享这个过程中的一些想法，期帮助到你们。

今年早时我们开新版的样式指——我在一次设计系统的活动中曾分享，同时我也谈论到人们关自己司的设计系统和其他司设计系统相比的问题。其比是没有意义的，我们应该注去创造自己的度量标准，因为别人的并不一定适用你。即使是我们的设计系统，也有很 bug 和提升的空间。所以我得我要分享我们的设计系统，包括缺点。

△ 我们的样式规范文档

一直在开放地工作，在的公开仓库中不断发布着新计划。将继续享一些新项目，也许它可以直被用其人的计系统，或者能够启示人如何去做。也会写更多的文章，去做一些享，或参社活动中。

如你有什么想要知可以在这里（Primer 仓库）开 issue 来告诉我们。

△ Primer 项目看板

GitHub 将持续投入到设系统中，我们也将持续努力到好，分享我们功或失败的验。如果也参与到我们的设系统中，发者创造好用的产品，可以加入我们。

相关链接及注释：

• 式规范：https://styleguide.github.com/
• Primer：https://styleguide.github.com/primer/

1. pull request：成员往项目代码中交特性或修复的请求
2. issue：类似项目协中的任务，用追踪需求或 bug
3. 仓库：代码仓库，可以做一个项目的所有代码文件集
4. Lerna：管理版本工具
5. Travis CI：持续集具，自动化触发码测试、编译或部署
6. Codepen：前端工程师展示作的地方

欢迎关注作者的微信公众：「codesigner」