Atlassian 設計體系元老的經驗分享
斑斑無聊地在四周溜達了一圈，嚼碎幾顆貓糧，聲音在夜裡越發清脆；繼而跳上床，把手彎起來埋在胸前，內心毫無波瀾地臥了下來，雙眼漸漸眯成了縫。
是蠻久沒做過譯文了哦。今天這篇做得還有點兒小興奮。原文作者 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 採用了集中式的設計體系管理機制，一方面允許每一名設計師參與貢獻，一方面通過每三個月的輪崗制度從不同的產品團隊當中抽調設計師與工程師加入我們的平臺設計團隊。在三個月的時間裡，他們會對設計體系的維護工作進行大量的貢獻；三個月後，他們回到各自的團隊當中，成為設計體系的簇擁者與佈道者。
有專人負責設計體系相關工作是非常重要的。這個人（通常指我）更像是設計師當中的產品經理，他需要維護整套體系，同時又要避免營造出讓人牴觸的工作氛圍。始終不要忘記，我們的目標是提升設計質效，讓每個人都成為更出色的設計師，並最終實現團隊效能與產品質量的提升。
英文原文：https://medium.com/asana-design/the-key-lessons-i-learned-creating-a-popular-design-system-d078c817b4dd?ref=webdesignernews.com%3Fref%3Duxdesignweekly，作者：Matt Bond，譯者：C7210
C自制的 WireframeKit for Sketch 線框稿風格元件庫已升級至V1.1，瞭解下：
