設計師常常忙著做文件,卻沒時間見使用者。我用兩個案子,分享 AI 怎麼讓時間回到研究和測試。
做了近 16 年服務設計顧問,我最近在兩個案子裡發現,AI 把畫布、預期成果和互動原型都做快了。對照 UX Collective 一篇談「設計變成沙漏」的文章,這篇整理設計流程的中段為什麼越來越厚、為什麼現在開始變薄,以及省下來的時間,設計師應該花在哪裡。
這篇你可以看到
- 1AI 怎麼改變工作坊的準備先做出畫布和預期討論結果,讓大家眼見為憑
- 2顧客調查怎麼帶著多個原型去見使用者看使用者實際操作,而不只是聽他說喜不喜歡
- 3設計流程的中段,為什麼越來越厚低利率、分工變細,文件變成溝通工具
- 4錢變貴了,AI 剛好出現Airbnb 和 Figma 調查看到的變化
- 5省下的時間,要花回兩個現場Discover 與 Deliver,以及設計師的判斷力
做了近 16 年服務設計顧問,我最近發現,AI 正在改變我們做設計的方式。
上個月,一個專案才剛開始,我們就已經把工作坊畫布做出來了。
不只如此。連工作坊預期的討論過程、參與者可能提出的觀點,以及最後可能完成的成果,我們都先用 AI 產出了一個版本。
這在以前,很難做到。
以前靠腦袋想像,現在可以眼見為憑
以前準備工作坊,我們會先花時間設計流程、思考討論問題,再手動製作畫布、調整排版。光是把想法變成可以拿出來討論的東西,就要花不少時間。
更麻煩的是,在工作坊真正開始前,很多事情只能靠腦袋想像。我們想像參與者會怎麼討論、可能提出哪些觀點、最後產出什麼成果,再透過口頭說明,試著讓其他人理解整個設計。
但光靠說明,每個人腦中想的可能都不一樣。如果討論後發現哪個地方不對,又得重新修改流程、畫布和排版。因為修改成本高,很多時候根本沒有餘裕反覆嘗試。
但這次不一樣。
專案才剛開始,我們就用 AI 做出工作坊畫布,甚至模擬了預期的討論過程和最後成果。這些不是真正發生的結果,而是拿來檢查、討論的假設版本。
有了具體的東西,我們就能更早與相關人員交流,一起確認:
- ✓這樣的工作坊流程,實際操作起來可行嗎?
- ✓畫布上的問題,能不能引導出有意義的討論?
- ✓最後可能產出的成果,是不是符合大家的期待?
如果哪個環節不對,就能提前修改,而不用等到工作坊現場才發現問題。
以前只能請大家想像工作坊會怎麼進行;現在可以先把它做出來,讓大家眼見為憑。
AI 不只是幫我們加快製作畫布的速度。
更重要的是,它讓原本只能在腦中推演的設計,變成可以提前討論、測試和修改的東西。
另一個案子,我們把更多時間花在使用者身上
另一個顧客調查案,也讓我有類似的感受。
以前做訪談,我們通常會先準備訪綱,到了現場,再透過提問了解使用者的想法。如果想拿實際的產品概念給使用者測試,還得另外花時間製作原型。
這次,我們先用 AI 做出好幾個不同方向的互動原型。不只是概念圖,而是可以實際點擊、操作的版本。
因為製作速度快,我們提早完成準備,也有更多餘裕帶著不同版本去見使用者。讓他們實際操作,觀察他們的反應,再根據回饋調整方向。
這跟只問使用者「你覺得這個功能怎麼樣」,很不一樣。一個人說自己喜歡某個設計,和他真的開始操作後的反應,不一定相同。
以前我們可能得先花很多時間做出一個版本,才能知道方向對不對。現在可以更快做出多個版本,也就有更多機會在真正投入開發之前,檢查不同的設計假設。
AI 縮短了製作時間。我們則把這些時間,用來理解使用者真正的反應。
設計師的時間,以前都去哪了?
做完這兩個案子,我剛好讀到一篇文章。
作者 Anamol Rajbhandari 是資深產品設計師,他在 UX Collective 提出一個很有意思的觀點:AI 正在把設計流程的中段掏空,讓設計變成一個「沙漏」。
過去十五年,設計流程越拉越長。研究報告、人物誌、旅程圖、流程圖、線框圖、原型、交接規格,再加上工作坊,以及報告工作坊結果的簡報。
每個環節都有自己的用途。但設計師可能花了大量時間準備文件、整理資訊、進行交接,真正拿產品或服務去接觸使用者的時間,反而變少了。
這段我讀了很有感。
以前有些專案,研究做了、分析完成了、簡報也做得很漂亮。然後結案。
後來,就沒有後來了。
文件記錄了團隊的努力,但不代表它真的改變了什麼。
我不是說研究報告、人物誌或旅程圖沒有價值。而是,這些原本用來幫助設計的工具,有時候卻變成設計工作的主要產出。
我們花了很多時間證明自己有做設計,卻不一定有足夠時間驗證設計是否真的有效。
為什麼設計流程的中段越來越厚?
Rajbhandari 從一個很特別的角度解釋:錢。
2008 年金融海嘯後,美國長期維持低利率。2020 年疫情期間,利率又降到接近零。資金便宜,加上疫情帶動數位服務需求,科技公司快速擴張。公司養得起更多人,也等得起比較長的產品開發流程。
於是,工作越拆越細。研究員負責研究,UX 設計師負責體驗,UI 設計師負責介面,PM 管理產品,工程師負責開發。分工越細,最困難的事情之一,就變成讓每個人理解彼此在做什麼。
研究員訪談了二十個人,不可能要求所有 PM 和工程師都讀完逐字稿,於是整理成人物誌。這週會議做出的決定,要讓幾週後接手的人理解,就靠旅程圖、流程圖和文件。
這些工具很多時候不只是設計工具,也是溝通工具。作者引用的研究也指出,資深從業者使用人物誌時,經常是為了團隊溝通;不同專業團隊檢查同一個網站,也可能找出很不一樣的問題。
這些研究讓我想到另一個問題。當設計品質很難客觀衡量,組織可能會更依賴看得見的交付物,判斷一個團隊有沒有認真工作。
久了,文件越完整、圖表越漂亮,就越容易被當成專業的證明。但它和產品或服務最後有沒有改善,是兩回事。
錢變貴了,AI 剛好出現
2022 年開始,美國快速升息,科技業也從擴張轉向控制成本。企業開始重新檢查組織和工作流程。這麼多分工、這麼多交接、這麼多文件,到底哪些真正帶來價值?
ChatGPT 剛好在 2022 年 11 月推出。作者認為,兩件事在時間上碰在一起。資金成本提高,讓企業有動機重新檢查流程;AI 的出現,則讓部分原本耗費大量人力的工作,有機會更快完成。
Airbnb 是文章提到的例子之一。2023 年,執行長 Brian Chesky 談到公司重新調整產品管理方式,讓產品開發與產品行銷的責任更緊密地結合。目的是減少組織之間反覆交接,讓更精簡的團隊能從頭到尾負責一件事。
Figma 2025 年針對 1,199 位產品團隊成員的調查,也發現 55% 的受訪者開始接手以前由其他角色負責的工作。PM 自己做原型,工程師產出初步設計。不同職能之間的界線,開始變得沒那麼明確。
當一個人可以更快從想法做到原型,原本需要多次交接的流程,自然有機會縮短。這也是作者說的:設計流程的中段,正在變薄。
錢便宜、分工細,要靠大量文件讓大家對齊;做一版畫布或原型很慢,修改成本高。
錢變貴、AI 出現,中段產出又快又便宜;省下的時間,拿去接觸真實的人。
省下中段的時間,我想花回兩個現場
回到我自己的工作。
我很認同作者的沙漏比喻,只是從服務設計的角度,我會把它講得更具體。省下中段的時間,我想花回兩端。
前面是 Discover,真正理解使用者、利害關係人,以及他們所處的情境。後面是 Deliver,把設計帶到現場,透過測試和實際使用,協助團隊把改變落實。
這兩端,都需要與真實的人互動。
回頭看前面的工作坊案例。AI 可以快速產生畫布,甚至模擬整個討論過程。但這些內容是否合理、哪些問題值得追問、流程能不能適用於實際參與者,仍然需要設計師判斷。
而且,工作坊不是照著畫布把問題問完就好。參與者怎麼回應、現場有沒有不同意見、哪些問題值得繼續挖掘,都得在互動中觀察。
原型測試也是一樣。AI 可以一次做出好幾個版本,但哪個值得繼續,不是只看哪個做得最快、畫面最好看。
使用者怎麼操作?他在哪裡猶豫?他說出口的想法,和實際行為是不是一致?這些觀察,才能幫助我們判斷接下來應該往哪個方向走。
而且,原型產出得越快,設計師反而越需要知道怎麼選擇。以前花很多時間才能做出一個版本。現在很快就能看到好幾個看起來都不錯的版本。但如果不知道怎麼判斷,只是把更多方案堆在桌上,也不一定能做出更好的設計。
作者把這種能力稱為「品味」。不只是知道什麼好看,而是能從不同選項裡,辨識什麼真正適合眼前的問題。這種能力,來自長時間的實作、觀察、犯錯與修正。
近 16 年下來,我越來越覺得,這才是設計師原本應該投入時間的地方。
你的一週,花在哪一段?
讀完這篇文章,我也開始重新思考自己的工作時間。如果把上週的工時攤開來看:
- 1有多少時間,你真的在理解使用者、釐清問題?
- 2有多少時間,你在做決定、製作原型、測試方案?
- 3又有多少時間,花在整理文件、修改簡報、調整格式,只為了讓其他人理解你已經做過的工作?
當然,不是所有文件都該刪除。有些文件確實能幫助團隊合作,也能留下重要的決策紀錄。
但如果 AI 能讓我們更快完成這些必要工作,或減少不必要的反覆製作和交接,是不是就能把時間用在更重要的地方?
對我來說,這才是 AI 最值得期待的改變。以前很多設計只能先靠腦袋想像,等到做出來、帶到現場,才知道可不可行。現在能更快把想法變成具體的東西,提前和人討論、驗證,再反覆修改。
AI 讓做出東西變得容易,也讓判斷什麼值得做,變得更重要。
做了近 16 年服務設計,我不認為設計師的價值是產出多少張畫布、多少份報告、多少個原型。而是能不能藉由這些工具,真正理解問題、做出判斷,最後帶來改變。
如果 AI 能讓我們少花一些時間在中間,多花一些時間接觸真實的人、測試真正的方案。那設計師反而更有時間做設計了。
你上週,花最多時間的是哪一段?
參考資料
- Anamol Rajbhandari,〈AI is hollowing out the middle of design, leaving an hourglass behind〉,UX Collective,2026 年 10 月。原文連結
- Figma,〈Are roles and responsibilities a thing of the past?〉(2025 Shifting Roles Report),2025 年。原文連結
- Brian Chesky 於 Figma Config 2023 對談,以及 Lenny’s Podcast 訪談(2023)。
文中的兩個實務案例由團隊共同完成。
如果你的團隊也想重新安排設計流程,把更多時間留給使用者研究和現場測試,歡迎和我聊聊合作的可能。



