「ArgusHack ─ Design System v2」專案封面

Design System

Design Token

視覺翻新

元件標準化

ArgusHack ─ Design System v2

專案期間

約 9 個月(2025 Q3 - 2026 Q1,與其他專案並行推進)

開發方式

敏捷開發

服務公司

盧氪賽忒(Leukocyte-Lab )

擔任角色

UI/UX 設計師

負責任務

痛點收集與歸納、Design Token 規劃、Wireframe、Mockup、重新設計元件、調整資訊層級

使用工具

Figma、Notion、Token Studio

背景與問題

Background

Design System v1 設計之初,產品功能相對單純,規範以當時的使用需求為基礎建立。
隨著商業策略調整,產品需容納的功能與資料量持續擴張,
原有規範逐漸跟不上產品的成長速度,因此啟動 v2 改版,以承接產品的現況與未來發展。

角色與產出

Teamwork

Design System v1 由我與 Design Lead 共同建置;到了 v2,我成為主要設計執行者 — 痛點收集與歸納、Token 架構重整、元件重新設計到資訊層級調整皆由我執行,Design Lead 負責收斂方向與把關。

痛點釐清

Pain Points

接到改版任務後,痛點蒐集分成三步進行:設計團隊先內部盤點 v1 的問題並確立改版目標,接著徵詢前端夥伴的意見,最後由我將所有回饋統整為三大痛點,作為 v2 的改版依據。

Step 1|設計團隊內部盤點

與 Design Lead 一起檢視 v1 的使用問題與業務回報的使用者回饋,邊記錄邊確立改版的目標與優先度。

內部討論的即時紀錄,痛點與任務規劃同步成形

Step 2|蒐集前端意見

另開一場會議聽取前端夥伴的回饋,把 Token 應用、元件維護等開發角度的困境納入改版範圍。

「ArgusHack ─ Design System v2」前端夥伴回饋的原始紀錄

前端夥伴回饋的原始紀錄

Step 3|統整為三大痛點

我把兩場討論累積的所有回饋逐一分類歸納,整理為三大痛點,並各自對應到解決方案。

視覺風格改版

Visual Direction

v1 採用 Neumorphism 風格,大量的漸層與陰影不僅讓 Figma 效能吃緊,前端實作與維護也相對費力。呼應「輕量、簡潔」的核心目標,v2 改採扁平化的視覺語言 — 以更明確的層級與色彩取代光影堆疊,同時降低設計與開發兩端的負擔。

v1 視覺

v2 視覺

設計產出

Design Deliverables

01|重組 Token 結構

Token 是設計與前端共用的樣式來源,定義了色彩、字級、間距等設計規則,也是整個 Design System 的基礎。當產品持續擴張,若 Token 結構缺乏延展性,元件重整與後續功能擴充都會變得困難,因此 v2 選擇從語意層重新規劃 Token 架構。

Before

Design Token 缺乏擴充性

初期的 token 規劃缺乏彈性,新情境出現時既有 token 難以沿用,只能不斷新增專屬 token 因應。sys 層逐漸失去語意功能、規範日益龐雜,前端的維護成本也持續累積。

After

依實際使用情境規劃語意層

不再強求每個 ref token 都建立對應的 sys 層,只在能明確定義使用情境的樣式上建立語意規範,其餘保留彈性直接取用 ref。每個 sys token 完整對應 ref 來源,並附上適用情境的說明,讓前端在套用時有明確依據。

02|重整資訊層級

資安演練的執行紀錄無法刪減,任何一筆都可能成為後續追查的依據。因此,這一階段著重於規劃資料的呈現順序與時機,協助使用者在龐大的資訊中快速找到需要的內容。

Before

資訊密集,重點難以浮現

重要資訊無法在初始畫面完整呈現,多數元件設計過大、層級不明確,需不斷下滑才能瀏覽所需內容;細節則以 Popup 一次呈現大量資訊,開啟時遮擋主畫面、中斷操作。

After

重整資訊層級,聚焦關鍵內容

依實際使用者回饋調整資訊層級,外層僅保留最重要的資訊,其餘細節收折至細節區。同時以側邊欄取代 Popup,讓使用者查看細節時不遮擋主畫面,操作也不會被中斷。

03|重新設計元件

v1 為了配合當時的視覺風格,設計了不少特殊樣式;然而隨著產品策略改變、資訊量持續增加,既有元件逐漸難以應對新的需求,只能不斷新增變體來補足情境。元件因此越長越多、職責也越來越模糊,因此這一階段重新定義元件邊界,統一規格與使用情境,讓元件重新回到可預期、可復用的狀態。

Before

單一用途元件不斷增生

同類元件在不同頁面各自演化,尺寸與樣式缺乏一致標準,新情境出現時經常直接複製調整,導致元件庫持續膨脹、實作時也難以判斷該套用哪一個。

After

重新定義元件規格與使用情境

依使用情境重新定義元件規格,統一尺寸、樣式、狀態與色彩規範。相同用途的元件收斂為同一組,設計與前端有單一依據,新頁面可直接復用。

Before

常用功能散落,需頻繁跳轉

系統資源、點數與使用者資訊分別散落在 Dashboard 與設定頁,這些功能的實際使用頻率遠高於當初預期,使用者常需中斷操作、跳轉至特定頁面才能查看。置於左側的 Nav Bar 也壓縮了主畫面空間,四個主頁僅以 icon 呈現,不易判斷用途。

After

常用功能整合至 Nav Bar

將三項高使用率的資訊整合至 Nav Bar,使用者不需再跳離當下頁面。Nav Bar 一併從左側移至上方,釋出主畫面空間並降低視覺干擾;四個主頁改以直觀按鈕呈現,不需 hover 即能判斷用途。

部分頁面展示

Page Display

「ArgusHack ─ Design System v2」部分頁面展示設計畫面「ArgusHack ─ Design System v2」部分頁面展示設計畫面「ArgusHack ─ Design System v2」部分頁面展示設計畫面「ArgusHack ─ Design System v2」部分頁面展示設計畫面「ArgusHack ─ Design System v2」部分頁面展示設計畫面「ArgusHack ─ Design System v2」部分頁面展示設計畫面

*本案例內容已取得前公司同意公開,部分細節未於此處呈現,歡迎於面談時進一步交流。

成果

Results

從混亂到可延伸,重建設計系統的底層基礎

v2 重整了資訊層級與規範結構,讓產品操作更直覺、設計更易於延伸維護。專案推進至開發與 QA 階段後,陸續收到產品團隊與客戶的正向回饋,
後續因公司營運調整暫停推進,尚未正式上線。

「ArgusHack ─ Design System v2」從混亂到可延伸,重建設計系統的底層基礎設計畫面

學習與反思

Takeaways

在有限條件下做出周全的決策

資安產品的客戶對資料蒐集格外敏感,難以透過埋設追蹤取得使用者數據。而 v2 最關鍵的判斷,正是重新決定「哪些資訊才是重要的」— 在沒有數據佐證的情況下,只能倚賴領域知識與跨團隊的交叉驗證來收斂。這讓我學會在資訊有限時,仍要把判斷的依據攤開來討論,而不是憑直覺定案。

在完整與務實之間找到平衡

第一次主導 Design System 的系統性規劃,讓我學會不為了系統的完整性而過度設計 — 例如 Token 架構只為能明確定義情境的樣式建立語意層,而非強求每個 token 都有對應規範。這個取捨讓系統更輕量,也更容易維護。

回頂端