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，並在不於中途弄壞任何一邊的前提下，逐步替換產品與設計檔案中的舊有元件。
