設計規範怎麼建立？Design Tokens、UI 元件與跨媒材交付

同一品牌色在網站是按鈕、簡報是封面、社群又壓在照片上；三個人都照色票做，成果卻像三個品牌。問題不在少一本 PDF，而是決策沒有被拆成可命名、可測試、可交付的規則。

可執行的設計規範要連起 design tokens、UI 元件、響應式行為與文件，讓設計、工程、行銷與簡報製作者都知道哪些值能換、哪些關係不能拆，以及例外的判斷依據。

封面是 AI 生成的設計規範編輯示意，以按鈕、欄位、卡片與色票呈現可共用的介面元素，非客戶作品或真實後台。畫面不代表已實作 design tokens、互動狀態或無障礙規則；下方另以教學圖說明命名與狀態，實際行為仍須在程式中驗收。

一、先分清楚：你缺的是識別、品牌手冊，還是 design system？

這幾種文件常被統稱為「規範」，工作卻不相同。品牌識別設計 決定 Logo、標準字、色彩、字體與影像語言；品牌手冊 把識別的正確用法整理成可查閱章節；本文所談的 design system，則把這些決策轉成數位介面與高頻素材可以反覆使用的結構。

如果眼前問題是同事拿錯版本、供應商不知道誰能核准，或特殊活動每次都繞過規範，應看 品牌規範導入與治理 。如果公司正準備找廠商重做整個網站，需求比較、合約與驗收則屬於 網頁設計公司選擇指南的範圍。

本文把 design system 視為可重用的決策、tokens、元件、模式與文件，不只是一頁色票或 Figma UI kit。若規則沒有說明不同內容、狀態與畫面寬度下的行為，就仍是視覺樣張。

二、從實際通路與高頻失真點開始盤點

建立規範前，先列出正在維護的網站、後台、活動頁、社群、電子報與簡報，再標示主要使用者、更新人、製作者與技術限制。系統範圍應由這張盤點表決定，不由設計軟體的功能倒推。

接著找「最常重做」和「錯了最麻煩」的地方。一家有門市與線上預約的台灣服務品牌，可能不是先缺一套完整圖示，而是活動頁按鈕每次換色、表單錯誤沒有固定說法、手機版價目卡常被裁掉，簡報又使用另一組標題層級。這些問題能直接形成第一批 token、元件與模板需求。

• 內容：最長的繁中標題、價格、警語或多語文字會不會撐破版面。
• 介面：按鈕、表單、導覽與提示是否已有重複但不同的版本。
• 通路：哪些原則共用，哪些尺寸與閱讀情境必須分開。
• 技術：前端框架、內容系統、瀏覽器支援與載入限制。
• 責任：誰能改基礎值、誰只能組裝元件，以及誰負責驗收。

第一版可以只涵蓋服務介紹、預約表單和確認訊息。先讓這條流程從內容、元件到窄畫面完整跑過，再依缺口擴充，勝過先畫一座沒人使用的元件倉庫。

三、Semantic design tokens：先命名用途，再綁定數值

Token 是被命名的設計決策。最底層可以保存原始色階、間距或字級，例如「palette.green.600」；semantic token 則改用角色命名，例如「color.text.primary」、「color.action.disabled」 ；只有元件確有獨立需求時，再建立 「button.primary.background.default」這類 component token。使用元件的人應看見「用途」，不必猜某個灰色或綠色現在代表什麼。

深色模式或子品牌上線時，元件仍引用相同語意角色，只替換底層值，也能查出變更範圍。若 token 只叫 blue、large 或 style-03，團隊仍要靠記憶猜用途，系統很快就會回到人工判斷。

Design Tokens Format Module 2025.10將 token 描述為具有人可讀名稱與值的資訊，也定義 type、description 與 alias/reference 等交換機制。該文件是 2025 年 10 月 28 日發布、被標示為 stable 的 Final Community Group Report，目標是改善設計與開發工具之間的互通。

需要特別辨明：這份規格由 W3C 的 Design Tokens Community Group 發布，但文件明載它不是 W3C Standard，也不在 W3C Standards Track。基礎值、語意角色、元件角色的三層命名是本文建議的工作方式，不是該規格強制的公司架構；採用格式也不代表現有工具會自動完成轉換與同步。

四、元件規範不能只畫正常狀態

一顆按鈕至少要交代結構、尺寸、文字長度、圖示位置、適用情境與不可使用情境。若只有一張預設狀態，工程師仍得自行決定滑入、鍵盤焦點、按下、載入和停用時怎麼呈現；不同人各補一套，元件名稱相同，行為卻不一致。

狀態應依真實功能選擇。一般操作可能需要 default、hover、focus、active 與 disabled；表單還會有 loading、error、success；可切換元件則可能需要 selected 或 expanded。沒有某種互動就不用為了表格完整硬畫，但任何使用者可能遇到的等待、失敗與空內容，都不能留給上線前臨時處理。

表單錯誤尤其容易只做成「邊框變紅」。完整規則還應包含錯誤文字放在哪裡、如何與欄位名稱關聯、送出後焦點移到何處，以及顏色以外是否有圖示或文字提示。內容規則也要放進元件：按鈕用動作動詞、標題最多幾行、金額能否換行，才不會用理想短文案掩蓋真實問題。

設計檔和程式元件最好採可追溯的命名，並記錄 token 對應、屬性、變體和已知限制。不過，Figma 中有一套 variants 並不表示程式已完成；驗收仍要檢查瀏覽器中的內容、鍵盤操作、狀態切換與實際資料。

一個預約表單，如何把 token 接到狀態？

下圖為教學示例，非客戶交付。先把深綠基礎色指定給 color.action.primary，再由主要按鈕的預設背景引用它；焦點則另外定義外框與間隔，不能只把按鈕變深。電話欄位錯誤使用 color.feedback.error，同時顯示「請填完整手機號碼」，不讓紅色成為唯一提示。

範例的窄畫面規則是欄位和按鈕直向排列、提示緊跟電話欄位，文字可換行。交接時用空白、少一碼與完整號碼各送出一次，再用鍵盤走過欄位和按鈕：確認錯誤訊息與欄位有程式關聯、焦點可見、正確資料能繼續。色值、命名與畫面是設計輸入，互動仍需在實際元件中驗證。

五、Responsive 規則要寫行為，不只交三張畫面

桌機、平板、手機三張稿只能顯示三個結果，沒有說明結果之間怎麼變化。斷點應從內容開始擁擠或功能需要改變的位置決定，而不是把常見裝置寬度當成每個專案的固定答案。同一個網站裡，導覽、表格和圖文卡片也可能在不同寬度發生轉換。

每個核心元件都要記錄：容器是否有最大寬度、欄位何時換行、內容順序會不會改、卡片如何堆疊、表格要重排還是允許捲動、圖片焦點與裁切怎麼保留，以及長字串能否正常斷行。若窄畫面改成另一種互動，也要寫出鍵盤與觸控操作，而不是只把元件縮小。

法西納作品集中的GOD MODE 識別設計案例 ，可以用來觀察同一標誌在窄畫面中如何調整版本、尺寸與留白；它是視覺應用示例，不代表所有產品共用同一組 breakpoint。規範真正要留下的，是選用版本的判斷條件。

六、把無障礙納入 token、狀態與驗收

無障礙不應等到畫面定稿才做一次顏色檢查。色彩 token 在核准前，就要放進文字、按鈕、表單邊界、圖示與焦點狀態測試；元件文件則要寫出鍵盤順序、可見焦點、名稱、錯誤訊息和內容放大後的行為。只在設計稿標示「已通過」，無法代替程式與輔助科技測試。

依WCAG 2.2 的 AA 成功準則，一般文字在排除規範所列例外後，最低對比為 4.5:1；辨識使用者介面元件與狀態所必需的非文字視覺資訊，最低為 3:1。這表示錯誤框線、選取記號與自訂焦點指示不能只在理想螢幕上「看得到」，而要依相鄰顏色實際計算與檢查。

WCAG 2.2 的 2.5.8 也要求指標輸入目標至少能容納 24×24 CSS pixels，但同一條準則列有 spacing、equivalent、inline、user-agent control 與 essential 等例外。因此，規範不應把「所有按鈕一律 24 像素」當成完整結論；仍要依目標邊界、鄰近控制與替代操作逐項驗證。

台灣可同時查閱數位發展部公開的 網站無障礙規範（110.07）。該頁交代 2017 年「網站無障礙規範 2.0」對應 WCAG 2.0，而 110.07 版是在既有架構上增修 17 個成功準則；它不等同 WCAG 2.2，也不能單靠一張檢核表推論所有網站已合規。政府或採購專案應以契約指定的規範版次、等級、檢測程序與驗收要求為準。

七、核心規則一致，通路轉譯不必長得一模一樣

網站會隨視窗與內容重排，社群圖和簡報頁多半有固定比例；三者可以共用品牌角色、文字層級、影像選擇與語氣，卻不該硬套同一個像素版型。可把共用原則留在核心層，再為網站、社群與簡報建立各自的 channel adapter 或模板。

例如「主要行動」在網站是按鈕，在簡報可能是下一步聯絡資訊，在社群則是貼文結尾的單一指令。三者共用訊息優先順序與品牌語氣，但尺寸、位置和互動方式各自驗收。這種一致是同一套判斷，而不是把同一張圖裁成不同大小。

螢幕上的 RGB 色彩也不能直接保證印刷成品一致。若規範延伸到紙本，應另列印刷色、材質、打樣與製程條件；design token 可以保存角色與對應資料，不能取代印前確認與實體校色。

八、交付前用真實任務驗收這套系統

交付包至少要讓接手者找到 token dictionary 與正式來源、元件狀態、responsive 行為、無障礙注意事項、內容限制、常用模板，以及設計名稱與程式元件的對照。尚未解決的例外也要明列範圍。

驗收時不要只請原設計者逐頁講解，改讓沒有參與前期的人完成幾個任務：新增一頁服務內容、輸入較長的繁中標題、建立表單錯誤與載入狀態、切到介於兩張設計稿之間的寬度，再把同一則訊息做成社群圖或簡報頁。過程中每一次猜測，都是文件或元件尚未回答的問題。

• 找得到唯一正式的 token、元件與模板來源。
• 修改語意角色前，知道會影響哪些元件與通路。
• 真實內容不會截斷、重疊或只靠顏色傳達。
• 設計、程式與文件使用一致元件名稱，差異有紀錄。
• 社群與簡報保留核心識別，也符合各自的閱讀情境。

驗收還要說清楚哪些已能使用、哪些待工程驗證、哪些只是方向範例。至於版本發布、舊檔停用與例外核准，應進入後續品牌治理，不在元件交付時含糊帶過。

九、FAQ：建立設計規範前常見問題

十、結論：先讓一條真實流程可以被別人重做

建立設計規範最務實的起點，不是一次收齊所有元件，而是挑一條高頻流程，把 token、狀態、窄畫面、內容與驗收做完整。當另一個人不靠口頭提示也能延伸，這套系統才真正開始工作。

若需要盤點品牌接觸點、釐清識別與數位設計的交付範圍，可先查看法西納的設計服務，再透過 聯絡頁整理目前使用的網站、簡報、社群素材與最常出錯的情境，讓第一次討論從真實問題開始。