CNCBI · 設計系統
200 萬用戶規模下的設計熵
設計並不容易規模化。效率不會憑空出現。靠招聘來規模化設計，卻不先建立標準，是一個迷思。每來一個新同事，產品裏就會冒出新的配色、字體與模式想法，不一致不斷擴大，維護成本不斷上升。每一個新同事，都在增加設計的熵。
只有一個方法能止住混亂的蔓延：承諾推行一套設計系統流程。設計系統的逐步成長，等同於一致性與軟件開發速度的逐步提升。設計系統是一套針對設計與程式碼的標準，加上能統一兩種實踐的元件，給所有人同一套指令、同一套 Lego 積木。
稽核既有元件
把每一個頁面按元件類型整理，搜尋特定頁面，用右側面板按元件篩選，並把各頁面當下的使用案例攤出來。這同時暴露了設計不一致藏在哪裏，成為整套系統的起步地圖。
參考系統與銀行業介面
不是所有設計系統都能套用到銀行業。經團隊討論後，IBM、Ant Design 與 Bootstrap 被選為結構參考；HSBC 與 MOX 則作為銀行業介面的參考。
Ant Design 尤其示範了出色的開發者導向體驗：元件按類型分類（Data Display、Data Input、Navigation⋯）、頁內導覽錨點、每個狀態都先攤出來、互動範例，以及一鍵複製或在沙盒中開啟程式碼。這亦成為團隊自家文件的目標。
用 POC 選出合適的工具鏈
設計系統管理對公司而言是全新領域。在把工作流推展到整個設計團隊之前，先以小型 POC 驗證管理機制如何契合各團隊當下的做法，而不只停留在理論。
逐個工作坊化每個元件
針對每個元件：設計其屬性與狀態，並訂立使用指引。相關 Jira 使用案例、業界最佳實踐、文章及其他團隊的應用方式均被逐一覆核，再據此定義團隊的標準形態。系統結構亦從這些決定中逐步浮現。
每週時間軸，基礎優先
一份按「要做甚麼、由誰來做」制定的每週時間表，讓持份者掌握進度，並便於資源調配。待辦按 Jira 使用案例的出現頻率排列，但字體、色彩與版面等基礎工作被放在最前，因為其後每個元件都依賴它們。
命名規範與巢狀符號
梳理業界文章與其他 UI 工具套件，比較命名規範與巢狀符號策略。過往經驗顯示，最合適的模型就是契合當下工作流的那個；命名亦會隨工具演進而調整。整套命名系統因此被視為一份持續演化的契約。
Sketch → Invision DSM → Storybook
每個情況的使用指引都寫得清清楚楚。styleguide 的 Sketch 符號透過 plugin 直接匯入 Invision DSM。Storybook 為前端開發者寄存實時元件範例，附互動程式碼片段。一個 design-token API 讓團隊其餘成員自動與設計值保持同步。
落地與替換
與工程師、PM 及其他持份者的溝通，是最困難的部分。落地意味著開發新元件、把它們接上 Storybook 與 Invision DSM，並在不於中途弄壞任何一邊的前提下，逐步替換產品與設計檔案中的舊有元件。
