想創(chuàng)建產品設計體系？來文中看看Atlassian設計體系元老的6點經驗分享。

The key lessons I learned creating a popular Design System

2012年，我啟動了一個副項目：對 Atlassian 當時12款軟件產品的設計模式進行標準化定義工作。在那之后的三年里，這個副項目逐漸成長壯大，并成為了我的全職工作；經過一系列的版本迭代，這個項目最終成為了大家所熟知的 Atlassian Design System。

期間，我還成立了設計平臺團隊（Design Platform Team），專門負責對設計體系進行管理維護，并將其運用于 Atlassian 產品套件的設計工作當中。

近些年來，行業(yè)里出現(xiàn)了越來越多關于設計體系的討論，我也時常被問及相關的經驗與洞見（注）。無論你在考慮為自己的產品創(chuàng)建設計體系，還是正在進行當中，或是曾經嘗試但以失敗告終，我都希望這些經驗可以幫助到你。

譯者注：包括接受《設計體系》一書作者的訪談，相關內容也體現(xiàn)在書中。

如今在 Asana，我又開始了新的設計體系構建之旅；回顧過往的經驗，我發(fā)現(xiàn)它們同樣有助于我們將團隊與公司推向成功，從而體現(xiàn)出設計體系真正的價值所在。

1、以小為始

第一個版本的 Atlassian 設計體系只包含20個靜態(tài) HTML 文件，由我桌下的那臺 Mac Pro 充當服務器。沒有模板，沒有版本控制，我親自動手為每一個組件編寫 HTML，并將線上產品的 CSS 直接導入過來作為樣式表。

雖然這一版本更新起來非常困難，而且不具備擴展性，但它也足夠向當時的團隊展示設計體系的基本價值了；我因而得到支持，并得以將更多時間與精力投入其中，逐漸摸索到了正確的道路。

反之，如果從一開始就考慮到各種擴展性問題，那么我們很可能需要花費數(shù)倍的時間來完成起步階段的跨越。如果你剛剛開始構建設計體系，建議你不要沉迷于無縫、完美的流程和機制，取而代之的是簡單快速地起步，驗證價值與方法，并保持迭代。

2、重在質效提升，而非控制設計

如果你認為構建設計體系的目的在于防止其他人“犯錯”，防止他們破壞掉只有你“有權”定義的規(guī)則，那么你們的體系構建工作很可能是在不正確的觀念之下進行的。

設計體系的目標是提升團隊的設計質效，幫助每一名設計師更加合理地進行設計決策。

你的工作并非將規(guī)則強加給他人并監(jiān)督他們執(zhí)行。反之，要將設計體系視為在公司內部實現(xiàn)“設計民主化”的工具。只有這樣，人們才會有意愿參與其中并進行貢獻。

務必記得，設計體系是一種強化工具，而非用于控制設計的監(jiān)管手段。

3、避免同步進行重設計工作

不要將設計體系的構建工作看作是產品重設計的契機。一邊進行著體系化定義，一邊對產品進行重設計，這會極大地拖慢工作進度。更合理的做法，是首先對產品當前的狀況進行記錄與清查，包括合理與不合理的模式在內；完成標準化定義之后，再回過頭來進行優(yōu)化工作。

在 Atlassian，我們曾經多次試圖在設計模式文檔的基礎工作完成之前對產品進行重設計。誠然，設計模式的定義與文檔化工作需要花費大量的時間，但以此為基礎進行新一輪的設計迭代，整體進程會更加輕松和高效。

4、跨職能尋求支持

設計體系的創(chuàng)建工作并非學校里的課業(yè)練習，如果最終無人使用，或是無法有效提升設計質效，那么我們的工作就是浪費時間。

只有讓其他人了解你的工作并參與貢獻，你才能得到越來越多的認同與支持。這一點對于設計體系工作非常重要。

2013年時，我們團隊當中的設計師與工程師占比大約在1:15到1:20之間。直至如今，回想起這個數(shù)字，我仍然會感到驚悚。不過當時，我確實有試過將這種失衡的局面轉化為工作中的優(yōu)勢，使工程師們更加認同設計體系相關工作。

我會在新人入職當周做一些宣講，每周有15人左右的樣子；為了讓他們從第一天起就能對設計體系的目標與價值有所了解，我會給他們講一些往事，譬如：我們的產品當中曾一度存在著44種下拉菜單，而如今已經標準化為一種，它的具體使用方式應該如何如何。

經過那一年的宣講，加上 Atlassian 的規(guī)模幾乎每年都會翻番，我總共幫助了將近500名新人了解了設計體系的重要性及使用方式。同時，這項工作還在潛移默化當中擴大了設計職能在整個企業(yè)文化當中的影響力。

5、超越“設計規(guī)范”

設計體系不同于設計規(guī)范，創(chuàng)建一份包含了所有組件的 Sketch 文件或許相對容易一些，譬如：所有的主操作按鈕都有著相同的配色，或是統(tǒng)一使用8像素柵格等等。但應該在何時使用主操作按鈕而非次級按鈕？按鈕中的文本應該采用哪種類型？主、次按鈕同時出現(xiàn)時應該怎樣布局？

設計體系必須針對這類規(guī)則性的問題提供解決方案，而不僅是記錄規(guī)格規(guī)范。很多團隊都忽視了這一點，致使設計體系的價值有所缺失。

正如前面提到過的，在2013年初，Atlassian 設計團隊的規(guī)模（約13人）相比于開發(fā)團隊（約300人）來說還相對較小。明確提供設計模式使用規(guī)范的好處在于，工程師可以在設計師人力不足時獨立完成大量的頁面構建工作。

這意味著在很多時候，設計師無需打開 Sketch 制作高保真設計方案，大家可以通過白板和腦暴直接確定功能流程，或是將更多時間用于上游高層面問題的處理。

6、少數(shù)人負責管理，多數(shù)人參與貢獻

我們在 Atlassian 采用了集中式的設計體系管理機制，一方面允許每一名設計師參與貢獻，一方面通過每三個月的輪崗制度從不同的產品團隊當中抽調設計師與工程師加入我們的平臺設計團隊。

在三個月的時間里，他們會對設計體系的維護工作進行大量的貢獻。三個月后，他們回到各自的團隊當中，成為設計體系的簇擁者與布道者。

有專人負責設計體系相關工作是非常重要的。這個人（通常指我）更像是設計師當中的產品經理，他需要維護整套體系，同時又要避免營造出讓人抵觸的工作氛圍。始終不要忘記，我們的目標是提升設計質效，讓每個人都成為更出色的設計師，并最終實現(xiàn)團隊效能與產品質量的提升。

原文作者：Matt Bond

原文鏈接：https://medium.com/asana-design/the-key-lessons-i-learned-creating-a-popular-design-system-d078c817b4dd?ref=webdesignernews.com%3Fref%3Duxdesignweekly

譯者：C7210，公眾號：Beforweb（ID：beforweb）

來源：公眾號：Beforweb（ID：beforweb）

本文由 @Beforweb 授權發(fā)布于人人都是產品經理，未經作者許可，禁止轉載

題圖作者提供