內部產品與協作團隊
產品、設計、開發與相關團隊需要用同一套結構討論需求、組合功能並維持體驗一致。
Enterprise AI · Product Design · Design System
將企業 AI 能力，
將企業 AI 能力，
轉化為容易理解、操作並持續擴充的平台體驗。
這是一項企業 AI 平台產品設計專案。團隊需要將基礎設施、模型能力與多種 AI 應用，整理成清楚、一致且能持續擴充的產品入口。
My contribution我主導平台視覺方向、資訊版型與 Design System，並透過互動原型、瀏覽器原型與開發協作，讓設計決策能進入實際產品。
Enterprise AI workspace
PLATFORM EXPERIENCETurn complex technology into clear product experiences.
SYSTEM FOUNDATIONReady to scale
AI WorkspaceShared entry point
Reusable PatternsConsistent states
Product ModulesFlexible expansion
Public reconstruction — 本畫面由公開版內容重新製作，不代表實際產品介面。
公開說明
本案例受保密協議限制，專案名稱、產品介面、功能細節與商業資訊均已省略或重新製作。本頁聚焦於我的角色、設計方法與可轉移的產品設計能力，不代表實際產品畫面。
01 · Context & Challenge
從抽象技術能力，轉向企業能理解與使用的產品體驗。
企業 AI 解決方案通常從基礎設施與模型能力出發，但技術規格本身很難讓非技術使用者理解：平台可以支援哪些工作、該從哪裡開始，以及不同能力之間有什麼關係。
團隊因此需要一個一致的產品入口，將分散的 AI 能力整理成可探索、可操作的平台體驗，同時保留未來增加產品模組與使用情境的彈性。
如何將複雜的 AI 技術，轉化為企業使用者能理解、能操作，也能持續擴充的產品？
企業使用者
使用者需要透過統一入口理解平台能力、找到適合的功能，並在不同 AI 任務之間維持一致的操作預期。
Problem Framework
問題不只是缺少介面，而是缺少一套將 AI 能力產品化的平台基礎。
平台需要同時處理資訊理解、體驗一致、未來擴充，以及設計與開發實作之間的落差。
技術能力難以被快速理解
基礎設施、模型與應用位於不同層級，需要轉譯成清楚的產品架構與使用情境。
不同 AI 功能缺乏一致體驗
當功能由不同團隊發展時，資訊層級、元件狀態與操作模式容易產生差異。
缺少可重複使用的設計基礎
每次新增功能都從零開始，增加溝通與製作成本，也難以維持品質。
設計與實作之間存在落差
版面、Responsive 與元件狀態在轉換後容易改變，需要更清楚的交付與檢查方式。
02 · My Role & Constraints
我的工作不只停留在介面設計，而是串連產品呈現、系統規範與實際開發。
我主導產品視覺、頁面架構與設計系統，並和 PM、RD 討論不同功能適合的資訊與互動方式；產品優先順序與技術方案則由團隊共同確認。
我主導的範圍
- 產品視覺方向與介面風格
- 頁面版型與資訊層級
- Design System 與元件規範
- Figma 互動 Prototype
- HTML/CSS Prototype 與樣式檢查
共同參與與非負責範圍
- 與 PM 討論功能與元件呈現
- 與 RD 對齊產品實作方式
- 需求與功能優先順序由 PM 決定
- 技術架構與商業策略不在我的負責範圍
Project Constraints
讓限制成為判斷設計成果的必要背景。
- NDA 限制可公開的產品畫面與商業資訊
- 第一階段尚未建立正式 User Research 與 Design QA
- 缺少可直接歸因於設計的產品與銷售數據
- 設計元件與前端元件尚未建立完整對照與版本治理
03 · Key Design Decisions
每個決策都回應一項限制，也代表一次取捨。
01
單次功能頁 vs. 可擴充平台
情境與取捨：單次功能頁能更快完成，但每增加一項 AI 能力都需要重新設計；平台架構的前期成本較高，卻能支援長期擴充。
Decision & impact
選擇平台架構，將導覽、應用卡片、資訊區塊與操作模組拆成可重複組合的基礎。
02
完全統一介面 vs. 保留應用彈性
情境與取捨：完全統一能降低維護成本，卻可能限制不同 AI 任務；完全客製則會再次造成體驗分散與重複製作。
Decision & impact
統一導覽、視覺與共用狀態，個別 AI 功能則依任務需求組合內容與互動模組。
03
靜態 Figma 交付 vs. 瀏覽器原型協作
情境與取捨：只交付 Figma 較省時間，但 Responsive、互動與樣式細節容易在產品實作後產生落差。
Decision & impact
增加 HTML Prototype 與 Git Review，讓 PM、RD 在開發前後都能確認實際瀏覽器行為。
04 · Design Evidence
以資訊架構、元件策略與原型協作，逐步收斂平台體驗。
釐清
整理技術能力、產品模組與平台的關係，和 PM 確認需求與呈現目標。
架構
規劃資訊層級、頁面版型，以及功能與共用元件的關係。
提案
透過 Wireframe、視覺方案與 Figma Prototype 比較不同方向。
實作
製作瀏覽器原型、進入開發協作，並持續檢查與修正實作差異。
CAPABILITY 01 · INFORMATION ARCHITECTURE
建立能被理解的平台層級
公開版以重製示意呈現思考方式，不使用實際產品結構、名稱或畫面。
PROBLEM
技術、產品與任務資訊混在同一層級，使用者難以建立清楚心智模型。
APPROACH
先區分平台入口、產品模組與任務內容，再決定導覽與內容優先順序。
TRANSFERABLE VALUE
以清楚架構降低理解成本，也為後續功能擴充預留穩定位置。
05 · Component Strategy
在一致性與任務彈性之間，建立可重複使用的元件策略。
我將跨功能共用的結構與狀態整理成設計基礎；個別 AI 任務則保留適度彈性，避免一致性變成限制產品發展的框架。
CAPABILITY 02 · COMPONENT STRATEGY
從共用規則到可擴充的產品模組
公開版只呈現系統化方法，不揭露實際元件、Design Tokens、功能狀態或內部規範。
01 / Foundation
共同基礎
建立一致的視覺語言與版面節奏。
02 / Shared Patterns
共用模式
整理跨產品模組可重複使用的結構。
03 / States
狀態設計
讓不同任務維持可預期的回饋邏輯。
04 / Flexibility
擴充彈性
保留個別情境所需的內容與互動差異。
Design to Development
讓設計不只停在 Figma，而是持續參與產品實作。
設計方向確認後，我以瀏覽器原型補充 Responsive 與互動細節，並在開發過程中持續檢查實作，縮小設計稿與產品之間的差異。
01Requirement產品需求
02UX / UI體驗與介面
03Prototype互動確認
04Browser Demo行為驗證
05Development產品實作
06Review差異檢查
07Iterate持續調整
CAPABILITY 03 · DESIGN TO DEVELOPMENT
以原型與實作檢查縮小交付落差
公開版呈現協作方法，不揭露程式碼、專案架構、內部流程或實際產品畫面。
06 · Outcome
成果不只是一組介面，而是一個能支援團隊協作與後續擴充的產品基礎。
受 NDA 與量化資料限制，這裡不公開採用數字或商業成果，而以可確認的產品基礎、系統方法與團隊影響說明設計價值。
建立一致的平台體驗基礎
將分散的技術與產品能力整理成可理解、可操作的共同入口。
支援後續 AI 功能持續加入
透過可重複使用的結構與共用模式，降低新增功能時從零開始的成本。
改善設計與開發溝通
以 Prototype、實作檢查與持續 Review，讓團隊更早對齊產品行為與品質。
把複雜技術轉成可理解體驗
以資訊架構與一致互動降低理解成本，讓技術能力能透過產品被使用者感知。
07 · Reflection
從建立平台基礎，走向可被驗證與共同維護的產品系統。
第一階段的重點，是先建立清楚、一致且能支援擴充的平台基礎。互動原型、瀏覽器原型與實作協作，讓我能持續參與從設計決策到產品呈現的過程。
但現階段的決策仍較依賴內部提案與利害關係人回饋，缺少來自實際使用者的系統化驗證；設計與開發差異，也需要更成熟的共同規範與 Design QA 流程。
建立使用者驗證
訪談業務與企業員工，觀察他們如何理解、尋找與使用 AI 功能。
補上產品數據
追蹤功能採用、任務完成、錯誤中斷與持續使用情況。
完善系統治理
建立設計元件、前端元件與版本變更之間的清楚對應。
建立 Design QA
讓設計品質由共同流程維持，而非依賴實作後個別修正。