譯文：設計體系與設計規範的區別

10-06

譯文：設計體系與設計規範的區別

來自專欄玲瓏設計

一、寫在前面的話

總有同學會把設計規範和設計體系搞混，甚至有的同學直接以為設計體系就是設計規範，實際上並不是如此，兩者的確有相似的地方，但並不是一個東西，一個是從表現層次體現，一個是對整體的設計布局進行的規劃。下面讓我們進入正文吧。

本文閱讀時長約為8分鐘，消化時長約莫一周。

英文原文：https://heydesigner.com/blog/minimum-viable-design-system/，作者：Marcin Treder

1.殭屍一般的設計規範

2.「設計體系」是一種動態的流程

3.通過合理的流程抑制複雜度的攀升

4.永無止境的MVP

5.以小為始，快步迭代

曾幾何時，某個設計團隊或前端開發團隊中的某個不幸的員工被推選出來，負責將那些經過團隊驗證的設計方式記錄成文檔，包括配色、字體、UI模式與代碼段，等等。

聽起來很像設計體系？確實，但並不是。

傳統的設計規範制訂工作旨在輸出一套完整的「成品」。然而每一次，這個「成品」在真正完成之前就已經過時了，最終便成為殭屍一般半死不活的存在。

原因何在？很簡單，互聯網產品的迭代速度太快了，變化是一種常態。設計師們試圖將每一條規則編入文檔，而同時，規則本身卻在不斷改變和進化。這件事本身就像西西弗斯神話一樣。

這項工作所帶來的挑戰致使業界開始重新思考如何通過更合理的方式去維護設計與代碼的一致性，於是「設計體系」的概念出現在我們面前。

與強調成品產出的設計規範有所不同，設計體系更具動態性，也就是更在於流程本身。

相比於指派某個設計師去創建一份靜態文檔，「設計體系」需要我們規劃一套更加合理的工作流程，以產品體驗的不斷優化為目標，隨時對設計工作當中產生的關鍵信息進行整理與維護。

設計體系團隊需要關注的不是「成品」的交付日期，而是如何持之以恆地、漸進式地改善產品設計一致性等方面的問題，以及如何提升產品迭代的效率，使之能夠越發快速地在市場當中進化和成長。

與任何封閉化的體系一樣，數字化產品的熵值也會持續提升，除非我們進行有意識的控制。產品的每一個新功能，團隊的每一名新成員，組織架構中每一個新的管理層...所有這些因素，最終都會導致產品複雜度的提升，即熵值的增大。

唯有持續的規劃與管理才能抑制不斷攀升的熵值。對於設計體系團隊而言，關鍵問題不在於一份規範化的靜態輸出，而在於持續合理化的工作流程，在於如何協調所有的設計、開發、產品及其他相關團隊，以產品體驗的持續提升為目標而協同作業。

「構建設計體系需要花費多少時間」，這類問題包含一種隱含的假設，即「設計體系有一個『完成』的時間點」。經過前文的分析，我們知道了這一假設並不成立。「設計體系」是一種動態流程，它應該隨時致力於設計工作的規範與優化，而其本身的構建過程則永無止境。

從這個角度講，設計體系就像某種持續性的MVP。一旦規範化的流程被建立起來並投入使用，設計體系就達到了「最小化可用」狀態。接下來，隨著產品的迭代，設計體系也會持續更新，但永遠無法達到「終極」狀態。隨著業務需求的變化及產品複雜度的提升，設計體系也將永無止境的進化。

設計體系的存在，起始於團隊意識到設計一致性的問題已經嚴重到需要通過新的工作流程加以解決的時刻。

隨著第一條設計約定的初步達成與實際運用，產品設計的複雜度就已經開始得到抑制。與傳統的、大而「完整」的設計規範不同，動態的設計體系從誕生的一刻起就可以立刻形成價值。即便起初只對5種主要配色的命名進行約定並投入實用，至少在這一點上，設計工作流程也得到了改善。

我個人甚至願意相信，即便一個設計體系只包含一種配色的定義，只要能在團隊內部達成共識、投入運用並保持迭代，也會比一套所謂的設計規範更有實用性和時效性。一個即刻有效的配色定義可以立刻降低設計熵值，而一套靜態的設計規範從來都是過時的、無法得到執行的。

所以，各位大可不必擔心「構建設計體系需要花費多少時間」這樣的問題 - 請接受「設計體系是動態流程」的現實，以小為始，快步迭代；我們將要與「混亂」、「複雜」進行持久戰，其中的每一個小戰場都至關重要。

與君共勉。