<- Back
<- Back
<- Back

Jason Chen

Work
About
Resume
->

BenQ Services Design System

建立設計系統，提升跨團隊效率與交付品質

Duration

15個月，2023年7月至2024年9月

Team Member

三位 UX 設計師、三位 UI 設計師、三位前端工程師

Responsitivity

規劃交付文件、定義過半數元件、跨團隊溝通、建立內部元件庫

Intro

根據過去專案內 UI Kit 的成功經驗，開發團隊有意進一步規劃設計系統，逐步為 BenQ 教育解決方案的所有網頁服務（Web App）都導入設計系統。

原先的成員編制無法應付龐大的工作量，於是我加入了團隊，協助共同打造一套用途更廣、更直覺好用的設計系統。

Impact ✨

1.

受益規模橫跨 7+ 專案、20+ 設計師與整個工程團隊

2.

至今採用設計系統的 3 個專案，平均節省 30% 以上的設計與開發時間

3.

建立內部共用 Figma 元件庫

規劃流程總覽

作為擴編初期就加入團隊的一員，我有幸獲得規劃整份文件並定義過半元件的機會，以下是幾個關鍵步驟：

🔍

Investigate

Investigate

––>

⏳

Define

Define

&

&

Iterate

Iterate

––>

🧩

Update

Update

––>

🛠️

Maintain

Maintain

🔍 Investigate

我首先參考各大設計系統與工程開源文件規劃設計系統文件架構，接著盤點所有專案出現的所有元件，按使用頻率優先級排列。

⏳ (Components) Define & Iterate

為了讓討論更有效率，我會先規劃出初版元件定義，與設計與工程團隊都取得共識後，才會正式交付。過程包含大量的討論與釐清，直到大家的立場都被考慮其中。

🧩 (Components Library) Update

交付後，我會在 Figma 元件庫新增元件與相關變形（Variant），確保所有設計師都能直接匯入使用。

🛠️ Maintain

如果遇到元件定義更新，會在與三方取得共識後調整文件與元件庫。

🔍 Investigate

如何規劃一份清晰易讀的設計系統文件？

我加入團隊的第一個任務，就是重新規劃設計系統文件。相比舊版文件只需要服務單一專案內的團隊成員，新版設計系統需要讓 20 多位設計師與整個工程部門都一讀就懂。

Before

After

Before

After

Before

After

為了規劃出簡單易讀的文件，我做了以下兩件事：

從各大設計系統汲取靈感

為了符合閱讀習慣，我們決定參考 Apple、Google Material Design、Adobe Spectrum、IBM Carbon Design 等設計系統與其文件結構。為每個元件獨立成頁，並且包含組成、定義、用途建議與最佳實踐四個部分說明。

參考 Vuetify 工程開源文件

此外，為了讓工程團隊有效率的理解元件規格與變形（Variants），特別參考 Vuetify 前端套件的文件說明，補充 Table of Options 區塊。

⏳ Define & Iterate

每個元件背後，是無數次的決策與溝通

這章節我會透過兩個元件 0-1 的過程，讓大家一窺規劃過程的真實樣貌。

案例一：

q-text-field

q-text-field

q-text-field

作為基本元件，Text field 在各專案間卻有許多細微差異，間接導致工程溝通費時費力。因此 Text field 被排在最優先處理的元件之一。

#1 調研現況 → 整理不同情境 → 提出初版定義

首先，我會參考多家主流設計系統規範並盤點專案使用情境，整理初版中性定義，在 UX 內部會議導讀與討論。

在這個階段，專案間定義不一致的細節會被重點討論。以提示文字（Helper text）為例，當時內部對其顯示位置存在三種不同看法：

置於 Info icon 派

置於 Info icon 派

置於 Info icon 派

因案例的字元數較多，決定以 Tooltips 形式藏在 Icon 中

置於 Placeholder 派

置於 Placeholder 派

置於 Placeholder 派

考量提示訊息可能與錯誤訊息重疊衝突

置於輸入框下方派

置於輸入框下方派

置於輸入框下方派

適用多數情境，但是與錯誤訊息重疊衝突問題未解

在大家充分表達設計脈絡後，我彙整使用場景後判斷「字數過多」是特例，不應作為預設。根本的問題在於「如何精煉提示文字」，與錯誤訊息重疊則可以透過 Swap 交互來規避。

釐清後，「置於輸入框下方」成為內部共識。也針對特例提出字數限制建議，如果遇到特例再輔以 Info icon 或額外文字規劃顯示。

🔼 q-text-field 提示訊息與錯誤訊息交互相關的定義

#2 達成 UX 內部共識 → 跨團隊溝通 → 定版開發

接著，我們會在設計系統會議向工程團隊與 UI 設計師們溝通，順利的話會定版進開發。如果遇到工程限制或意見不一致，則會回頭與 UX 內部再度溝通，直到三方取得共識。

不同背景的夥伴時常提供嶄新的觀點或注意事項，像是後端驗證時機、預設樣式與特殊狀態下的游標屬性，都是在他們的提醒下補充定義的！

🔼 與設計系統團隊溝通 Text field icon 位置種類的我（這場很順利）

🔼 與設計系統團隊溝通 Text field icon 位置種類的我（這場很順利）

🔼 與設計系統團隊溝通 Text field icon 位置種類的我（這場很順利）

案例二：

q-side-navigation

q-side-navigation

q-side-navigation

BenQ 教育解決方案旗下的多款產品，原本擁有各自獨立的設計脈絡。隨著產品逐漸整合與設計系統的發展，我決定從 Header 與 Side NAV 著手整合。這被視為實現跨產品體驗一致性的起點。

🔼 在導入設計系統前，各服務間架構差距甚大

其中，各團隊對 Side NAV 的展現方式產生分歧：一派認為 Side NAV 應該預設收合為 Navigation Rail，另一派則認為應該像 Sidebar 固定顯示。

缺乏共識時，我們能怎麼前進？

由於兩派的設計脈絡都有理有據，因此難以透過 UX 取得共識。討論一度陷入僵局，會議無疾而終。

事後我一邊反思問題的本質，一邊私下找多位資深設計師深度討論對跨產品體驗一致性的看法，同時整理諸如 Google Workspace、Adobe Suite 等參考資料。

才終於慢慢地我意識到：

由於兩派的設計脈絡都有理有據，因此難以透過 UX 取得共識。討論一度陷入僵局，會議無疾而終。

事後我一邊反思問題的本質，一邊私下找多位資深設計師深度討論對跨產品體驗一致性的看法，同時整理諸如 Google Workspace、Adobe Suite 等參考資料。

才終於慢慢地我意識到：

「一致性不代表完全相同的樣式或行為，而是讓使用者的學習負擔最小化——使用者在 A 產品學會的操作方式與使用習慣，可以順利的套用到 B 產品。」

最終這個觀點取得大家的認可，基於這個共識，我們調整了設計系統的一致性策略：

Side NAV：

依照產品性質分為兩種類型，保留規彈性，同時統一基本邏輯、項目層級與行為。

Side NAV：

依照產品性質分為兩種類型，保留規彈性，同時統一基本邏輯、項目層級與行為。

由於兩派的設計脈絡都有理有據，因此難以透過 UX 取得共識。討論一度陷入僵局，會議無疾而終。

事後我一邊反思問題的本質，一邊私下找多位資深設計師深度討論對跨產品體驗一致性的看法，同時整理諸如 Google Workspace、Adobe Suite 等參考資料。

才終於慢慢地我意識到：

「一致性不代表完全相同的樣式或行為，而是讓使用者的學習負擔最小化——使用者在 A 產品學會的操作方式與使用習慣，可以順利的套用到 B 產品。」

最終這個觀點取得大家的認可，基於這個共識，我們調整了設計系統的一致性策略：

Side NAV：

依照產品性質分為兩種類型，保留規彈性，同時統一基本邏輯、項目層級與行為。

A. 固定展開的 Sidebar

A. 固定展開的 Sidebar

A. 固定展開的 Sidebar

強調可視性與清晰的層級結構

B. 預設收合的 Navigation Rail

B. 預設收合的 Navigation Rail

B. 預設收合的 Navigation Rail

最大化內容空間，僅在 Hover 時展開完整 Side NAV

Header：

Header：

作為全產品共用的頂部元件，則需要嚴謹定義，統一包含語言切換、帳號管理、幫助中心、設定等項目與操作行為。

作為全產品共用的頂部元件，則需要嚴謹定義，統一包含語言切換、帳號管理、幫助中心、設定等項目與操作行為。

Header：

作為全產品共用的頂部元件，則需要嚴謹定義，統一包含語言切換、帳號管理、幫助中心、設定等項目與操作行為。

至於響應式規劃，則統一規劃為漢堡選單，點擊後展開完整導航。這樣的規劃，不只讓各專案在保有設計彈性，也能讓使用者在不同服務間享有共通的操作慣性。

🔼 Header 與 Side NAV 在平板與手機斷點的交互表現

🛠️ Maintain

🛠️ Maintain

🛠️ Maintain

沒有 PM 仍能持續前進的專案

隨著越來越多的專案實踐，設計系統不時會遇到新增變體或調整定義的狀況。這時，我們會在內部的元件討論會提出，由設計系統團隊評估後，再進行上述的共識討論。為了持續追蹤開發進度，各部門會定期在 Trello 更新進度。

🔼 在沒有 PM 的情況下，團隊透過 Trello 同步彼此進度

🌟 Outcome

🌟 Outcome

🌟 Outcome

截至目前的小小里程碑 ✨

在超過一年的努力下，我們先後上架了兩輪元件、導入響應式設計與無盡的迭代，以下是我們血與淚的結晶：

#1 總共對齊 30+ 元件

從元件組成、適用時機、定義到變體，目前設計系統共有2 個完整規範的元件可供使用。其中也包含 Data Table、Header、Side NAV 等複合元件，為跨產品體驗一致性奠基扎實的基礎。

🔼 文件以每個元件單獨成頁規劃

🔼 複合元件進度表

此外，我們也以 General Rules 形式統一規範跨元件共用的通則：

🔼 以載入模式為例，General Rules 會討論跨元件的 Design Pattern 與設計建議

#2 為元件全面升級為響應式版本

趁著 AMS 規劃響應式版本之際，我們也為設計系統內的元件逐個升級為響應式版本，並利用 AMS 的 QA 環節驗證本次迭代。

🔼 Dialog 在各斷點區間的表現圖示

Extra Effort

#3 推出設計團隊共用的 Figma 元件庫

為了更順利將設計系統落地在各專案交付文件，我帶著兩位實習夥伴額外為團隊規劃了 Figma 元件庫，降低設計師的工作負荷，也讓工程團隊更易讀。

🔼 只要把 Components Library 匯入檔案就可以使用

🔼 Table of Options

🔼 q-text-area 的所有 Variants

意料之外的影響力

除了上述成果，設計系統的成效被內部 Android 系統工程部門看到，促使他們發起建立 Android 設計系統！

而團隊內的 Junior Designer 與 Intern 也反應，設計系統的元件定義有如內部共識，讓他們與工程師溝通更有說服力。

學習與反思

從設計系統的經驗，我收穫的不只是元件細節的規劃與考量，更從與團隊溝通理解 UI 與工程面的施作細節。對 UI 規劃與前端更深的理解，都讓我在跨部門溝通順利許多。

不過設計系統是一個溝通成本極高，成效又難以預料的專案。很幸運這次取得不錯的成果，但日後如何衡量「設計系統帶來的好處」與「規劃設計系統所花的心力」也是我正在學習的課題。

Next Projects

Next Projects
Next Projects

#Web App Design

BENQ (2024)

帳號管理軟體改版，優化使用者的管理體驗

View Case Study

->

Coming Soon

…

Account Management System Revamp Cover

#Web App Design

BenQ (2024)

帳號管理軟體改版，優化使用者的管理體驗

透過使用者研究與測試了解痛點，優先處理設定障礙與手機使用限制，同時為設計系統升級響應式版本。

View Case Study

->

Coming Soon

…

Account Management System Revamp Cover

#Web App Design

BenQ (2024)

帳號管理軟體改版，優化使用者的管理體驗

透過使用者研究與測試了解痛點，優先處理設定障礙與手機使用限制，同時為設計系統升級響應式版本。

View Case Study

->