擁有 Design System 後的延伸議題
今天要延續上一篇 《從設計主管的角度來建構 Design System》的內容，進一步分享當我們為 CMoney 建立 Web Design System 後，視野進一步打開、所探索到的進階議題。這些議題我目前還沒有攻克，只是整理了一些前輩們的思路 :
Measure Design System ROI
設計系統最直接的效益是去衡量設計師 / 工程師所節省的時間，Knapsack 提供了一個從這方面計算的工具。
然而，這裡面需算入前面半年的設計系統製作時間、與未來的定期維護成本。Maximilian Speicher 提出了基於上述因素所做的計算工具與解釋《One formula to rule them all: the ROI of a Design System》。
能這樣計算的前提是 — 設計師的工作內容 / 時數有準確的向設計部回報，這在 CMoney 目前有點難，因為 SCRUM 設計師其實是直屬並回報給 Product Owner 的。
總的來說，我有三種思路 :
- 設計部要求 SCRUM 設計師、甚至是工程師方面回報他們日常工作採用 Web Design System 的紀錄與時間差的前提是我們能精追蹤其工作… 這可能是最科學但又高成本的統計方式。
- 設計部定期問卷詢問設計與工程師這 Design System 的採用百分比、主觀上節省的時間、滿意度。
- 就局部個案去分別紀錄高度客製的設計案與大量採用 Design System 的設計案的設計/開發時間差，以此假設成 ROI。
衡量 ROI 的重要之處在於向公司負責，並使公司同意我們繼續投入人力在維護這個系統、或擴展到 APP 產品線。
Coverage Tracking
- 最科學的方法是透過程式去追蹤前端程式碼中使用了 Design System 的痕跡，痕跡可能會是 Design Token 或特定名稱的 Component，但這一塊得要透過工程部主動出人力追蹤來完成，設計部的可控範圍做不到這件事，Steve Dennis 的《How to Measure Design System Adoption 》介紹了此方法。
- 其次可以使用 Figma Organization 方案，它聲稱會提供類似 GA 的 Dashboard 來幫助我們追蹤 Design System 中元件的使用分佈。然而，Organization 的人頭費是專業版的 3 倍，我們很難在無法衡量成效的情況下爭取公司出 3 倍錢。
- 我們目前則是讓設計師人工回報 Design System 的採用紀錄。
另外，目前 Figma 有針對單一文件的 Instance Finder，也許我們未來能找到、或自行開發出跨檔案的 Instance Finder。
自動化 QA
在上一篇有提到，我們的 Design System 是透過主管 ( 我 ) 與 Peer Review 來把關其設計品質與文件化內容的。當進入維護階段後更新頻率下降到 1 個月 1 次 request，我們的目光和短期記憶將不在 Design System 中，因此需要建立一套 QA SOP 讓任何人有辦法替新的 Design System Check-in 把關。
Design Lint 是目前我最常搜到的工具，用來掃描設計稿的物件有無全部套用好 Style。這就像自動化測試一樣，我相信市面上尚有其它檢查工具待發掘。
自動化控制 Design Token + Dark / Light Mode Switcher
我們的 Design Token 目前是手工制定的，且 Figma 內建僅支援文字、顏色、框線樣式，Spacing 和 Dark mode 與跨網站與應用我們目前尚無法控管。
我打算在後續研究 Tokens Studio for Figma, ********DSO 能否幫助我們解決此題。
Combine multiple APP Design System
最後也是最重要的 — 將 CMoney 既存另外 3 個體系 APP 產品線的 Design System 整併進來，從 Design Token 層級開始統一，並重複前面幾個段絡的做法，達成良好的 Coverage 並使 ROI 得以衡量。
以上是目前為止我對 Design System 的實踐經驗，感謝觀看 ~
