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
----→
⏳
Define
&
Iterate
----→
🧩
Update
----→
🛠️
Maintain
🔍 Investigate：我首先參考各大設計系統與工程開源文件規劃設計系統文件架構，接著盤點所有專案出現的所有元件，按使用頻率優先級排列。
⏳ (Components) Define & Iterate：為了讓討論更有效率，我會先規劃出初版元件定義，與設計與工程團隊都取得共識後，才會正式交付。過程包含大量的討論與釐清，直到大家的立場都被考慮其中。
🧩 (Components Library) Update：交付後，我會在 Figma 元件庫新增元件與相關變形（Variant），確保所有設計師都能直接匯入使用。
🛠️ Maintain：如果遇到元件定義更新，會在與三方取得共識後調整文件與元件庫。
🔍 Investigate
如何規劃一份清晰易讀的設計系統文件？
我加入團隊的第一個任務，就是重新規劃設計系統文件。相比舊版文件只需要服務單一專案內的團隊成員，新版設計系統需要讓 20 多位設計師與整個工程部門都一讀就懂。
Before
After
為了規劃出簡單易讀的文件，我做了以下兩件事：
從各大設計系統汲取靈感
為了符合閱讀習慣，我們決定參考 Apple、Google Material Design、Adobe Spectrum、IBM Carbon Design 等設計系統與其文件結構。為每個元件獨立成頁，並且包含組成、定義、用途建議與最佳實踐四個部分說明。
參考 Vuetify 工程開源文件
此外，為了讓工程團隊有效率的理解元件規格與變形（Variants），特別參考 Vuetify 前端套件的文件說明，補充 Table of Options 區塊。
⏳ Define & Iterate
每個元件背後，是無數次的決策與溝通
這章節我會透過兩個元件 0-1 的過程，讓大家一窺規劃過程的真實樣貌。
案例一：
q-text-field
作為基本元件，Text field 在各專案間卻有許多細微差異，間接導致工程溝通費時費力。因此 Text field 被排在最優先處理的元件之一。
#1 調研現況 → 整理不同情境 → 提出初版定義
首先，我會參考多家主流設計系統規範並盤點專案使用情境，整理初版中性定義，在 UX 內部會議導讀與討論。
在這個階段，專案間定義不一致的細節會被重點討論。以提示文字（Helper text）為例，當時內部對其顯示位置存在三種不同看法：
置於 Info icon 派
因案例的字元數較多，決定以 Tooltips 形式藏在 Icon 中
置於 Placeholder 派
考量提示訊息可能與錯誤訊息重疊衝突
置於輸入框下方派
適用多數情境，但是與錯誤訊息重疊衝突問題未解
在大家充分表達設計脈絡後，我彙整使用場景後判斷「字數過多」是特例，不應作為預設。根本的問題在於「如何精煉提示文字」，與錯誤訊息重疊則可以透過 Swap 交互來規避。
釐清後，「置於輸入框下方」成為內部共識。也針對特例提出字數限制建議，如果遇到特例再輔以 Info icon 或額外文字規劃顯示。
🔼 q-text-field 提示訊息與錯誤訊息交互相關的定義
#2 達成 UX 內部共識 → 跨團隊溝通 → 定版開發
接著，我們會在設計系統會議向工程團隊與 UI 設計師們溝通，順利的話會定版進開發。如果遇到工程限制或意見不一致，則會回頭與 UX 內部再度溝通，直到三方取得共識。
不同背景的夥伴時常提供嶄新的觀點或注意事項，像是後端驗證時機、預設樣式與特殊狀態下的游標屬性，都是在他們的提醒下補充定義的！
🔼 與設計系統團隊溝通 Text field icon 位置種類的我（這場很順利）
案例二：
q-side-navigation
BenQ 教育解決方案旗下的多款產品，原本擁有各自獨立的設計脈絡。隨著產品逐漸整合與設計系統的發展，我決定從 Header 與 Side NAV 著手整合。這被視為實現跨產品體驗一致性的起點。
🔼 在導入設計系統前，各服務間架構差距甚大
其中，各團隊對 Side NAV 的展現方式產生分歧：一派認為 Side NAV 應該預設收合為 Navigation Rail，另一派則認為應該像 Sidebar 固定顯示。
缺乏共識時，我們能怎麼前進？
由於兩派的設計脈絡都有理有據，因此難以透過 UX 取得共識。討論一度陷入僵局，會議無疾而終。
事後我一邊反思問題的本質，一邊私下找多位資深設計師深度討論對跨產品體驗一致性的看法，同時整理諸如 Google Workspace、Adobe Suite 等參考資料。
才終於慢慢地我意識到：
「一致性不代表完全相同的樣式或行為，而是讓使用者的學習負擔最小化——使用者在 A 產品學會的操作方式與使用習慣，可以順利的套用到 B 產品。」
最終這個觀點取得大家的認可，基於這個共識，我們調整了設計系統的一致性策略：
Side NAV — 依照產品性質分為兩種類型，保留規彈性，同時統一基本邏輯、項目層級與行為。
A. 固定展開的 Sidebar
強調可視性與清晰的層級結構
B. 預設收合的 Navigation Rail
最大化內容空間，僅在 Hover 時展開完整 Side NAV
Header — 作為全產品共用的頂部元件，則需要嚴謹定義，統一包含語言切換、帳號管理、幫助中心、設定等項目與操作行為。
至於響應式規劃，則統一規劃為漢堡選單，點擊後展開完整導航。這樣的規劃，不只讓各專案在保有設計彈性，也能讓使用者在不同服務間享有共通的操作慣性。
🔼 Header 與 Side NAV 在平板與手機斷點的交互表現
🛠️ Maintain
沒有 PM 仍能持續前進的專案
隨著越來越多的專案實踐，設計系統不時會遇到新增變體或調整定義的狀況。這時，我們會在內部的元件討論會提出，由設計系統團隊評估後，再進行上述的共識討論。為了持續追蹤開發進度，各部門會定期在 Trello 更新進度。
🔼 在沒有 PM 的情況下，團隊透過 Trello 同步彼此進度
🌟 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
