開發軟體產品前請先搞懂 Design System
本身不是專業設計師，僅和設計師合作所學到的經驗來做記錄和分享，若有得罪之處和誤解，請見諒～
目錄
- 什麼是 Design System？
- Design System 的優缺點？
- 為什麼打造軟體產品前最好先搞懂 Design System？
- 如何建構 Design System？
- 重頭做一次，絕對不要再發生這些事
什麼是 Design System？
Design System 其實就像台灣國小生的生字簿：
- 筆劃（設計風格規範）
- 部首（重複使用的介面設計元素(UI element)）
- 分類（重複使用的互動設計元素(像是檔案管理)）, Ex: 方向（上下左右）
Design System 就是一種規範、標準，只要遵循它的規則基本上不太會出錯。 它在任何領域無所不在，但不只是視覺介面設計的風格規範而已，更是連貫點、線、面的體現出產品本身，以及產品開發階段開發者所遵循的設計語言。
Design System 的優缺點？
－優點
- 因為有一個規範可循，可以減少設計和技術的溝通成本（即使團隊架構逐漸龐大、產品跨國開發）
- 一致性的設計語言，專注在用戶需求、產品本身，以利於產品開發。
－缺點
- 限制創意
- 建構初期時間壓力大，需要在短時間內思考非常地深遠，以便後續產品開發、重構
其實很有趣，雖說它減少產品開發中的溝通成本，卻也在建構初期耗費設計上的時間、心力（請給公司設計部門一個讚）
為什麼打造軟體產品前最好先搞懂 Design System？
如果以軟體科技領域來說，Design System 可能會被歸類為設計部門的職責， 但我認為只要是開發自有產品，而不是一般接案、代工公司，那基本上公司從上到下都要知道 Design System，因為它會在產品投入開發後發揮強大的影響力！甚至在跨產品團隊逐漸擴大成為一種標誌性的識別。
－身份不同會有不同的體悟
- 對 Designer 而言，Design System 是一種復用的元件集合。
- 對 RD 而言，Component 是遵循 Design System 所開發出的 UI 復用元件。
一旦 Design System 建立完成後，RD 就能夠遵循 Design System 開發出團隊所需要的共用元件， 但在開發共用元件之前，如果 RD 不知道 Design System 就埋頭開始開發，那麼在不懂的情況下所開發出的元件，可能會造成視覺落差、破壞中長期產品的標誌性識別。
這也是為什麼打造軟體產品之前，最好先搞懂 Design System 的原因之一。
如何建構 Design System？
建構 Design System 需要同時思考到產品本身、產品標誌性識別甚至是 CIS，一但有這些共識，就會開始以下步驟：
-
盤點 Visual Audit (視覺審核)
- 確認元素和品質
-
建立 Visual Design Language(視覺設計共同語言)
- 顏色
- 尺寸
- 字體
-
打造 UI Library
-
Documentation（文件化）
- 標準建立完的最後一步就是文件化以利後續溝通，至於用什麼方式呈現就單看團隊的決定。
UI Library 建構的工具百百種，這裡不一一紀錄，可以參考：
重頭做一次，絕對不要再發生這些事
設計團隊很用心地完成 Design System、前端工程部門也遵照設計規則去開發出內部的 Component Library，可是做完之後我們遇到了以下問題。
－若有多個專案和需求，根本來不及提供給需求方
如果今天只有一個產品線，設計師和工程師還可以一步一步地設計、開發，但今天若有多個產品線，所需要的 Component 都不一樣那根本就沒辦法應付。
來不及提供怎麼辦？不做了嗎？當然不是！ 開發部門先捨棄設計規則，一但設計團隊把 Design system 釋出後再無縫接軌替換 Component。
在這階段 PM 需要知道有哪些 Component 是沒有遵照 Design system，因為同時設計和開發的情況下 Component 會有多個版本，一不小心這個 Component 在 A 產品、B 產品就會長不一樣。
－必須有專責的開發部門、窗口
在團隊當中人員的調動都是很正常的，可是如果原本負責公司內部 Component Library 的 RD 有任何異動，這時候誰要維護、開發？
為了避免這種事情發生，團隊一開始就要明定由哪個 PM、團隊負責，這非常重要！
它也是屬於產品的一部分，由 Component 所疊加上去的功能，是最貼近使用者、客戶的產品。