設計系統是關於關係的

設計系統非常有用。 它們提供了可重用的元素和指南，用於在產品之間構建一致的“外觀和感覺”。 因此，用戶可以將他們從一種產品中學到的知識應用到另一種產品中。 同樣，團隊可以推出經過良好測試的導航或評論模式，使產品更值得信賴。 有效的設計系統以可重複的方式解決無聊的問題，以便開發人員和設計人員可以專注於解決新問題。

然而，當有人在會議中使用“設計系統”一詞時，我永遠無法確定會發生什麼反應。 我看到了對嘗試一種新的工作方式的好奇和興奮，但我也看到了對限制設計師創造力的系統的想法感到沮喪和擔憂。 一些設計師認為設計系統會削弱創造力，或者它們是尋找問題的解決方案。 設計系統會隨著時間的推移而碎片化，導致團隊停止使用它們。

不過，設計系統並沒有消失。 一項調查顯示，2018 年只有 15% 的組織缺乏設計系統。 這比前一年的 28% 有所下降。 一些團隊使用大型通用設計系統，例如 Google 的 Material Design，而其他團隊使用更小、更定制的系統，例如 REI 的 Cedar 和 Mozilla 的協議。

設計系統應該賦予團隊權力，而不是限制他們。 為此，我們需要開始更全面地思考。 設計系統不僅僅是代碼、設計或文檔。 就是所有這些東西，加上系統的製造者和使用它的人之間的關係。 它不僅包括 CSS 文件和 Sketch 文檔，還包括信任、溝通和共享所有權。 事實證明，有一整個研究領域致力於探索這樣的系統。

大局

1960 年的一篇題為“社會技術系統”的論文探討了技術、人類以及它們所在的更大環境之間的相互作用。 Enid Mumford 解釋說，研究人員開始研究如何在經理和員工之間建立更好的關係，但到 1980 年代，他們專注於提高工作效率和成本效益。 2011 年，Gordon Baxter 和 Ian Sommerville 寫道，這項研究有助於激發以用戶為中心的設計，而且還有很多工作要做。

Baxter 和 Sommerville 認為，今天，關注員工生活質量的“人文”研究與關注員工生產力的“管理”研究之間仍然存在緊張關係。 他們還解釋說，同時考慮技術和人機交互很重要：“系統性能依賴於技術和社會子系統的聯合優化。”

我認為設計系統是社會技術系統。 它們涉及創建系統的人員、使用系統創建產品的人員以及與這些產品交互的最終用戶之間的交互。 它們還喚起了巴克斯特和薩默維爾所看到的效率和人文主義之間的同樣張力。

設計系統不僅僅由圖像和代碼組成； 它們涉及設計師、開發人員、產品經理、首席執行官和 GitHub 上隨機人員之間的對話。 這些交互發生在各種環境中——公司、開源社區、家庭——它們跨越文化和組織邊界。 組建團隊可能意味著將動畫、聲音設計、數據可視化、觸覺和文案等學科的人員聚集在一起。 創建一個成功的設計系統需要同等的技術專長和軟技能。

然而，仔細閱讀設計或工程新聞聚合器，您可能會看到對“技術子系統”的明顯關注——代碼和工具，而不是人員和對話。 哪種創意工具最適合跟踪設計令牌？ 應該使用哪些 JavaScript 技術來構建可重用組件——React、Web 組件或其他？ 哪個構建工具最好？

當然，這些問題的答案是“視情況而定！” 誰將設計、構建和使用該系統？ 他們的需求是什麼？ 他們在哪些限制條件下運作？ 他們對哪些工具和技術感到滿意？ 他們想學什麼？

為了回答這些問題，Baxter 和 Sommerville 推薦了兩種類型的活動：

• 宣傳和認識活動
  了解將創建和參與系統的各種人，並廣泛地分享這些信息。
• 建設性的參與
  跨角色溝通，構建原型，並考慮系統的技術和社會部分。

吃吧

在 2019 年初，我是一個團隊的一員——我們稱他們為“藍隊”——正在為一個大型組織構建設計系統。 我促進了與這個團隊和“綠色團隊”的非正式聊天，他們正在使用設計系統來構建一個 Web 應用程序。 每隔幾週，我們就會讓所有開發人員和設計師圍坐在一張桌子旁，討論我們正在構建什麼以及我們試圖解決什麼問題。 這些聊天是我們的“宣傳和意識活動”。

我們無權公開我們的設計系統，所以我們做了次好的事情：我們把它當作組織內的一個小型開源項目。 我們將代碼放在兩個團隊都可以訪問並請求貢獻的存儲庫中。 藍隊負責審查和批准這些貢獻，但任何一個團隊中的任何人都可以貢獻。 Team blue 也在構建他們自己的應用程序，因此從某種意義上說，他們既是設計系統的用戶，又是設計系統的保管人。

這些互動幫助團隊構建了更好的產品，但同樣重要的是，它們在團隊之間建立了信任。 藍隊了解到，人們正在深思熟慮地使用該系統，並在此基礎上構建聰明的新想法。 格林團隊了解到該系統確實是根據他們的需求量身定制的，因此他們可以使用它而不是反對它。 Baxter 和 Sommerville 可能將這項工作稱為“建設性參與”。

我們發現，兩個團隊都面臨著學習新技術和快速交付完整產品的壓力。 換句話說，他們已經在相當大的認知負荷下運作。 因此，兩個團隊同意專注於使系統易於使用。 這意味著迴避整個 Web 組件的爭論，主要關注 CSS，並確保我們的文檔清晰友好。

把它們放在一起

各種規模的組織都創建了可重用的設計元素，以幫助團隊構建更一致、更優雅的應用程序。 不同組織的需求和動態在他們的設計系統中表達出來。 這裡只是幾個例子：

• Google 的 Material Design 有多種不同框架和語言的實現。 它被 Google 內部和外部的各種人使用，因此它具有全面的文檔和各種用於設計應用程序的工具包。
• Microsoft 的 Fluent Design System 針對四種截然不同的平台。 與 Material 一樣，它包括用於 UX 設計師的工具包和綜合文檔。
• Mozilla 的協議是在 Sass 和 vanilla JavaScript 中實現的。 它非常注重國際化。 亞歷克斯吉布森說，這個系統幫助 Mozilla “以更快的速度創建品牌網頁，減少重複的手動工作。”
• REI 的 Cedar 是用 Vue.js 組件構建的，不能與其他 JavaScript 框架一起使用。 Cedar 主要由 REI 的內部開發人員使用，並且與公司的品牌密切相關。 設計系統的代碼是開源的，但它的字體不是。
• Salesforce 的 Lightning 設計系統是一個與 JavaScript 無關的 CSS 框架。 它可以選擇與 Lightning 組件框架一起使用，其中包括兩個 JavaScript 實現：一個使用 Web 組件，另一個使用 Salesforce 的專有 Aura 框架。
• Red Hat 的 PatternFly 旨在為公司的雲平台產品提供一致的用戶體驗，因此它具有相對較高的信息密度並包含各種數據可視化組件。 在對 Web 組件進行了一些實驗之後，PatternFly 團隊最近從 Angular 切換到了 React。 PatternFly 還包括一個使用 HTML 和 CSS 的與 JavaScript 無關的實現。 （全面披露：我是前紅帽員工。）
• IBM 的 Carbon Design System 提供 React、Vue、Angular 和 vanilla JavaScript 的實現以及用於 Sketch 的設計工具包。 Carbon 團隊正在試驗 Web 組件。 （向 Jonathan Speek 致敬以追踪該存儲庫。）

像這樣的系統是一致且可靠的，因為來自不同團隊和角色的人一起工作來構建它們。 這些系統解決了實際問題。 它們不是開發人員試圖將自己的意願強加給設計師的結果，反之亦然。

Josh Mateo 和 Brendon Manwaring 解釋說，Spotify 的設計師“將他們的角色視為共享系統的核心貢獻者和共同作者——他們擁有一個共享系統。” Mina Markham 將自己描述為 Pantsuit 設計系統中的“工程與設計之間的翻譯者”。 Jina Anne 深入研究了設計系統背後的團隊動態和用戶研究：“劇透警報！ 你需要的不僅僅是設計師。”

讓我們建立一些東西！

現在我們已經完成了研究和一些示例，讓我們來談談如何構建一個新的設計系統。 從與人交談開始。 弄清楚誰將使用並為您的設計系統做出貢獻。 這些人可能跨越多個學科——設計、開發、產品管理、業務等等。 了解人們的需求和目標，並請他們分享他們正在做的事情。 考慮安排一次非正式會議，提供小吃、咖啡或茶，營造溫馨的氛圍。 與這些人建立定期溝通。 這可能意味著加入共享聊天室或安排定期會議。 保持語氣隨意和友好，並專注於傾聽。

當你談論你正在做的事情時，尋找常見的問題和目標。 您可能會發現團隊需要顯示大量數據，因此他們正在研究用於顯示表格和生成報告的工具。 優先解決這些問題。

還要尋找類似主題的重複模式和變化。 您可能會發現不同團隊的按鈕和登錄表單看起來有些不同。 這些變化有什麼意義？ 哪些變化是有意的——例如，主按鈕與輔助按鈕——以及意外發生了哪些變化？ 你的設計系統可以命名和編目有意的模式和變化，它可以消除“意外”變化。

這裡的目標是與使用設計系統的人建立一個快速的反饋循環。 更快的反饋和更小的迭代有助於避免在錯誤的方向上走得太遠而不得不大幅改變路線。 PJ Onori 將這些突然的、巨大的變化稱為“衝擊”。 他說，一些挫折是好的——這表明你正在學習和應對變化——但太多可能會造成破壞。 “你不應該害怕顛簸，”他說，“但你需要知道它什麼時候有用，以及如何幫助減輕它的缺點。 減輕痛風不利影響的最佳 [方法] 之一就是從小處著手——從小事著手。”

考慮通過設置一些基本元素從小處著手：

• 用於存儲代碼的版本控制系統。 GitHub、GitLab 和 Bitbucket 都是不錯的選擇。 確保使用該系統的每個人都可以訪問代碼並提出更改。 如果可能，請考慮將代碼開源以覆蓋盡可能廣泛的受眾。
• 實現系統的 CSS 代碼。 使用 Sass 變量或 CSS 自定義屬性來存儲“設計標記”——常見的值，例如寬度和顏色。
• 一個 package.json 文件，它定義了應用程序如何構建和安裝設計系統。
• 演示如何使用設計系統的 HTML 文檔，最好使用系統自己的 CSS。

CSS 框架 Bulma 的 node-sass 文檔更詳細地描述了這些步驟。 如果您想從頭開始，您可以跳過安裝和導入 Bulma，或者如果您想從一些基礎知識開始，您可以包含它。

你可能已經註意到我在這裡沒有提到任何關於 JavaScript 的內容。 您可能希望最終添加此元素，但您不需要它來開始。 研究最好和最新的 JavaScript 工具很容易陷入困境，而迷失在這項研究中會使入門變得更加困難。 例如，“Web Components 非常適合設計系統的 5 個原因”和“我為什麼不使用 Web Components”都提出了有效的觀點，但只有您可以決定哪些工具適合您的系統。 從 CSS 和 HTML 開始，您可以收集真實世界的反饋，這些反饋將幫助您在時機成熟時做出決定。

當您發布系統的新版本時，請更新系統的版本號以表明發生了哪些變化。 使用語義版本控制以“1.4.0”之類的數字來指示發生了什麼變化。 增加最後一個數字表示錯誤修復，增加中間數字表示新功能，增加第一個數字表示大的、破壞性的變化。 與使用設計系統的人保持溝通，邀請反饋和貢獻，並隨時進行小改進。 這種協作、迭代的工作方式有助於最大限度地減少“顛簸”並建立共享所有權感。

最後，考慮將您的設計系統作為一個包發佈到 npm 上，以便開發人員可以通過運行命令npm install your-design-system來使用它。 默認情況下，npm 包是公共的，但您也可以發布私有包，將包發佈到私有註冊表，或者要求開發人員直接從版本控制系統安裝包。 使用包存儲庫將更容易發現和安裝更新，但直接從版本控制安裝可能是幫助團隊入門的簡單短期解決方案。

如果您有興趣了解更多有關事物的工程方面的信息，Katie Sylor-Miller 的“構建您的設計系統”提供了一個很棒的深入了解。 （全面披露：我曾與凱蒂合作過。）

包起來

設計系統由代碼、設計和文檔以及關係、溝通和相互信任組成。 換句話說，它們是社會技術系統。 要構建設計系統，不要從編寫代碼和選擇工具開始； 首先與將使用該系統的人交談。 了解他們的需求和限制，並幫助他們解決問題。 在做出技術、設計或戰略決策時，請考慮這些人的需求，而不是理論上“最佳”的做事方式。 從小處著手，進行迭代並隨時進行交流。 使您的系統盡可能簡單以盡量減少顛簸，並邀請反饋和貢獻以建立共享所有權感。

通過同等重視工程和人際因素，我們可以在避免陷阱的同時獲得設計系統的好處。 我們可以以高效和人道的方式工作； 我們不必二選一。 我們可以授權團隊而不是限制他們。 授權的團隊最終會幫助我們更好地為用戶服務——畢竟，這就是我們首先來到這裡的原因。

關於 SmashingMag 的進一步閱讀：

• 管理設計系統的技巧
• 在您的設計系統中包含動畫
• 超越工具：構建設計系統如何改善您的工作方式
• 為美國政府構建大型設計系統（案例研究）