跨境電商設計系統
🏆 專案成就亮點
為公司建立了一套健康、清晰且可長期維護的 Design System 架構，讓團隊在多專案並行的情況下仍能維持一致的產品體驗。
獨立建立 400+ Components、200+ Variables
專案 UI 產出效率提升 約 4 倍
建立 Design System 維護規則書 與 系統導入指南
建立 Core / Project 雙層設計系統架構，支援多平台產品
🚀 專案願景
一致性（Consistency）：
提供統一的設計語言與標準，確保不同專案或產品之間的體驗連貫。
效率（Efficiency）：
減少重複溝通與設計/開發成本，讓團隊能更快推出高品質的成果。
可擴展性（Scalability）：
建立清楚的更新與版本管理規範，使系統能隨產品需求持續成長而不失控。
協作性（Collaboration）：
讓設計師、工程師與 PM 有共同依據，降低跨部門溝通摩擦。
持續性（Sustainability）：
確保設計系統不因人員更替或時間推進而失效，能長期維持有效運作。
類別
Design System
時間
2025/01 ~ 2026/02
擔任角色
設計系統規劃與建立者
工具
Figma、Notion、Gemini
🧗 面對的挑戰
公司品牌與產品服務複雜，需要建立一套可長期維護的設計架構
原有設計稿中的元件樣式不一致、結構混亂
需要與設計、PM、工程等跨部門建立共識
🔍狀況 (Situation)
公司當時其實已經有完整的 Hi-fi Mockups，產品也已經上線，但 Figma 檔案的狀態幾乎是失控的。設計檔案中存在許多問題：
Component 四散各處
同一個 Component 被複製出多個版本
原始 Component 已經找不到
頁面幾乎沒有使用 Auto Layout
整體來說，設計檔案就像是一個混亂的車禍現場，如果不重新整理，未來的維護成本會持續放大。
(圖片：原始設計檔混亂頁面)
🔍狀況 (Situation)
公司當時其實已經有完整的 Hi-fi Mockups，產品也已經上線，但 Figma 檔案的狀態幾乎是失控的。設計檔案中存在許多問題：
Component 四散各處
同一個 Component 被複製出多個版本
原始 Component 已經找不到
頁面幾乎沒有使用 Auto Layout
整體來說，設計檔案就像是一個混亂的車禍現場，如果不重新整理，未來的維護成本會持續放大。
(圖片：原始設計檔混亂頁面)
📝任務 (Task)
我的任務是：
為公司重新規劃並建立一套 Design System，讓未來產品開發可以具備：
一致性（Consistency）
效率性（Efficiency）
可擴展性（Scalability）
協作性（Collaboration）
持續性（Sustainability）
(圖片：Design System Roadmap Audit → Build Tokens → Build Components → Documentation → Team Adoption)
📝任務 (Task)
我的任務是：
為公司重新規劃並建立一套 Design System，讓未來產品開發可以具備：
一致性（Consistency）
效率性（Efficiency）
可擴展性（Scalability）
協作性（Collaboration）
持續性（Sustainability）
(圖片：Design System Roadmap Audit → Build Tokens → Build Components → Documentation → Team Adoption)
⚡行動 (Action)
Step 1 — 規劃設計系統架構
首先，我先全面了解公司的產品業務與服務內容，確保設計系統的架構能符合實際產品需求。
公司的產品包含 8 個不同服務平台，過去每個平台的 UI 都各自發展，風格差異非常大。
因此我規劃了一個 雙層 Design System 架構：
Core Design System
負責管理所有專案共用的基礎元件，例如：
Design Tokens
Buttons
Labels
基礎 UI Components
Project Design System
管理各個專案特有的元件，例如：
專案特殊色彩
專案特有元件
特定業務模組
每個專案檔案會同時接入：Core Design System + Project Design System
這樣可以在 維持整體 UI 一致性的同時，保留各服務的差異化。
(圖片：設計系統架構圖)
⚡行動 (Action)
Step 1 — 規劃設計系統架構
首先，我先全面了解公司的產品業務與服務內容，確保設計系統的架構能符合實際產品需求。
公司的產品包含 8 個不同服務平台，過去每個平台的 UI 都各自發展，風格差異非常大。
因此我規劃了一個 雙層 Design System 架構：
Core Design System
負責管理所有專案共用的基礎元件，例如：
Design Tokens
Buttons
Labels
基礎 UI Components
Project Design System
管理各個專案特有的元件，例如：
專案特殊色彩
專案特有元件
特定業務模組
每個專案檔案會同時接入：Core Design System + Project Design System
這樣可以在 維持整體 UI 一致性的同時，保留各服務的差異化。
(圖片：設計系統架構圖)
Step 2 — 整理與釐清
我將整個設計系統拆分為三個層級：
1️⃣ Tokens
2️⃣ Components
3️⃣ Modules
同時透過 Page 結構標示元件的使用情境，例如：
Input Layer
Content Layer
Navigation Layer
Feedback Layer
接著我逐頁檢視產品 UI，分析各介面的 Tokens、元件結構與使用邏輯，並從最基礎的 Tokens（顏色、字體） 開始建立設計系統的基底。
其中最困難的部分是，在舊設計稿中 同一個元件常常存在 2–3 個不同版本，例如間距、字體大小或 Icon 尺寸略有差異。
為了確保系統的一致性，我需要 反覆比對上線產品畫面，並與設計與工程同事來回確認正確樣式。
(圖片：類架構的 Sidebar、未統一樣式的按鈕統整為一)
Step 2 — 整理與釐清
我將整個設計系統拆分為三個層級：
1️⃣ Tokens
2️⃣ Components
3️⃣ Modules
同時透過 Page 結構標示元件的使用情境，例如：
Input Layer
Content Layer
Navigation Layer
Feedback Layer
接著我逐頁檢視產品 UI，分析各介面的 Tokens、元件結構與使用邏輯，並從最基礎的 Tokens（顏色、字體） 開始建立設計系統的基底。
其中最困難的部分是，在舊設計稿中 同一個元件常常存在 2–3 個不同版本，例如間距、字體大小或 Icon 尺寸略有差異。
為了確保系統的一致性，我需要 反覆比對上線產品畫面，並與設計與工程同事來回確認正確樣式。
(圖片：類架構的 Sidebar、未統一樣式的按鈕統整為一)
Step 3 — Icon 系統
Icon 的整理其實是整個專案中最頭痛的部分之一。
一開始我將每個 Icon 按照尺寸建立，例如：
Heart 16x16、Heart 20x20、Heart 24x24、Heart 30x30
但很快發現這樣的方式 建立與維護成本都很高，也很容易失控。
因此後來我改用 Icon Wrapper 架構。
做法是：
將每個 Icon 製作成 Component
依功能分類，例如 Base / Outline / Solid
建立一個 IconWrapper Component
Wrapper 主要負責：
控制 Icon 尺寸
透過 Instance Swap 切換 Icon
這樣就建立了一套 可快速擴展、可控且好維護的 Icon 系統。
(圖片：Icon 原本的製作方式與後來的製作方式，Icon 表)
Step 3 — Icon 系統
Icon 的整理其實是整個專案中最頭痛的部分之一。
一開始我將每個 Icon 按照尺寸建立，例如：
Heart 16x16、Heart 20x20、Heart 24x24、Heart 30x30
但很快發現這樣的方式 建立與維護成本都很高，也很容易失控。
因此後來我改用 Icon Wrapper 架構。
做法是：
將每個 Icon 製作成 Component
依功能分類，例如 Base / Outline / Solid
建立一個 IconWrapper Component
Wrapper 主要負責：
控制 Icon 尺寸
透過 Instance Swap 切換 Icon
這樣就建立了一套 可快速擴展、可控且好維護的 Icon 系統。
(圖片：Icon 原本的製作方式與後來的製作方式，Icon 表)
Step 4 — 建立規則
在元件建立完成後，我開始補齊設計系統中最重要的一部分：規則與文件。
我建立了 Design System 維護規則書，內容包含：
設計系統架構
Core / Project System 說明
元件更新流程
新需求提出流程
職責分工與版本管理
檔案分類方式
同時我也建立了 Design System 導入指南，說明：
設計系統串接方式
檔案架構
版本控制
專案執行流程
讓團隊在未來的專案中，可以持續使用並維護這套系統。
(圖片：各個規則的文字截圖)
Step 4 — 建立規則
在元件建立完成後，我開始補齊設計系統中最重要的一部分：規則與文件。
我建立了 Design System 維護規則書，內容包含：
設計系統架構
Core / Project System 說明
元件更新流程
新需求提出流程
職責分工與版本管理
檔案分類方式
同時我也建立了 Design System 導入指南，說明：
設計系統串接方式
檔案架構
版本控制
專案執行流程
讓團隊在未來的專案中，可以持續使用並維護這套系統。
(圖片：各個規則的文字截圖)
Step 5 — 跨部門溝通
當設計系統建立完成後，我與團隊開始與其他部門同步資訊，包括：
PO
PM
Engineering
透過這些溝通，我們建立了四方共識：
未來元件更新與設計修改，都會以 Design System 為依據。
這讓元件管理與產品迭代變得更加清晰。
(圖片：Design → PM → Dev 流程圖)
Step 5 — 跨部門溝通
當設計系統建立完成後，我與團隊開始與其他部門同步資訊，包括：
PO
PM
Engineering
透過這些溝通，我們建立了四方共識：
未來元件更新與設計修改，都會以 Design System 為依據。
這讓元件管理與產品迭代變得更加清晰。
(圖片：Design → PM → Dev 流程圖)
✨結果 (Result)
最終，我成功為公司建立了一套完整的設計系統生態。
成果包含：
建立 400+ Components
建立 200+ Variables
訂定 Design System 維護規則書
建立系統導入指南
整體設計與開發流程效率提升 約 4 倍。
團隊在未來的專案中，也能持續維持：
一致性
效率
可擴展性
協作性
持續性
(圖片：可能搞個什麼 PO、PM、工程、UI 四方一起取得共識合作的圖)
(圖片： 400+ Components 和 200+ Variables 和 4 倍生產力的配圖)
✨結果 (Result)
最終，我成功為公司建立了一套完整的設計系統生態。
成果包含：
建立 400+ Components
建立 200+ Variables
訂定 Design System 維護規則書
建立系統導入指南
整體設計與開發流程效率提升 約 4 倍。
團隊在未來的專案中，也能持續維持：
一致性
效率
可擴展性
協作性
持續性
(圖片：可能搞個什麼 PO、PM、工程、UI 四方一起取得共識合作的圖)
(圖片： 400+ Components 和 200+ Variables 和 4 倍生產力的配圖)
🌱專案心得與反思
一開始看到那些像車禍現場一樣的設計文件時，我的第一反應其實是：
「這要怎麼救？」
但隨著設計系統一步一步建立起來，我開始看到整個產品 UI 慢慢變得有秩序、有邏輯，尤其在後續測試中，團隊在建立新頁面時的速度明顯提升，讓我感到非常有成就感。
這個專案也讓我重新理解一件事：
UI 好看只是基本功。
真正困難的，是如何設計一個可以支撐 上百甚至上千頁面 的設計系統，讓元件能被：
重複使用
清楚管理
持續優化
而這也是我在這個專案中最大的收穫。
(圖片： Mockup)
🌱專案心得與反思
一開始看到那些像車禍現場一樣的設計文件時，我的第一反應其實是：
「這要怎麼救？」
但隨著設計系統一步一步建立起來，我開始看到整個產品 UI 慢慢變得有秩序、有邏輯，尤其在後續測試中，團隊在建立新頁面時的速度明顯提升，讓我感到非常有成就感。
這個專案也讓我重新理解一件事：
UI 好看只是基本功。
真正困難的，是如何設計一個可以支撐 上百甚至上千頁面 的設計系統，讓元件能被：
重複使用
清楚管理
持續優化
而這也是我在這個專案中最大的收穫。
(圖片： Mockup)
