從 Designer 到 Builder：AI 如何改變我的 UI/UX 工作流程

・ 設計思考

從 Designer 到 Builder：AI 如何改變我的 UI/UX 工作流程

這篇整理自我這次的分享〈從 Designer 到 Builder：AI 如何改變我的 UI/UX 工作流程〉。聽眾是 UI/UX 設計師，所以重點不在工具教學，而在工作流程到底變了什麼。

Builder 的界線在哪裡？

Builder 的三個階段：概念發想、產品落地、市場變現

我對 Builder 的定義是：一個人透過 AI，從概念發想做到產品落地，再推上市場變現。

  1. 概念發想：想清楚要解決什麼問題
  2. 產品落地：把它用技術實現
  3. 市場變現：有人願意付錢，才算驗證

以我自己做的「快來報價」（qlite.cc）為例，它是一人公司的客戶與報價管理系統。以前我是 Designer，現在比較像 Builder，差別很具體（產品背景可以看〈快來報價 Qlite，我第 n 個用 AI 開發的產品〉）：

快來報價 Before & After：Designer 與 Builder 在交付物、上線方式、驗證方式與協作對象的差異
Before｜DesignerAfter｜Builder
交付物Figma 設計稿＋規格文件可上線的產品
從想法到上線逐一規劃功能，排進時程再交付想到一個，就做一個
驗證方式上線前、開發中、上線後分段檢查先推上市場，看反應再修
需要誰幫忙PM、工程師、QA、行銷自己 + AI

先暫停一下：不是每個設計師都要成為完整的 Builder

交付一個完整的產品，難度太高了。只有自己創業做產品的人，才真的需要走完概念、落地、變現整條路。

對大多數設計師，不論你是乙方還是甲方，更重要的是兩件事：累積知識，以及建立系統化的交付流程。這篇接下來談的，都是這兩件事。

設計師該不該往全端走，我之前也寫過一篇〈邁向 AI 的工作世代，設計師成為全端的可能性？〉。

工具：從 Figma，變成四個

工具從 Figma 變成 Obsidian、Claude Code、VS Code、GitHub 四個

以前畫完設計稿交給工程師，Figma 就夠了。現在我的工作環境變成四個工具，各自負責一件事：

  • Obsidian｜知識大腦：保存研究證據、限制與決策
  • Claude Code｜AI 協作 + Skill：讀知識、改檔案、執行 Skill
  • VS Code｜原型工作區：編輯、執行、驗證原型
  • GitHub｜版本與交付：保存版本、審查變更、交付

如果要開始，我建議先做三件事：

  1. 學 Git 基本操作：commit、branch、PR
  2. 開一個自己的 repo，當 AI 的工作環境
  3. 利用工程的技術，建立一個可以持續更新的知識大腦

Obsidian 和 Claude Code 怎麼搭配，可以參考〈Obsidian + Claude Code，這才是 PM 與設計師該學的〉。

AI 時代，設計師先定義「問題意圖」

四層意圖：問題、功能、操作、執行意圖，設計師專注問題意圖，並以 CRM 為例

在 AI 的時代，「意圖」這個詞很重要。我把意圖分成四層：

  1. Problem Intent 問題意圖：為什麼要做
  2. Functional Intent 功能意圖：要做什麼
  3. Interaction Intent 操作意圖：怎麼使用
  4. Execution Intent 執行意圖：怎麼實現

後面三層，AI 越來越能幫上忙。但設計師最該專注的，是第一層：問題意圖。

意圖沒說清楚，AI 再強，也只是更快做出錯的東西。

舉例來說，「我要做一個 CRM」是解法，不是問題。真正的問題可能是：客戶資料散落各處、維修紀錄難追蹤、業務不知道該 follow 哪些客戶。（延伸閱讀：〈設計流程已死？談 AI 時代真正重要的事 – 意圖〉）

進到真實產品前，設計師的兩個主要任務

兩個主要任務：建立專案的知識大腦，與建立可持續交付的原型
  • 建立專案的知識大腦：累積研究、規則、限制與決策，收斂成清楚的 Problem Intent。
  • 建立可持續交付的原型：把意圖變成可測試、可修改、可交付的版本。

知識大腦：先從專案開始，再長成公司的共享層

專案 A、B、C 各自累積知識，再跨專案抽取成公司共享知識層

不要一開始就替全公司規劃知識大腦。先在專案裡用 AI 建立穩定的流程，每個專案各自累積研究證據、設計決策、領域限制與測試結果。之後再跨專案抽取、驗證、去重，把共通詞彙、重複模式與可重用標準，升級成公司的共享知識層。

知識大腦存脈絡，不存進度

知識大腦與專案管理工具的分工對照

進度每天都在變，放進知識大腦只會累積大量過時文件。所以我的分工是：

知識大腦（Obsidian）專案管理工具
素材與證據：研究、訪談、文件與原始來源任務與待辦：下一步要做什麼
脈絡與決策：當時為什麼這樣判斷、有哪些限制負責人與期限：誰來做、何時完成
結論與學習：提煉後可找回的知識進度與狀態：里程碑、阻塞、每日變動

兩邊用連結互相指過去，不要複製。

Obsidian 保存的，是知識如何形成

知識形成的五層：原始素材、綜合整理、發現、洞察、產品概念

很多人期待從原始資料直接跳到 insight。但我會把中間每一層都留下來：

  1. Raw 原始素材：訪談、研究、文件
  2. Synthesis 綜合整理：摘要、標註、比較
  3. Finding 發現：反覆出現的模式
  4. Insight 洞察：模式背後的原因
  5. Concept 產品概念：可執行的產品構想

這些中間產物是產品概念的來路，也是之後重新驗證的入口。

每個 Skill，把資料往下推一層

repo 結構中四個 Skill 分別對應 wiki 裡的 interview-syntheses、findings、insights、concepts 資料夾

在 repo 裡，我替每一層轉換寫一個 Claude Code 的 Skill：

  1. synthesize-interview → 00. interview-syntheses（整理訪談）
  2. extract-findings → 01. findings（萃取發現）
  3. promote-insights → 02. insights（提煉洞察）
  4. promote-concepts → 03. concepts（歸納概念）

Human in the Loop：人在迴圈裡，Skill 越用越準

Human in the Loop：Skill 把 A 轉成 B，人標註後 refine 成 B'，再回頭修正 Skill

Skill 產出的東西，不會每一個都是我要的。所以我的流程是：

  1. 用 Skill 把輸入 A 轉成產出 B，例如從 Finding 產出 Insight。
  2. 我在 Obsidian 的 frontmatter 欄位標註哪些要、哪些不要，再用 refine 的 Skill 重新生成，讓 B 在內部循環成我要的 B’。
  3. 調整到滿意之後，回頭修正原本 A → B 的 Skill。下一次產生 B，就會更準。

A → B 不一定是 Finding 到 Insight，任何「輸入 → 產出」的 Skill 都適用。重點是人一直在迴圈裡。

【待補：frontmatter 欄位範例】

交付的不是畫面，是設計系統

repo 裡的 CLAUDE.md 與設計系統，透過 Figma MCP 與 Figma 主檔雙向同步，由系統產生新畫面

最後一塊是交付。我的做法是在 repo 裡建立 CLAUDE.md，裡面放 Figma 的連結，透過 Figma MCP 跟 Figma 連動。然後在同一個 repo 建立設計系統：樣式（tokens）、組件（components）、文件（docs），並且和 Figma 主檔保持雙向同步。

之後產生的新畫面，都由系統依照樣式和組件產生，不從頭畫。設計師交付的，不再是一張張畫面，而是一套能產生畫面的系統。

設計系統裡的樣式怎麼分層，可以參考〈Tailwind CSS 與 Design Tokens：色彩系統的三層繼承架構完整解析〉。

結語：設計流程一定會改變

結語：AI 加速了開發已成共識，AI 能否做設計決策還在討論，現在就把 AI 放進工作流程

目前大家的共識是，AI 加速了開發：畫面、原型、程式碼都比以前快很多。

但 AI 能不能幫設計做決策，還在討論。判斷什麼值得做，目前還是設計師的責任。這部分我在〈AI 讓設計更快了，為什麼設計師沒有比較輕鬆？〉和〈當 AI 給出完美解答，設計的價值在哪裡？〉都有更完整的討論。

不管答案最後是什麼，有一件事現在就可以做：把 AI 放進你的工作流程。從知識大腦、Skill 到設計系統，先讓自己的效率提高。

延伸閱讀