top of page
Project Cover.png

LightSketch 設計系統

建立產品一致性,提升跨部門協作效率

  • 重新定義產品色彩與 UI 元件規範

  • 依據 Atomic Design 原則建構設計系統架構

  • 強化設計與工程團隊間的溝通與交付流程

專案時間

2023.10 - 2024.12
(1年3個月)

擔任角色

產品設計師

負責項目

定義產品顏色、
元件設計與規範定義、
跨部門協作與溝通

專案概覽

01 | 目標

由於現有產品的元件風格不一致,為提升整體介面一致性與團隊協作效率,我們決定導入設計系統,並建立一套可重複使用的 UI 元件。讓工程團隊能將更多時間投入在核心的邏輯開發,而非重複處理樣式問題。

03 | 挑戰

身為公司內部唯一的產品設計師,我需同時支援新功能的設計與設計系統的建置,時間與資源分配是一大挑戰。

02 | 角色與產出

在本專案中,我作為產品設計師,與工程團隊及產品經理密切合作,負責將設計系統的概念導入至整個團隊。我的工作涵蓋從產品色彩定義、UI 元件視覺與互動設計、元件設計與測試,到交付開發與後續版本優化管理等流程。

04 | 成果與影響

我在設計新功能的過程中同步導入設計系統,並與工程團隊協作使用 Tailwind CSS,成功降低元件開發與維護時間,同時提升設計與程式的整合效率。

專案背景

LightSketch 是由德國慕尼黑的燈具製造商 Ambright 所開發的線上繪圖工具,主要提供給工業設計師使用。Ambright 擁有獨特的「Printed Light」技術,能夠製作出個人化的燈具設計,而 LightSketch 正是這項技術的應用入口。

透過 LightSketch,設計師可以在網頁工具中繪製出他們想要的燈具輪廓,系統會即時提供估價,並自動將設計需求傳送至 Ambright 的內部系統,由相關團隊聯繫客戶並安排後續製造流程。

設計師設計燈具
設計師在LightSketch上畫燈具的形狀
Ambright 用機器製作出個人化燈具形狀

了解問題與痛點

透過與工程與產品團隊討論後了解公司內部與產品當前痛點

產品當前問題

1. 同樣元件、不同樣式

目前產品雖已有完整的功能框架,但因早期缺乏產品設計師介入,UI 元件未建立明確的設計規範,導致整體風格不一致,影響用戶體驗與開發效率。

顏色不一致

以 CTA 按鈕為例,雖都採用黃色背景搭配白色文字,但由於缺乏固定色碼,有些按鈕之間出現細微色差,降低整體視覺一致性。

元件樣式不一致

同一層級的按鈕卻使用不同的顏色、陰影與邊框樣式,不僅容易讓使用者誤判功能的重要性,還增加了工程團隊的維護與重構成本。

2. 元件可讀性與易用性不足

部分元件在視覺表現上缺乏狀態區隔與清晰的操作指引,導致使用者混淆或操作錯誤。

狀態不明確

例如工具列中的按鈕,當時Enabled 與 Disabled 狀態在視覺上容易使用戶搞混。

對比度不足,影響易讀性

有些許元件未符合WCAG 2.1 AA級的顏色對比要求。例如,CTA按鈕黃底白字的對比度,影響視覺可讀性與無障礙體驗。

舊有產品介面:元件有風格不一致與顏色對比度不足的問題。例如,右上角上面的工具列按鈕互動不直覺風格也不ㄧ致,右下角的CTA按鈕顏色對比度也不足。

團隊當前痛點

1. 資源有限,時間壓力大

工程團隊在有限人力與時間下,需同時負責前端介面建置與後端複雜邏輯開發。由於缺乏明確的設計參考與支援,無法投入足夠時間優化介面細節,導致 UI 品質參差不齊。

2. 元件無法重複使用,重工頻繁

因為當時尚未導入設計系統,每當開發新功能時,工程師往往需從頭建立 UI 元件。這不僅造成元件樣式重複、難以維護,也導致整體風格與行為不一致,進一步拉長開發與測試時間。

規劃與方向

短期目標

1. 優先製作 MVP 元件

考量到團隊人力資源有限,我們決定以「支援新功能開發」為優先,並從即將用到的核心 UI 元件開始建立設計系統,例如:按鈕、Header、工具列(Toolbar)等。

在實際製作元件前,我先重新定義產品整體的視覺風格與色彩規範。雖然公司已有初步的品牌風格設定,但產品界面與公司網站的風格並不一致,因此首要任務是統一產品中的色彩與字體系統。

現有公司網站頁面
現有公司網站頁面
修化後的產品介面
修化後的產品介面

2. 選擇技術:Tailwind CSS 與 Three.js

為了建立可重複使用、具彈性且開發快速的元件,我們選擇以 Tailwind CSS 作為 UI 樣式的基礎。Tailwind 提供了系統化的 CSS 工具類別(utility-first approach),讓我們可以快速客製並套用一致的樣式規範。

同時,為了支援產品中 2D 與 3D 視覺需求,我們也採用 Three.js 進行圖形渲染,與 UI 元件整合使用。

長期目標

1. 設計系統檔案管理架構

我們採用 Atomic Design 的概念來建立 Figma 設計系統檔案,依據元件的複雜程度分為四大類別,從基礎設計元素到完整功能模組,提升元件的可維護性與擴充性。

圖的內容從左至右為4種Figma檔案分類:基礎層(例如:顏色)、UI元件(例如:按鈕)、複合元件與產品功能頁面。
Figma 檔案分類架構
  1. 基礎層 (Foundation):
    包含 Design Tokens,例如色彩、字體、間距、尺寸與陰影,是系統風格的基礎。
     

  2. UI元件 (Components):
    由基礎層組成的原子元件,例如按鈕、輸入框、下拉選單與複選框等。
     

  3. 複合元件 (Patterns):
    由多個 UI 元件組成的結構,例如 Dialog、Toolbar、Header 等,具備明確互動邏輯與狀態變化。
     

  4. 功能頁面 (Features):
    結合多個元件與模式,用於特定功能場景,例如「使用者教學流程」。

2. 元件版本管理

設計系統導入後,我們也建立了版本管理流程,便於團隊追蹤每個元件樣式的修改歷程,並確保設計與開發之間的一致性。

圖的左邊為按鈕檔案內的版本管理方式,右邊呈現版本紀錄樣式變更的內容。
元件版本紀錄與樣式變更歷程

每當元件樣式或邏輯有變更時,都會在 Figma 中記錄對應版本與修改說明,方便日後查閱與團隊溝通,也支援後續的設計審查與版本控制策略。

設計產出

設計原則

為了提升產品整體一致性、建立便於維護與擴充的設計系統,同時強化設計與工程團隊的協作效率,我以下面三項設計原則做為此產品設計系統的核心理念:

1. 保持產品風格一致

整個產品以樂高邏輯的方式規劃整體產品架構,從最小單位的 Design Tokens(色彩、字體、間距等)出發,逐步組合為一致性的 UI 元件,進而延伸至頁面與功能模組。

左側為選擇燈箱種類的視窗:此視窗從許多元件所組成,而每個元件由Design Tokens所組成。

考量到產品中有許多客製化圖示無法直接套用現成圖庫,為維持整體視覺一致性,我設計了一套符合產品風格的 icon 系列。

客製化圖示以符合整體產品風格,例如工具列內的工具種類、3D視、燈具掉立方式與繪圖工具的圖示。

2. 易於維護與擴充

設計系統的結構參考 Atomic Design 架構,讓元件從基礎到複雜組合皆具可拆解性與重用性。同時,我導入元件版本管理與命名規則,確保每次更新都可被有效追蹤,並支援未來元件擴充或調整樣式的需求。

3. 強化設計與工程團隊合作效率

透過建立設計規範一致、結構清晰的 Figma Variants,我協助工程團隊更快速理解元件狀態與互動邏輯。所有元件皆搭配實際使用情境、狀態(如 default、hover、disabled)與命名規則,有效縮短設計與開發的溝通時間。

CTA按鈕元件在Figma上的Propertie設定
此為CTA按鈕元件在Figma上的Propertie設定:背景顏色種類、尺寸大小、按鈕狀態、按鈕內容。

設計結果

1. 從顏色與字體系統著手

考量到公司已初步確立品牌風格,加上專案時間有限,我優先在現有色彩基礎上進行優化,特別針對 對比度不足的問題進行調整,確保整體符合 WCAG 2.1 的無障礙設計標準。

色彩系統共劃分為 8 種核心色彩,涵蓋品牌主色與介面指示色,兼顧產品視覺風格與功能性:

設計系統的色彩總覽圖表,包含中性色、品牌色與功能提示色,每色階均顯示對比數值與色碼。
品牌色
  • 米色(Primary):

    核心品牌色,用於主要操作,建立一致的視覺印象
     

  • 黃色(Secondary):

    用於高亮區塊或次要操作提示,例如燈的放置位置
     

  • 紫色(Tertiary):

    用於輔助強調與操作控制,避免過度單一

中性色
  • 灰階色:
    用於背景、邊框、文字等基礎介面結構

功能色
  • 紅色(Danger):
    用於錯誤提示、危險操作警示
     

  • 橘色(Warning):
    表示潛在風險或提醒
     

  • 綠色(Success):
    表示操作成功或完成狀態
     

  • 藍色(Info):
    用於資訊提示與協助說明內容

選擇燈箱種類視窗
彈出視窗選單介面,展示使用者選擇不同形狀的燈具懸吊結構,每個�選項以圖片與文字說明標示。

產品主色 (米色)

用於按鈕與互動框選,提升辨識度並保持品牌一致性。

繪製的燈具形狀與放置燈的位置
設計畫布中呈現使用者繪製的燈具形狀與放置點。

次要色 (黃色)

在 2D 繪圖畫面中標示燈具的軌道與位置點,方便辨識。

​放置燈箱位置
燈箱呈現焦點狀態的效果。

警告 (橘色) 與錯誤色 (紅色)

  • 錯誤色表示無法製造的設計錯誤,例如超出製造限制的形狀。

  • 警告色則代表可疑但仍有彈性的設計情況,建議使用者可與公司進一步聯繫確認是否可行。

成功確認視窗
提交訂單成功的確認彈窗,包含訂單號碼與回饋訊息,按鈕採用綠色成功提示色。

成功色 (綠色)

在任務成功提交後使用綠色確認提示,提供正向回饋。

字體種類
產品所使用的所有字體種類(7 種字體大小)

字體選擇方面,我沿用公司既有品牌所使用的字體,以維持整體風格一致性。在此基礎上,我根據產品常見的資訊層級,初步定義了 7 種字體大小,建立清晰的階層結構與應用規範。

  • 標題(Heading):
    使用 36px、24px、18px 三種尺寸,依層級與情境調整,皆搭配粗體(Bold)呈現
     

  • 副標題(Subheading):
    使用 16px 與 14px,區分段落與模組內標題,同樣使用粗體以強化層級感
     

  • 內文(Body Text):
    主要為 14px,一致採用 Regular 款式,提升閱讀舒適度與系統一致性
     

  • 輔助與註解文字(Caption / Notes):
    使用 12px 與 10px,應用於次要訊息或輔助說明,避免搶眼但仍具可讀性

2. UI元件與產品頁面

元件設定視窗 (Object Settings Dialog)

針對產品中大量重複出現的設定視窗,我將其視覺風格模組化,並透過 Component Tokens 建立可統一控制的設計規則。

所有視窗都套用相同的 tokens,例如:圓角、陰影、邊框、欄位間距等,若未來需調整樣式(如提升圓角大小或優化陰影),只需修改 tokens 即可全域更新,無須逐一調整每個元件,大幅提升維護效率與系統一致性。

2D 繪圖頁面中的燈具設定視窗,與右側兩個元件設定面板,展示統一設計風格與輸入結構。
左側為上視圖模式,右側為 3D 模式,皆展示相同燈具設定視窗,強調元件跨模式使用的一致性。
步驟條元件 (Stepper Component)

由於本產品功能相對複雜,為了讓第一次使用的用戶更快上手,我設計了 Onboarding 流程,並透過步驟條元件(Stepper)逐步引導用戶完成操作。步驟分為三大階段,對應產品的使用邏輯與學習曲線。

此外,在「設計提交流程」中,由於需填寫多項個人與公司資訊,我同樣使用相同的步驟條元件協助用戶拆解表單流程,避免資訊過載,提升整體體驗。

這兩個場景雖然功能不同,但皆共用同一組 Stepper 元件,實現設計重用與一致的引導體驗。

左圖為 Onboarding 引導介面,右圖為設計提交表單,兩者皆使用相同的步驟條元件進行流程引導。

專案成果

在約一年左右,我建立了產品的基礎設計系統,從顏色與字體規範到UI元件庫,逐步推動設計系統導入並實際應用於新功能開發中。這套系統不僅提升設計與開發的一致性,也改善了團隊協作效率與後續維護成本。

  • 提升產品整體一致性:
    統一元件風格與品牌視覺語言,強化用戶體驗與品牌形象
     

  • 建立可重複使用的元件庫:
    透過設計系統元件化,提高設計與工程團隊的開發效率與維護彈性
     

  • 優化團隊合作流程:
    設計系統作為設計與工程溝通的橋梁,降低反覆修正與溝通成本

反思與學習

縮小設計與工程團隊間的隔閡

這次設計系統的導入讓我深刻體會到設計與工程的溝通並非只是交付畫面,而是需要從早期就建立共同語言與開發思維。透過與工程師一同制定元件邏輯、命名方式與使用情境,我學會如何以工程的角度拆解設計,讓元件更易於實作與維護,也讓設計討論更加具體且可實現。

元件需保有足夠彈性

由於同時支援新功能的設計,元件設計需具備彈性,以因應不同模組的需求與變化。我學到,設計系統中的元件不能過度固定,而應在「一致性」與「靈活性」之間取得平衡。透過設計 Variants 與 Tokens 的方式,元件能夠隨情境切換樣式與狀態,在提升可維護性的同時,也保留實用上的彈性與延展性。

設計系統是漸進式的過程

設計系統不是一次性建完的結果,而是持續演進、調整與對齊的過程。這次專案中,我在推動設計系統的同時也需支援新功能設計,因此我採取「從新功能導入,逐步向下擴展」的策略,避免試圖一次性改造所有頁面。這種「設計中導入設計系統」的方式,讓整體過程更符合團隊節奏,也降低了導入阻力。

網格

​其他專案

Cover.png

2023.04 - 2023.06

SleepWell Track:
​病患治療資料

​符合地區性需求:設計屬於當地治療師日常使用流程

用戶訪談 | 使用者體驗 | 介面設計

bottom of page