以規格驅動開發 Prototype 定義 AI 設計工作流

專案背景

這是一間大型證券公司的業務 CRM 系統，服務對象橫跨業務員、研究員等多種角色。首頁儀錶板、客戶查詢、行銷活動、數據報表、系統設定，五大功能模組分多個 Phase 分批交付，外部合作對象是一間大型軟體開發公司。

我以 UX/UI 設計師的身份負責全模組的設計決策與 Prototype 製作。模組數量多、週期緊湊，需要思考怎麼在這個條件下維持交付品質並盡可能降低設計溝通成本。

設計挑戰

工具的極限限制了互動複雜度

Phase 2 靜態設計尚未定稿，業主為了確保重要的報表模組設計方向正確，要求優先交付動態 Prototype。報表模組的互動需求攤開來看：縱向三層 drill down 展開、橫向年份展開月份再展開週次、頂端欄位凍結、左側欄位凍結，多種操作維度，要在同一個 Prototype 介面同時展示。

Figma 可以同時模擬部分互動路徑，但撐不住多維度運作的操作狀態和細節呈現，不僅工序複雜，與實際使用體驗的落差也需要靠口頭補充說明。本專案由設計團隊、外部開發團隊、業主三方溝通，不可能每次 review 都有設計師在場說明，按照過往經驗，很容易造成整個專案反覆出現摩擦。

此外，部分 stakeholder 不太會使用 Figma，學習意願也較低。容易將 Prototype 的限制當作是設計問題，進一步影響使用體驗。按照往例，每次要看 Prototype 都得會議現場 demo，會後還得補一份說明文件方便對照，相當於走一次流程，溝通成本就疊了三層。

設計決策

建立人人可上手的標準工作流

要說服別人改變原有的交付方式，光說明工具能做什麼遠遠不夠。得先確定這套流程從頭到尾都能跑，產出要禁得起檢驗，才有資格去談。因此我設立了三個目標：

1. Hi-Fi Prototype 要能夠突破 Figma 的硬限制
2. 設計稿還原度要在 90% 以上，最理想是做到 Pixel Perfect
3. 就算不是設計師或工程師也可以製作、維護成品

於是我花半天的時間將過去零散的 AI 應用組合成初步的 Prototyping 工作流，包含工具的選用和串聯、人工判斷的節點以及每個工作階段投入的時間評估。

整套工作流以 Claude Code 為核心執行環境。透過 Figma MCP 在 Claude Code 和 Figma 之間建立橋接，直接讀取 Design System 中的元件定義，把下拉選單、Date Picker、Table Cell 這些使用頻率較高的元件轉成 Prototype 的共用元件庫，確保畫面精度能對齊設計稿。規格轉換的部分則透過 Open Spec，以 SDD（規格驅動開發）的方式，在 Claude Code 內將規格文件直接產出可互動的前端框架，互動邏輯有明確的規範，讓 AI 不會自己瞎猜亂做。

Design Token 確保設計稿與 Prototype 一致

Prototype 要能被信任，前提是它的畫面必須和設計稿對得起來。多模組、多頁面的系統若直接用硬編碼顏色和間距，改一次需求就得逐頁修正。在快速迭代的專案中，技術債的堆疊會造成極大的風險。

我以 Figma 設計稿為視覺的單一來源，分別用兩種方式確保 Prototype 精緻度能和設計稿保持一致：

這個架構讓需求調整從逐頁修改，變成只需要維護單一來源就可以同步修改，也確保多個 Phase 迭代下來，Prototype 的畫面精度始終和設計稿保持一致。

成果展示與說服

完成初版報表模組 Prototype 後，我先與 PM 進行內部溝通，說明分三個層次進行：

PM 的評估這個提案對三方都有利，進一步與外部團隊溝通，對方也同意採用，我提出的 Prototype 方案自此成為三方的設計溝通基準。

設計成果

AI Prototyping 工作流有效解決多維度操作行為的痛點，原本很難靠想像的使用行為有了具體的使用體驗，讓交付後的溝通更加順暢，設計也如期定案。

工作流建立後，每個 Phase 的 Prototype 製作有可複用的元件基礎和清楚的分工節點，重複建立的成本大幅降低。Phase 1 在確認後 1 天內完成交付，Phase 2 提前 5 天、Phase 3 提前 7 天交付。

Prototype 直接作為溝通基準，設計稿的來回確認次數減少，三方也更有餘裕可以溝通設計細節，而不是被驗收期限逼著做決定。對不擅長操作 Figma 的利害關係人，這套流程也省下另外約會議 demo，和後補說明文件的工序，極大程度提升整體設計流程的效率。

心得與反思

對我來說，最困難的不是流程設計，而是面對經驗和資源都更加豐富的外部團隊與業主，要不要打破慣例提出自己的解決方案的不確定感。我一貫的做法都是先驗證概念可行，再拿證據去說服、影響他人。AI 只是加速了整個解決方案實踐的流程。

在複雜的協作環境裡，說服需要的不是論述，而是讓人可以親自操作的東西。

最意外的問題是在 Prototype 交付之後才浮現出來。由於 Prototype 擬真程度太高，合作團隊和業主更容易放大檢視細節，出現「這個功能應該要可以操作」、「這個欄位的加總值不對」等問題，導致後續的調整方向從「是否符合使用體驗」，偏移到功能完整性與資料的補齊。除了學習工具的使用以外，當能做到的事越多，我們就越需要定義清楚哪些事是真的該做的。

關鍵洞察

高保真 Prototype 能以假亂真是優點，但當使用者無法區分「模擬互動」和「真實功能」時，驗證目標就會被稀釋。Prototype 的邊界不只需要在製作前定義，更需要在交付後反覆釐清。