設計系統（design system），我想許多從業的設計師多少都有聽過，或是也曾試著在自家產品導入設計系統，但大多設計師所想像的設計系統，大概僅是在軟體（figma）裡設計好組件（component），讓其他設計師也可以共享這份已經做好的組件，嚴格來說這樣的做法僅是在設計端建立一個共享的資源庫（library），不能稱的上是設計系統。
但要如何建立一套完整的設計系統，每個公司產品的方式都不太一樣，這系列的文章，我會分享我個人在產品導入設計系統的經驗與思路，這套思路，也是我自己近年來對設計系統的理解與經驗累積。放眼望去，我也很少看到真的有設計師去實作整套設計系統，或許受限於產業類型或是產品規模，大多文章的描述還是停留在對原子設計（Atom Design）的認知階段，離真實的設計系統實作仍有一段距離。
而就我個人經驗，設計一套系統並沒有什麼固定的套路，其實以台灣公司的產品規模也未必要導入設計系統，但要建構一套設計系統也是不行，我是根據自己在產品開發經驗的累積，並針對自家產品開發的需求，一步一步完成這套系統邏輯，在每一次執行的專案中，慢慢的偷渡設計系統的概念到產品專案中，在工程師意識到的時候，系統大概也就導入一半了，要讓公司投入資源開發設計系統，在台灣一直都是一件困難的事，但一點一點滲透、嘗試，終究還是可以建立一套屬於自家產品的設計系統。
從「設計端」的角度切入設計系統
這篇文章的標題，強調是從「設計端」來建立設計系統，為什麼要強調設計端？因為大部份的設計系統，無法跟開發端分離，所以不會單純由設計師建立，這邊我指的設計系統，是像 Microsoft 或是 Google 等級的公司的設計系統，設計師扮演提供設計與概念的角色，但要導入開發，還是需要開發人員的協助與配合（亦或是，設計師本身具有開發的能力），所以一般來說，設計系統是設計師與工程師的共同產出物。
但在台灣以代工產業為主的工作氛圍下，很少會有公司願意投入開發資源在設計系統的建立上，因此設計師在設計系統上所能產出內容是有限的，大部份的設計師因為沒有程式經驗，所以設計系統的導入，只停留在與設計師共享組件與樣式的階段，但想設計一套在開發端可執行的系統，仍然是有可能的，本系列文，會以設計師的角度出發，在產品開發端與設計端之間，找出一套讓設計系統可以執行的方式，就算工程端不導入設計系統，設計端仍可以運用這套系統來維持設計的一致性。
只要有心，設計師終究會找到自己的出路。
為什麼要建立設計系統
通常我在思考為什麼要建立設計系統時，都會從目前所「遇到的問題」及「期望看到的結果」來思考如何建立設計系統，一般在產品開發中常見的問題：
- 「樣式不統一」 → 「在不同裝置、平台上的設計樣式要儘量達成一致」
- 「設計資源樣式套用混亂，一堆重覆的色號與資源（Asset）圖片」→「所有產品的的樣式、圖片、圖標資源最好應該都由設計師來管理，而且最好可以達到隨意的切換產品樣式與主題」
- 「組件規格混亂、重複設計組件」→「需要有一份可維護、可擴充的組件文件撰寫規範」
當然上述的問題，未必要透過建立設計系統來解決，只要養成良好的文件管理習慣也可以處理，但在想導入設計系統的需求下，根據問題與期待的結果，建立設計系統會有四個主要我想達成的明確目標：
- 建立統一且可管理的樣式規範
- 建立一個由設計師管理樣式與資源的方法
- 建立設計文件的撰寫規範
- 撰寫組件設計規範（component design guideline），並基於此讓工程師持續迭代的組件
設計系統的產出物
為了達成設計系統的目標，設計端應該要有一個很明確的產出成果供工程師使用，我們先不期待做出像 Google Material Design 或是 Apple Human Interface Guidelines 或是 Ant Design 這樣完整的設計規範，因為產品的量級與開發資源差太多了，我們能做的，是建立起一個在100人左右的開發團隊下，仍可穩定執行的設計系統。
而在這個條件下，設計師的產出物主要有兩項：
- Design Token
- Design Guideline
我想大多數對於設計系統有一些了解的設計師對於這兩個名詞都不會感到陌生，但怎麼建立、怎麼維護、怎麼管理，這才是建立設計系統所需知道的 know how，而 Design Guideline 的撰寫，我之前的文章已經提供了撰寫的規範（介面設計規範（UI Design Guideline）的撰寫方式），後面的文章，我會著重介紹如何建立 Design Token，並將它套用在不同產品與專案上；既然是系統，那也代表只要了解這套方法，想不同產品上要使用它，應該都不是難事。
先完整，再推進
我在自家產品嘗試導入設計系統的心態是，就算工程師不導入，設計師端依然可以根據這兩個產出的文件，來維持設計的一致性，當然有時候也未必是工程師不想導入，也有可能是設計師對於系統的理解不足，沒有足夠的經驗與能力完成 Design Token，對工程師來說，當然也不會冒然的去增加產品開發的風險，畢竟這些都是「額外」的需求，都是在產品需求之外的事。
因此個人建議，這些文件的產出未必要讓工程師馬上去實現，先讓這件事看起來很完整，每個專案的過程，一點一點去推動、滲透。當樣式有被定義、組件有被重覆使用，工程師也會意識到，原來設計端早有一套固定的設計規範，設計系統的雛型也就會在這個過程中，不知不覺的被實現。
總結
Design Token 與 Design Guideline 是設計師與工程師溝通的橋樑，也是整套設計系統的基石，有了這套系統，在團隊成員擴編時，才能漸漸的導入設計營運（Design Ops）。
文末想感謝自己團隊的小伙伴們，雖然我們團隊很小，在撰寫文件或是做 Design Review 時，也是被我各種吹毛求疵與刁難，但這樣的訓練是有代價的，至少迎來產品導入設計系統的第一道曙光。
