富邦設計系統

數位金融,從設計系統開始

執行時間

2025.02 - 2025.11

專案類型

Design System

專案角色

UI Designer

負責項目

UI 元件定義&製作、建立Token、Variable、元件使用說明書

專案背景&目標

背景現況

富邦目前舊版的設計系統在各子公司內部不同角色的使用上皆有反映「難以滿足實務需求」的問題,並且由於目前設計系統「未符合無障礙設計,缺乏跨裝置、深色模式相關的完整規範」,因此希望委託我們對設計系統進行全面的優化以及升級。

專案目標

解決不同角色使用上的核心痛點,建構一套可擴充、易維護、具實用性且符合無障礙設計標準的設計系統,同時,也一併將跨裝置、深色模式的規範加入到設計系統當中。

專案限制

舊版設計系統目前已廣泛應用在各子公司的介面中,因此在調整時,需要兼顧新舊版本間的落差,確保各子公司專案皆能平穩的轉換至新系統。

專案成果&效益

成功取得後續專案合作

客戶對海棠信任度提升

現況釐清

焦點團體訪談

為了了解各子公司內部不同角色在既有設計系統中的使用經驗與痛點,我們邀請主要使用者角色(PM、FE、Designer),進行半開放式的焦點團體訪談,並且將訪談結果進行統整歸納,作為我們後續設計系統優化的依據。

以下為我們經過統整歸納後,不同角色對於設計系統的關注點與核心痛點:

Project Manager

關注:設計系統能否提升跨部門溝通協作效率

目前設計系統規範不夠完整,導致在開發過程中常需要反覆進行確認,造成跨部門溝通協作的效率下降。

UIUX Designer

關注:設計系統能否達成視覺一致性與系統化管理

目前色彩、間距、圓角等等基礎樣式只有設定數值,導致設計決策過於主觀,造成不同頁面間的視覺不一致,難以維持一致性。

目前元件結構難以應付不同業態與複雜應用場景,導致經常出現客製化的組件。

元件尺寸間距、互動方式等等的細節規範缺乏定義,導致設計與開發實作之間存在落差。

Front Engineer

關注:設計系統能否提升開發以及維護的效率

設計系統缺乏可直接引用的程式碼範例以及使用說明,導致需額外進行開發,不僅增加負擔,也提高了後續維護的難度。

設計端與程式端命名方式不一致,難以直接透過 CSS/Token 對應,造成後續維護成本高。

Project Manager

關注:設計系統能否提升跨部門溝通協作效率

目前設計系統規範不夠完整,導致在開發過程中常需要反覆進行確認,造成跨部門溝通協作的效率下降。

UIUX Designer

關注:設計系統能否達成視覺一致性與系統化管理

目前色彩、間距、圓角等等基礎樣式只有設定數值,導致設計決策過於主觀,造成不同頁面間的視覺不一致,難以維持一致性。

目前元件結構難以應付不同業態與複雜應用場景,導致經常出現客製化的組件。

元件尺寸間距、互動方式等等的細節規範缺乏定義,導致設計與開發實作之間存在落差。

Front Engineer

關注:設計系統能否提升開發以及維護的效率

設計系統缺乏可直接引用的程式碼範例以及使用說明,導致需額外進行開發,不僅增加負擔,也提高了後續維護的難度。

設計端與程式端命名方式不一致,難以直接透過 CSS/Token 對應,造成後續維護成本高。

接下來接下來
接下來接下來
接下來接下來
來看我們如何解決來看我們如何解決
來看我們如何解決來看我們如何解決
來看我們如何解決來看我們如何解決

導入 Design Token,建立更明確的使用定義與規範

為了讓設計師在設定色彩、間距等等基礎樣式時能有明確的依據,並且讓設計端與程式端命名方式能夠一致,我們導入了 Design Token 架構來建立更明確的使用定義與規範,而此架構一共分為以下三個層級:

• 基礎層 (Primitive Tokens): 定義最原始的客觀數值
• 語意層 (Semantic Tokens): 賦予數值明確的使用情境與意圖
• 元件層 (Component Tokens): 針對元件綁定的專屬變數

首先,以色彩系統為範例,我們從最底層的基礎值著手,針對每種色彩擴充出 9 個色階,並且將色彩做了基礎層的命名(範例:color-brand-blue-500)。確保介面在不同狀態變化下皆有一致的視覺回饋,也為深色模式的對應預留了彈性空間。

接著,進入到語意層,我們在語意層採用 CTI 從大到小的命名方式,從「什麼性質」,到「用在哪裡」,再定義「什麼情況下」使用,來讓設計師在使用上能更直覺地透過名稱對應到實際的介面情境。(範例:color-bg-surface-primary)

最後則是元件層,我們使用 Functional Approach 從使用情境出發的命名方式,將元件名稱放在最前面,讓同一個元件的所有屬性統一收納在一個資料夾內,管理上更加方便,並且同時也讓工程師以及設計師一眼就能辨識這個值屬於哪個元件。(範例:button-color-bg-primary-default)

額外補充:除了色彩以外,我們也將 Design Token 架構運用至間距、圓角、字級等基礎樣式。

打造彈性可控的模組化元件,應對複雜的應用情境

以真實回饋為基礎,為各元件設定變體與控制項

為了解決「目前元件結構難以應付不同業態與複雜應用場景的問題」,在開始重構元件前,我們主動蒐集了各子公司設計團隊的在使用上的痛點與回饋。透過這些真實回饋,來幫助我們能更精準地為各個元件設定符合需求的變體與控制項。

接著,我們利用 Figma Variants 與 Properties 的功能來建立元件的變體與控制項, 讓設計師能透過簡易的參數切換,就能快速組裝出符合需求的介面。並且針對像是 Menu、Dialog、Drawer 這種複合式元件,我們以巢狀結構為基礎,導入 Slot 的機制讓元件能夠靈活組合運用,藉此來避免產生客製化組件,提升設計系統的擴充彈性與維護效率。

額外補充:在重構元件時,我們也一併考量到新舊版本間的落差幅度來進行元件的架構調整,並且同時也針對跨裝置設定相對應的應用尺寸。

元件實際使用展示

清楚定義元件細節規範,消除設計與開發間的落差

在元件建立完成後,我們會產出元件使用說明,清楚定義各個元件的細節規範,包含元件類型、使用規則、應用情境、組成元素、尺寸與間距、注意事項以及互動模式等等。這些細節項目不僅能協助設計師在不同情境下正確應用元件,也能讓工程師在實作過程中有明確的依循標準,進而消除設計與開發間的落差。

提供完整程式碼以及範例,提升開發與維護的效率

在頁面的底部也提供可複製的完整程式碼,包含範例、引入方式、HTML 結構、CSS 樣式、API 規格 等等提供給工程師,讓他們只需載入套件就能直接使用元件。而未來如果有進行調整更動,也僅需更新套件內的模組,即可連動更新至所有應用場景。

我們除了優化以外我們除了優化以外
我們除了優化以外我們除了優化以外
我們除了優化以外我們除了優化以外
也為跨裝置、深色模式制定規範也為跨裝置、深色模式制定規範
也為跨裝置、深色模式制定規範也為跨裝置、深色模式制定規範
也為跨裝置、深色模式制定規範也為跨裝置、深色模式制定規範

建立網格與佈局的規則,維持跨裝置間一致的視覺比例

因應跨裝置的規範需求,我們也建立了網格與佈局的響應式規則,並且透過網格與佈局之間的緊密連動,來維持跨裝置間一致的視覺比例。

訂定深色模式對應規則,確保深淺模式的一致性

針對深色模式,我們訂定了色彩對應規則。以 50 – 800 的色彩數值範圍為基準,取用跨模式反向對應的色彩數值。如:深色模式 blue800 對應 淺色模式 blue50 的規則,為色彩奠定清楚的轉換邏輯。

額外補充:我們也將深淺模式的色彩進行背景搭配文字對比度的測試,來確保色彩符合 WCAG-AA 無障礙規範標準。此外,色彩對應規則也同樣應用在輔助色、中性色以及狀態色中。

深色模式實際使用展示

設計系統展示

專案總結|未來有高度合作意願 🎉

雖然目前專案尚未完全收尾,但在過程中,客戶已多次於會議中對此設計系統表達高度肯定,特別讚賞我們在規劃邏輯、視覺一致性與跨平台適配上的細緻考量。不僅提升了專案合作的信任感,也讓客戶主動表示未來若有設計或外包需求,將優先考慮與海棠進一步合作。這對團隊而言,不只是專案進展的成果回饋,更是建立長期合作關係的重要契機。