更多設計系統相關文章：
設計系統這個話題近幾年越來越受到大家的關注，國內有阿里集團的 Ant Design、Fusion Design，以及字節系的 Semi、Arco、騰訊的 TDesign；國外也有大家比較熟悉的 IBM Carbon Design、Salesforce Lightning Design，以及前段時間給大家介紹的 AWS CloudScape。
對于這些不同的設計系統，大家時常會有一些不一樣的觀點。比如有的同學認為 A 做得好，B 太過于簡單，全是底層能力沒啥用。
如何理解它們之間的差異，是我們學習過程中非常重要的一環。我們不能簡單的從內容上去做比較，而是需要先從它們的定位出發。
從我個人的視角來看，我會傾向于將所有的設計系統分為是哪個不同等級系統級→領域級→業務級，大家可以用下面這張圖看清楚它們的邏輯。從系統級到業務級，是對設計標準的抽象到具象，同時我們對設計的指引也是從基礎認知轉為更加具體的約束。
1. 等級 1：系統級設計系統
系統級，顧名思義，就是操作系統級別的設計系統。當下的數字產品大部分是基于操作系統和瀏覽器所構建的，所以我們首先需要基于 OS 或瀏覽器級來開始工作。這里最常見的是 Google 的 Material Design、Apple 的 Human Interface Guideline 以及各種 Web 前端框架，比如 BootStrap。
配合硬件和軟件技術的發展，系統級的設計系統為我們提供豐富的交互形式以及設計指引。同時它們也對用戶的基礎認知和使用習慣做出了定義和引導，確保了一個產品在基礎交互層面的體驗基準線。
其實我們也可以將它“簡化”一下，將它們比作支付寶或微信的小程序就更容易理解了。支付寶和微信經過多年的運作累積了海量的用戶和流量，于是很多的企業（或開發者）希望能夠進駐到平臺，為用戶提供服務并獲取響應的收益。
為了給用戶帶來一致、優質的服務和使用體驗，支付寶和微信向企業（或開發者）提供一整套完整的設計指導原則和開發框架，也借此來幫助提升小程序的開發效率，降低產品的實現成本。而企業（或開發者）也會盡可能的去遵守它們的規則，以獲得更好的業務上的合作扶持。
2. 等級 2：領域級（行業級）設計系統
相較于系統級，領域級會更加聚焦于某一個領域或行業。比如 IBM 的 Carbon Design，阿里的 Fusion Design，螞蟻的 Ant Design 以及字節的 Semi Design、Arco Design、騰訊的 TDesign。
如果對以上這些名字有過一定的了解，你應該發現它們基本面向的都是企業級應用場景，或者是我們常說的 B 端場景。為什么會是這樣呢？其實還是在于 B 端產品相對來說更看重實用性和效率，比較適合對設計進行抽象。C 端的業務能做嗎？邏輯上當然是可以的，只不過在目前來看，大家并沒有能夠達成一致。
這里的共識并不是說它簡單、對設計的要求不高。而是在企業級的場景下，高效、一致、簡潔等關鍵詞是大家最為核心的設計原則，目的是讓用戶能夠更為有效、輕松的完成當下的任務。再加上如今蓬勃發展的 B 端業務，設計系統的價值在這里可以得到很好的驗證和體現。
領域級最重要的目的是能夠幫助在這個行業中的產品能夠快速完成 0 到 1 的產品建設。減少在前期工作中的浪費，讓大家能夠更加快速的進行對產品的迭代和市場的驗證上。
領域級的產品比較多了，我們這里可以簡單列舉一些：
3. 等級 3：業務級（產品級）設計系統：
我們前面說過，設計系統的等級從下至上是從抽象到具象的過程，而這個具象就是我們對業務中設計標準的明確指引。同時，業務級的設計系統往往也是我們設計師參與得最多的一類。它的定位很明確，就是基于行業和業務的特性來構建，一切都是為業務而服務。
業務級設計系統的目的是提供明確的約束和指引，能夠幫助業務快速的實現產品業務邏輯，避免不必要的浪費。
同時它也需要具備良好的業務抽象和擴展性，有非常好的運作機制，能夠提升整體業務生產鏈路的效率。在網絡上我們能看到的業務級設計系統其實并不太多，AWS 的 CloudScape 是一個還不錯的案例，大家有興趣可以讀一下下面這篇文章進一步了解。
4. 業務級設計系統案例 - AWS CloudScape Design System
CloudScape Design System 是今年的 7 月底，AWS 正式對外發布的設計系統 。這是一套開源解決方案，可用于大規模構建云服務業務的的復雜 Web 應用。
這套解決方案其實早在 2016 年就已經在開始內部啟動了，如果大家有用過 AWS 的產品，可能你已經默默的見過它了。
CloudScape 提供了多達 66 個組件，而且這里面大多數都是基于 toB 類業務特性制定的自定義組件。基于這些組件和云服務業務的特性，它還封裝了 5 大類 35 個 Pattern 以及 27 中場景的演示 Demo。
① CloudScape Design System 的核心特點
內容簡練務實，指導準確有效
相較于很多設計系統的站點，CloudScape 提供的內容非常簡練，沒有太多設計理念、價值觀的講解，更多還是落在實際應用指導。它更像是一本面向實操的指導手冊，每一個 Component 和 Pattern 都提供了清晰準確的定義、場景以及使用說明。而且大部分都提供了在線配置調試功能，幫助使用者更好的理解和使用。
定位明確，領域性強
從 2016 年啟動到現在已經有了 6 年時間， 經過了 AWS 這么多年業務中的打磨后 CloudScape 給我的一個感覺就是清晰和明確。特別是在 Pattern 的部分，35 個雖然不算多，但基本都是這個領域的內的一些標準場景的抽象。基本上云產品業務需要的場景它提供了指引，相信做過相關產品的同學會有更強的體感。
強約束性 & 可控自由度
在之前的文章里有很大家提到過，設計系統就是要對場景進行抽象、封裝并逐步進行合理有效的約束，達成體驗上的和諧和統一。CloudScape 堅定的給出了很多強約束來保障產品的基礎體驗一致性和有效性，同時它也在可行的范圍內提供了一些自定義空間，來確保產品設計過程中的差異性。
② CloudScape Design System 中的設計模式
CloudScape Design System 的另一個亮點在于它對設計模式的抽象，能夠很好的覆蓋在此類業務場景中的一些共性場景，為同類型的設計需求提供了一個很好的標準解決方案。
CloudScape 提供以上 5 大類共 35 組 Pattern。相較于之前和大家提供的 Carbon Design System 這里對 Pattern 的定義會更加的具象，也更貼合業務。大家一看就很清楚它能幫助我解決哪個業務需求。
這里也一樣，挑選一個比較有代表性的和大家展開聊聊。
③ Announcing new features · 新功能發布
「新功能發布」可以說是 toB 產品中的老大難問題了。不是它本身有多復雜，而是絕大多數產品上都很亂。規則制定不清晰，設計師會錯用，有了規則執行也難以到位，時間一長就會出現通知、浮窗、提示滿天飛的情況。
當然，這本身是一個和產品、設計、運營多方以及“利益”都有關的問題，我們今天還是先回到設計本身，看看 CloudScape 是如何定義標準的。
首先對于「新功能發布」它給出了三條核心體驗原則：
- 用戶的核心工作是完成任務，所以盡可能保持溝通內容的簡潔，減少用戶認知的負擔
- 給予用戶控制權，減少對用戶工作的打擾
- 控制好對 Flashbar 這類組件的使用，降低對用的視覺干擾
服務級的功能發布 – 圖中 ①
如果新發布功能會影響到該服務中的所有頁面，可以使用系統中視覺最強的組件 FlashBar 來進行提示引導。
頁面級功能發布 – 圖中 ②
頁面級功能發布是針對新增頁面或服務中有新功能增加所提供的通知方式，在側邊欄中使用彈出氣泡提供提示引導。
頁面內功能發布 – 圖中 ③
頁面內功能發布是針對某個具體功能頁中新模塊增加所提供的通知方式，在頁面模塊中使用類似 Flashbar（視覺強度較低）的通知模塊提示引導。
CloudScape 對新功能發布的定義其實也并不復雜，但通過分類之后也已經非常清晰了。使用者需要的是在使用前先確定它是屬于哪一個層級的新增功能，在選擇與之對應的類型即可。
雖然從嚴格意義上來說它應該是業務級設計系統，主要是為 AWS 的業務所服務。但在我看來，拋開業務屬性本身，它還對 B 端設計的很多通用場景做了大量的深入和研究，非常值得我們學習和借鑒。
5. 業務級設計系統案例 - 阿里巴巴 Fusion Design 和 螞蟻 Ant Design
① 阿里巴巴的設計系統 Fusion Design 和 Ant Design
在阿里我們有兩套主流的設計系統，分別是我們設計中臺的 Fusion Design 和螞蟻的 Ant Design。Ant Design 對外的知名度較高，為很多企業的 0 到 1 產品建設提供了基礎。而我們團隊的 Fusion Design 在后面幾年逐步轉向對內，以服務好內部業務為核心。
它們兩都是差不多在 2016 年左右啟動的，發展至今它倆支撐了三大集團（阿里、菜鳥、螞蟻）的全部數百條業務線。對于我們來說，最為核心的就是做好底層能力的建設，讓其他業務能夠在此之上生長出自己的產品級業務系統。
事實也證明，這個模式是正確的。在接下來的幾年里，結合在線搭建的能力，設計系統已經逐步從一套方法理論演進成為一個能夠參與業務生產的工具。在一些我們重點合作的業務里，已經可以達成幫助設計師提效 50%，研發提效 30%的成果。
在有了上面對不同設計系統的分級后，大家可能會有一個問題，那就是在著手開始工作時我們應該從何處入手呢？這里我可以給大家推薦兩種思路。
- 一種是基于領域級來構建，適合偏 Web 端的產品，有很好的 0 到 1 基礎。重點關注行業領域的特性，去抽象業務組件、業務 pattern
- 另一種是基于系統級去構建，適合偏移動端的場景，直接業務級往上去做
這里在領域級，我推薦大家可以去使用阿里、字節、騰訊這幾家的產品，因為迭代速度和維護有更好的保障。
這里我們再簡單回顧一下這三類設計系統
- 系統級：操作系統級別，提供最底層操作系統級的設計及研發指引；
- 領域級：聚焦于某一類通用場景的設計及研發指引，當前最為成熟的還是在企業級應用（B 端）場景；
- 業務級：基于系統級或領域級的二次加工定義，為具體的產品或業務提供設計及研發指引。
1. 對于設計系統的思考變化
這里我們聊的思考變化不僅僅是指在設計師角度，更多的是公司的角度來看待設計系統以及它所提供的價值。
以前我們聊設計系統，很多都是設計師和前端從認知、從興趣的角度出發來嘗試更為先進的業務生產模式。而很多公司的管理者對它的理解是設計的一致性、設計體驗的提升，而對于降本提效至少在工程上我們也并沒有特別明顯的價值產出。
從企業經營的視角看待設計系統
這兩年隨著互聯網紅利的逐步消失、疫情的影響，成本、收益都都面臨的巨大的考驗，連各大互聯網公司也不再放任大家去不斷的“試錯”。阿里在一年多前也逐步的開始對每個團隊實行經營責任制，讓大家必須認真思考每一次的資源投入。
雖然大家諸多抱怨，但宏觀上來說我認可這是一件正確的事情。它也倒逼著團隊管理者們通過更科學、高效的工作模式來運作團隊，杜絕浪費。同時也就在這個時刻，因為業務的特性，一些企業級產品從相關方到管理者都開始重新審視它所能帶來的價值，有些想清楚的也早早的開始并已經獲得了相當明顯的收益。
這里面的邏輯其實也并不復雜，給大家舉個例子：某事業部 CTO 線的核心交付就是各類中臺系統，宏觀角度可以拿頁面數進行計算。
單頁面成本 = 平均工時工資 x 單頁面交付時長
這里提供了兩個影響成本的變量，要么降低工時工資，要么降低單頁面交付時長，但對于企業來說非常時期往往兩手都得抓。平均工時工資不在我們的把控范圍內，但單頁面交付時長對于設計師和研發來說就有很多事情可做了。設計系統的投入和產出價值可以很清晰的算筆賬，只要方案制定得合理，大概率這個 ROI 是滿足預期的。
從業務的視角看待設計系統
還是說回前面那次調研，你會發現產品經理的出現了，設計系統不再只是一個設計和研發的工作，產品經理也需要參與其中一起制定規則。
受訪者中有 16% 表示團隊中的參與者為設計師、前端工程師、產品經理。
產品經理為什么要參與？因為在設計系統的角度，設計師和前端工程師定義的是解決某一類問題的界面交互模式。而產品經理的日常工作是創建實例，解決某個具體業務流程問題。
想象一下產品經理在寫 PRD 的時候如果是這樣的場景：
這是一個新品報名系統
模塊 1：注冊登錄
模塊 2：報名表單
- 子模塊 1：用戶身份認證
- 子模塊 2：商家資質認證
- 子模塊 3：…
模塊 3：報名管理
模塊 4：商品管理
這背后每一個模塊、子模塊，除了交互模式上的定義，還需要從產品上進行業務邏輯的定義。好的業務級設計系統應該讓產品經理將重心放在業務流程本身，而不必去關心某一個具體按鈕、彈框。而作制定者也不用再整天糾纏在業務細節中，將工作的重心放在對業務 Pattern 的抽象、制定中。
當然，這類模式并不是一件容易的事情。它首先需要設計師、前端工程師、產品經理達成共識：
- 我們需要的不僅僅是規范，還需要更多的確定性的“約束”，將達成的共識封裝成模塊供使用；
- 非必要情況下，我們要做無畏的“設計創新”，一切以切實解決問題為優先；
- 如果需要對制定好的規則進行改變，不要修改實例。去給已封裝的模塊提需求。
以上的這些思考不能僅停留在設計師群體里。在企業里工作，講清楚一件事情的價值很重要，我們不僅需要自己先想清楚，還需要我們的合作伙伴、管理者也能理解，這樣才能給我們推行設計系統給予更多的理解和支持。
1. 設計系統對公司的價值
當我們投入資源做一件事情，需要關注到它所帶來的價值。特別是在如今的大環境下，大家都更加的精打細算，講不清價值的事情在任何公司都難以推動。
對于公司而言，設計系統就是產品的基礎，也是業務能夠快速迭代的發動機。通過其能力的不斷迭代，我們可以進一步封裝、約束我們的設計標準。以此來不斷優化業務的生產流程，達到企業能夠降本提效的目的。
對公司而言，我們節省的不僅僅是成本，更重要是時間。而在當前激烈的競爭環境下，市場的先機往往比金錢更加重要。
2. 設計系統對設計團隊的價值
一直以來，設計師在整個企業中的話語權是不高的。特別是在國內，設計師更多時候是一個不太重要的”資源“。有時候大家都會打趣到，這個項目可以沒有設計投入，但研發不能沒有啊。雖然這只是個玩笑，但它背后的本質還是在于設計師這個角色缺少不可替代性。這也是為什么在國內很少有設計角色進入企業最為核心管理層的原因。
而在我看來，這也是設計團隊發展至今最為核心的能力和資產，是設計團隊提升影響力，成為業務核心能力的重要基礎。
3. 設計系統對設計師的價值
在日常的項目設計工作中。設計師的能力都是通過一個個具體的項目來體現，大部分時候它很難沉淀為一種核心能力展現在其他人面前。
設計系統的發展，讓設計師有機會能夠向”架構師“的方向進行發展。將自己在設計和行業方面的經驗進行體系化的沉淀并轉化成產品能力來進一步放大自己的價值。同時，它也將可能推動設計師的崗位向下一個階段發展，衍生出新的角色：產品型設計師和架構型設計師。
當然，除了對我們的價值層面，我們還需要從更多的方面向公司去介紹它的價值。如果大家不太清楚應該如何去組織、表達，可以閱讀下面這篇文章進一步了解。
延展閱讀 ?? 如何向你的主管和團隊介紹 Design System 的重要性
復制本文鏈接 文章為作者獨立觀點不代表優設網立場，未經允許不得轉載。
繼續閱讀本文相關話題
熱評 小李學藝