建構品牌元件庫

背景與問題

產品在快速迭代的早期階段，累積了大量沒有統一規範的設計債：同一個元件在不同頁面存在不同的樣式、不同的命名或是狀態缺漏，導致工程師很難直接套用，每次開發都會發生重工或需要大量的溝通成本。

起初這個問題是工程師向我反映，這讓我意識到產品設計上不能只是一味追求快速，「規格化」顯得越來越重要，這將會影響整個團隊的開發效率。

在我與主管討論過後，決定為品牌建立一個完整的「元件庫」，並將這個目標與績效掛鉤，用半年的時間來解決這個問題。

我的角色與貢獻

這個計畫由我發起，並與另一位產品設計師共同規劃，最後再與主管討論執行方式，具體包含：

1. 識別團隊成員在使用元件庫時的痛點，定義優化範圍
2. 分析 Figma、Ant Design、Lightning Design System 等成熟設計系統架構
3. 盤點並整理出 34 個高頻元件，並建立可視化表格掌握進度
4. 建立統一的樣式、命名與邏輯規範，確保設計端與工程端能直接對應
5. 規劃分階段導入策略，在不影響既有功能的前提下滾動式更新
6. 說服主管將任務列入設計團隊 OKR，確保品質與績效掛鉤

設計過程

1. 釐清需求，縮小範疇

在動手之前，我先訪談了三個最重要的關係人：其他設計師、工程師團隊、產品經理，想要了解他們各自對元件庫的期待。整理後發現三方的需求分別落在： 一致性、模組化、文件紀錄三大重點。

為了同時滿足三方對一致性、模組化、文件紀錄的需求，我參考了多個成熟設計系統，發現大多數元件庫都包含三大類：元件狀態、元件使用規範、元件使用情境。其中「元件狀態」與「元件使用規範」這兩類就足以涵蓋三方的核心需求；而「元件使用情境」雖然有助於文件完整性，但考量到當下的資源與時程，我決定暫時放棄這個部分，優先聚焦在能直接解決痛點的前兩類。

2. 全面盤點

我透過多種方式盡可能還原元件的真實樣貌：翻閱 Sketch 與 Figma 的歷史舊檔、查閱過去留下的規格文件、直接閱讀工程師的程式碼、詢問工程師釐清邊界行為，以及反覆把玩產品本身來觀察實際呈現與設計稿的落差。

這個過程讓我意識到，過去的設計工作更像是在一棟樓裡做裝潢，只關注表面的視覺呈現；而這次的盤點，才真正讓我看見了這棟樓的地基與鋼筋結構。最終整理出涵蓋樣式、字體、元件等共 34 個需要建構的部分。

3. 定義統一規範

盤點完之後，我針對前面歸納出的三個核心需求，分別找出對應的解法：

① 解決「元件在不同頁面樣式不一致」的問題

我為每個元件明確列出所有可能的狀態變體，涵蓋大小、交互（Hover、Active、Focus、Disabled）與顏色等維度。這個階段需要與其他設計師頻繁討論，目的是讓不同裝置共用同一套邏輯，例如 Web 端按鈕的 Disabled 狀態，必須與 App 端的 Disabled 表現一致，避免使用者在跨裝置時產生認知落差。

② 解決「命名統一、元件能重複使用」的問題

我先列出會被頻繁使用的基礎物件（字體、顏色、Icon 等），再與工程師一起討論哪些數值應該被抽出來變成變數，以加速他們轉譯為程式碼的過程。最後再把這些 Token 整理回元件庫，讓設計與工程在同一套命名系統下協作。

③ 解決「不知道元件何時、如何使用」的問題

我整理了一份專門記錄使用規則與邏輯的文件，明確說明每個元件適合的場景、不該被使用的情況、以及搭配規則。這份文件成為設計師與 PM 在規劃流程時的共同依據，減少了過去靠口頭溝通造成的解讀差異。

4. 分階段導入，降低風險

為了避免大規模更動造成 Bug 以及不想耽誤到產品主線的開發，我與 PM 討論後決定採取「大包小 + 滾動式調整」策略：以一個主要進行中的產品專案為載體，同步優化既有元件，滾動式將新規範導入產品。這樣做一方面避免了大規模更動造成的風險，另一方面也讓團隊能持續推進手邊更重要的專案。

5. 建立迭代流程

導入完成後，我也建立了一套後續更新的 SOP，讓團隊成員清楚知道當元件需要新增或修改時，該走什麼流程、誰來決策、何時同步，避免日後再度累積設計債。

成果

1. 設計時間：小型專案從平均 2 天縮短至 1 天
2. 開發 BUG 數：次專案從 15 個降至約 5 個
3. 初稿通過率：PM 過稿從 2 次降至幾乎 1 次

---

反思