作為全球最受開發者歡迎的開源社區，Github 的設計團隊是怎樣構建自己的工作流程的呢？Github 設計系統的管理者 Diana Mounter 通過這篇文章講述了 Github 設計系統的整個進化史。
設計系統現在已經成為我們整個設計構建流程的核心。從2011年起 Github 的設計師就已經抽象出一套 UI 模式和公共樣式。2012年，所有這些公共樣式和其它資源就被打包成了一個設計系統的雛形——Primer，并應用于 Github 所有的站點。Primer 在內部被使用了很多年，最終它有了一套完整的 CSS 和文檔，并被開源出去。2016年設計系統團隊成立并擁有了全職人員維護。這篇文章主要講述這個團隊及設計系統的演進歷史，以及我們現在正在做的和將來要做的事情。
在 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 中被更加廣泛地使用時，我們就需要規模化我們的流程，以保證它可以更加高效，我們也更有信心使用它。
我們自己的工作流程中最大的痛點就是 Primer 每次的新發布。因為每個模塊都是單獨存放在自己的倉庫「3」維護的，這就使得整個系統的更新變得無比困難。每次我們都得小心翼翼，以免使用時遇到問題。我們經常會填寫一個重復的版本號，或者忘記更新某一個模塊，或者不知道這次更新會給在線產品帶來的隱患。我們急需一個更加強健的流程來更好地檢查每次的更新。
我們的解決辦法是將所有模塊集中管理，并使用 Lerna「4」來幫助我們管理版本和發布新版。更新幾次之后，我們開始使用 Travis CI「5」來自動構建發布預初版本。也就是說，每當有人提交新的 pull request 時，系統就會自動構建一個版本，他就可以下載這個版本在自己的項目中進行測試。這對于正式發布前測試改動很有幫助。
△ 使用 Travis CI，當有人提交 pull request 時會自動構建并發布至 npm
隨著時間往后推移，我們發現經常需要重復地給出一些反饋，比如說「盡量使用已有的公共樣式」這種。為此，我們寫了一個機器人腳本來自動做這件事。這個機器人會在有新的 pull request 時自動評論，告訴作者哪些地方需要修改一下，并且提供相關的文檔鏈接。這給我們節約了很多時間，并讓更多人不知不覺中學習了我們的設計系統規范。
△ Servbot 在一個 pull request 下方評論
我們繼續去發現重復的工作項，并嘗試通過自動化的方式提升它。今年我們使用我們自己開源的 Probot 機器人、Figma 接口和 Travis CI 來自動化我們的圖標庫 Octicons 的發布流程。
除了「第一響應人」制度，我們每周還有三天的例行辦公時間留給其他人問問題。一般這個時間我們會進行結對編程、討論需要我們幫助的產品發布，以及解答一些通用問題。
△ 我們在 Slack 內進行例行辦公，這樣所有人都能知道，并且我們忘記時機器人會提醒我們
凸顯設計系統價值這件事使得我可以讓團隊成長。作為團隊負責人，我經常要給新人們講解案例，使他們明白設計系統帶來的積極影響，比如說它讓我們在發布新特性時更加高效，工程師們可以在不需要設計師協助的情況下提前做更多事情。我一般更傾向于向新人講述我們正在做的很厲害的事情，以及未來可能會幫助更多人的事情，而不告訴他們我們不能做什么。
2017年我們團隊來了一個新的設計系統設計師，Shawn。Shawn 來自于美國 Web 標準，之前有過設計或設計系統相關的工作經驗，他善于從設計角度去做一些開發上的決定。
今年（2018）我們招了第一個全職的工程師，Emily。她之前在 Buffer 做前端工程師，開發維護他們的組件庫。Emily 具有 React.js 和可訪問性的經驗，這對于我們當前的團隊或工作是很重要的。
△ 不同時間我們需要不同類型的人
無論我們招的是設計師還是工程師，我們都要求一些通用技能。我們要求開發者具有設計敏銳度，這樣能做出更好的決定來構建設計系統，使其可以更好地服務于設計。我們也會要求設計師具有基本的代碼讀寫能力，能夠從開發的角度思考，并根據開發的經驗進行設計。這很重要，因為設計系統融合了設計和開發，我們需要給設計和開發提供一致的設計語言。
作為團隊負責人和管理者，我也要提升自己的影響力。相比于一年前，我現在帶了更多的人，往后我還要管理更多人員，以及開始構建我們的設計運維事務。這意味著我不能作為一個普通的工作者，不問世事。今年早些時候，我發現我遇到了自己的瓶頸——我更像是一個設計系統的編輯者，而不是作者。
過去我給這個設計系統貢獻了很多視覺設計的工作，并且作為最主要的決定者。現在我正在學習如何將這些工作分攤一部分給其他成員，如果他們有不懂的，我會教他們。
我們最有趣的會議（是的，會議也可以很有趣）是每周組件評審。此時每位提交了新組件的成員會帶著我們過一遍他們的代碼，給我們展示如何使用，效果是怎樣的，并征求一些意見反饋。這保證我們創造出一個體驗一致的設計系統。
△ 當貓和會跳舞的同事加入時會議會變得更有趣
每年我們都會設定目標，下面這幾項雖然沒有覆蓋所有，但是一直是我們2018年所專注的。
Github.com 的前端技術棧分散而老舊，我們在構建 UI 時需要考慮的事情特別多。
與其分心于各種不同的編程語言（比如 HTML、CSS 和 JavaScript），我們不如專注于組件層面。為了達到這個目標，我們今年主要的任務就是構建一個基于 React.js 的組件庫。現在我們已經開始去做了，等這個組件庫達到第一個穩定版本我們就會開源它。有一些團隊已經開始使用 React.js 了，我們希望能夠盡快讓他們使用到我們的組件庫。我們的應用系統團隊已經幫我們做了一些事情，幫助我們更容易地將設計系統接入，我們需要緊密合作。
△ 我們的 primer-react 組件庫演示沙箱
我們想要看到更多團隊參與進設計系統的構建，不只是我們團隊。我們想要人們在使用 Primer 時感覺更簡單，也更容易學習。因此，我們花了很多時間去研究設計工具、實踐教程、開發工具，以及簡化參與流程。
今年我們將設計組件轉移到了 Figma，并使用 Figma 來進行可交互原型設計。Figma 是基于 Web 的，這意味著我們可以整合進設計系統工作流中的其它工具，而且不用局限于 macOS。Figma 的公共樣式特性可以幫助我們提取出注入顏色、排版等樣式，和我們在代碼中的實現方式類似。Figma 還提供對外接口，可以幫我們很容易地接入其它自動化流程，比如說根據我們代碼中的組件來檢查 Figma 中的組件是否符合規范。
△ Figma 中的 Primer 顏色樣式
今年晚些時候，我們將會去探索代碼原型工具。在設計流程確定的階段我們使用圖形化的設計工具是很好的，但有時候我們需要做更進一步的探索。在 Github 很多設計師都是直接擼產品級的代碼，但這樣也不好，因為每次都需要進行一些前期的基礎搭建。還有一些設計師會在 Codepen「6」中使用我們之前的一些模板。
△ Primer 在 Codepen 中的項目
我們知道這兩種方式其實都不是很完美。設計師需要經常做一些頁面原型或流程，他們需要能夠快速調整設計效果，就像在圖形化設計工具中一樣。這在產品級代碼中很難做到，而使用 Codepen 中的模板意味著他們在專注于業務之前需要寫很多代碼。理想的情況是設計師們需要能夠快速開始，使用真實或接近真實的產品數據來構建頁面。我們知道這對于很多公司都是一個挑戰，希望我們能夠找到一個解決辦法。
我們希望 Github 是人們在談論設計系統時首先想到的公司之一。許多公司開始構建自己的設計系統，這是一個不斷發展的領域。我們將會不斷分享這個過程中的一些想法，以期幫助到你們。
今年早些時候我們公開了新版的樣式指南——我在一次設計系統的活動中曾分享過，同時我也談論到人們關于自己公司的設計系統和其他公司設計系統相比較的問題。其實比較是沒有意義的，我們應該專注于去創造自己的度量標準，因為別人的并不一定適用于你。即使是我們的設計系統，也有很多 bug 和可提升的空間。所以我覺得我要分享我們的設計系統，包括缺點。
△ 我們的樣式規范文檔
我們一直在開放地工作，在我們的公開倉庫中不斷發布著新計劃。我們將繼續分享一些新項目，也許它可以直接被用到其他人的設計系統，或者能夠啟示人們如何去做。我們也會寫更多的文章，去做一些分享，或參與到社區活動中。
如果你有什么想要知道的可以在這里（Primer 倉庫）開 issue 來告訴我們。
△ Primer 的項目看板
GitHub 將持續投入到設計系統中，我們也將持續努力做到最好，分享我們成功或失敗的經驗。如果你也想參與到我們的設計系統中，為開發者創造更好用的產品，可以加入我們。
相關鏈接及注釋：
- pull request：成員往項目代碼中提交新特性或修復的請求
- issue：類似于項目協作中的任務，用于追蹤需求或 bug
- 倉庫：代碼倉庫，可以看做一個項目的所有代碼文件集合
- Lerna：管理版本的工具
- Travis CI：持續集成工具，自動化地觸發代碼測試、編譯或部署
- Codepen：前端工程師展示作品的地方
歡迎關注作者的微信公眾號：「codesigner」
復制本文鏈接 文章為作者獨立觀點不代表優設網立場，未經允許不得轉載。
發評論！每天贏獎品
點擊 登錄 后，在評論區留言，系統會隨機派送獎品
2012年成立至今，是國內備受歡迎的設計師平臺，提供獎品贊助 聯系我們
標志設計標準教程
已累計誕生 729 位幸運星
發表評論 為下方 1 條評論點贊，解鎖好運彩蛋
↓ 下方為您推薦了一些精彩有趣的文章熱評 ↓