從設計主管的角度來建構 Design System
今天，我想談談在 CMoney 推進 Web Design System 的現狀與心得。
背景
當我在 2021 年進入 CMoney 時，公司已有超過十個 SCRUM 團隊，每隊均配有自己的設計師和前端工程師，各自打造獨特的設計和程式碼，靈活性雖高、卻也像無數次的重新發明相同的輪胎。而類似的易用性問題，時常重複發生在不同的 SCRUM 團隊中。
在這些團隊裡，只有兩個大型產品（’籌碼 K 線’和’股市爆料同學會’）以及一款作者聯名的選股 APP 產品線有達到 Design System 的雛型 — 可自體複用的設計稿與程式碼，而 CMoney 本身的理財寶網站則處於維護不足的狀態。
作為設計主管，我看到了提升公司產品設計體驗的必要性。為了更有效地將設計師的心力花費在分析與高階的 UI 互動上，我認為我們需要逐步整合設計風格，並建立一套設計系統。以避免設計師們的大部分時間被浪費在重複創建相同的基礎元件上。
—
對既有產品線採用規範化來穩定品質
針對現有的APP產品，我通過和設計師以及利益相關者的討論，陸續提出了一套對 CIS、Dos & Don’ts、共用登入模組、圖表元件範本等的規定，以收斂不同APP之間的視覺和UX差異。
為 CMoney 網站建立全新 Web Design System
至於 CMoney 的網站，由於公司在這方面並未建立 UI 庫（過去都是設計師短期、局部的做設計），而工程部門又確定未來會逐步將網站從 Aspx 轉變為 Vue.js。設計部門有充足的空間提出一套基於Vue.js的設計系統，從而大大提高 CMoney 網站的開發速度，並作為我們 APP SCRUM 團隊的設計系統參考案例。
我們從 2022 5 月開始規劃、8 月任命專任設計師做設計、11月完成 Web Design System 本體、12 月完成使用操作說明，歷時約半年。其後我們進入運用階段，運用在至少 7 個子網站中。
建立 Web Design system 各時期面臨的一些決策
前期 —
1. 以 TDesign 作為基礎來改造成 CMoney 自己的 System
從 0 開始會花費數個月的準備時間 — Great designer Steal 😀
而 TDesign 是基於 Vue.js 開發，符合 CMoney 的前端技術 (相對於 Ant Design 基於 React) 且具有整套完整的 Figma 設計稿 (相對於 Element UI 的不完備)
2. 任命專任設計師
在設計系統的建構階段，需要一個人專心投入、並和工程團隊適時接洽，採用中央集權的方式打造設計系統是最有效率的方式 — 當然這位設計師本身要有足夠能力。
我們很幸運的能夠維持長達半年的設計團隊穩定 (沒有 SCRUM Team 出缺，我能留一位 Web 經驗不錯的 UIUX 設計師在我手上，長時間負責此事。)
3. Naming Rule
我們對 Figma Component 採用中文命名、Design Token 則是英文，這是因為 Figma Component 的使用者是設計師們，他們對中文命名較能直覺使用； Design Token 則是給工程師看的，所以使用他們熟悉的英文變數來寫。
4. Design System 文件型式
我們沒有採用業界知名的 Zeroheight，原因是前端團隊決定自己建一個 Component Library；僅有 Web UI 設計稿的情況下，Figma 檔案也還沒大到需要拆分檔案，因此使用 Zeroheight 的好處還不夠明顯。
5. 我的角色
我在前期每週至少一次 Review Design System 規劃進度，確保專任設計師有考慮到跨平台、RWD、與 CMoney 既有產品 UI Pattern 等因素；並和工程主管保持兩週一次聯繫，在各階段召開設計 vs 工程的 SOP 會議。
中期 —
1. 從由主管 Review 轉變為 Peer Review
專任設計師開始召開設計師定期會議，將有機會進行 Web Design 的 SCRUM Team 設計師聚集，透過會議 Announce 新的設計、並聽取設計師們的回饋，這能幫助專任設計師得知前線設計師們真正需要滿足的 UI 情境。
2. 股市圖表
CMoney 是做股市分析起家的公司，我們的網站常需要使用複合式的資訊圖表來示股市行情，這是 TDesign 沒辦法給我們的，我們得要自行繪製。在這裡我花了較多心力 Review 設計進度，以確保新產出的股市圖表與 CMoney APP 中的資訊顯示體驗有一致性。
3. 建立版號並 QA 工程團隊的開發進度
工程團隊不可能等到 Design System 設計完才進行開發，他們在我們還在調整 Design System 的雛形時就開始拿 TDesign 做客製化。不可避免的會碰到他們開發完的元件後設計師才發現元件變化情況不敷使用、而更新設計稿，工程師再度需要開發的狀況，所以我們會用版號來標注設計稿與元件程式的版本。
後期 —
1. 操作手冊
在設計完成度達 90% 後，專任設計師開始回頭為每個元件撰寫操作手冊，而我則進來 Review 文件，協助其修正不易看懂的說明。
2.從中央集權轉變為分散管理
當 Design System 完成後，工作量不需要綁定一人負責，這時我指名 3 位 SCRUM Team 設計師接手後續維運 — 當有設計師或工程師反應 Design System 有優化需求時，他們自行協調出人力來接手；原本的專任工程師則轉為 Design System 顧問，安排他進 SCRUM Team 做產品，轉換心情。
成果
Design System 完成後帶來的效率化是肯定的，CMoney 甚至在 2023 年減少了 5 位以上 Web Front-End 的編制 : 從設計師與工程部的估算來看，我們大致能減少 70% 的工作，減少的部分來自於畫設計稿、標注說明、開發元件、QA 上。
使用 Web Design System 的網站有 7 個以上，包外同、外部，案例包含：CMoney 美股、CMoney ETF、AI 財經百科等。
…
下一篇文章，我會介紹擁有 Design System 後的延伸議題，作為我未來的研究項目。
今天的部分到此為之，感謝觀看 ~
