Shopify 設計系統不只是一頁按鈕和色票。它要讓設計稿、Theme settings、Liquid、App block 和內容編輯使用同一套規則，也要涵蓋商品缺貨、折扣、錯誤、載入、鍵盤與行動版等交易狀態。只整理正常畫面，真正開發時仍會重新做決定。
先從現有商店盤點，不必一開始重畫所有元件。找出重複模式與不一致，再建立能被實際頁面採用的最小核心。
先盤點頁面和狀態
選首頁、集合、商品、購物車、帳號與內容頁，截取 typography、color、spacing、grid、button、form、card、badge、accordion、modal 和 navigation。每個元件記錄 variants、states、responsive behavior、資料來源和目前實作位置。
特別找出 hover 之外的 focus、disabled、loading、error、empty、sale、out-of-stock 和 long content。這些狀態最容易在設計系統外被臨時補上。
Token 使用語意命名
建立 primitive token，如品牌色階、字級與 spacing，再用 semantic token 表達用途，例如 surface-primary、text-muted、border-error。元件使用 semantic token，品牌換色或深色區塊時不必逐一修改硬編碼色值。
Theme settings 應只開放經過設計的選項。若每個 section 都能輸入任意色碼與間距，token 很快失效。將可編輯自由轉成有限的「一般、強調、深色」等組合，並驗證對比。
元件要對應 Shopify 資料
Product card 不只是圖片和標題，還有價格區間、比較價、variant、badge、availability、market 與 localization。Variant picker、quantity、discount、subscription 和 cart line 也各有 API 與錯誤狀態。文件需說明資料 contract，避免設計名稱和程式欄位各自發展。
Sections 和 blocks 則是內容模組層。將元件組成可編輯 section 時，記錄可用 template、schema、最大 blocks、空值與內容長度。可搭配 Shopify 2.0 區塊規劃建立 catalog。
無障礙寫進元件契約
每個互動元件要有語意元素、accessible name、鍵盤操作、focus order、focus appearance、status announcement 和 reduced motion。顏色 token 包含文字、非文字和狀態對比，不用顏色單獨表示錯誤或庫存。
文件附上可測試案例，而非只寫「符合 WCAG」。例如 modal 開啟後焦點進入、Escape 關閉、關閉後回到觸發按鈕；表單錯誤以文字說明並移動或連結到欄位。
設計與程式用同一版本語言
Figma component、Theme/React component 和文件使用一致名稱。每次變更記錄新增、修改、deprecated 與 migration。破壞性變更先提供相容期，避免一個 token 改名讓大量頁面在下一次 build 才壞掉。
若有 Storybook 或 preview route，放入真實繁中、英文、長商品名、缺圖和各種價格。Visual regression 與互動測試能在多頁採用後防止回歸。
治理比初次建置更重要
指定設計與工程 maintainer，新元件申請需說明用途、現有元件為何不足、狀態和 owner。每季查看使用率、重複元件與例外 CSS，安排合併或退場。行銷活動有特殊需求時，先判斷它是一次性組合或值得進核心系統。
衡量設計系統可看重複程式減少、交付速度、無障礙缺陷、元件採用和 Theme editor 任務，不使用模糊的「品牌一致度」作為唯一成果。若需要從盤點到元件治理，可參考 Shopify 設計系統服務的交付邊界。