當 Prototype 太早成為答案：AI 協作下，產品設計容易忽略的思考盲區

最近幾次和 PM 合作，我開始遇到一個很明顯的變化：PM 也能透過 AI 很快產出看似完整的 Prototype，甚至一次提出好幾種呈現方案。團隊可以更快看到流程、討論解法，從表面上看，設計似乎也能更快往下走。

但我踩了幾次雷之後，開始意識到一件事：Prototype 產得越快、看起來越完整，反而越容易讓人誤以為「問題已經被想清楚了」。

容易被跳過的，正是原本應該發生在 Wireframe、Flow chart 階段的思考。

第一次踩雷：我直接把 PM 的 Prototype 當成設計起點

有一次，PM 已經準備好 Prototype、需求規格與流程。整體看起來很完整，功能也像是已經回答了原本的問題。

於是我很自然地往下一步走：截圖 Prototype、放進 Figma，開始思考如何套進既有的 Design system、哪些元件需要調整，以及哪些 Demo 階段為了方便理解而加入的說明，在正式產品裡其實可以拿掉。

但就在我調整 UI 的過程中，我卡在一個關鍵情境上。

我無法說服自己：為什麼使用者在這個情境下，一定要用這個解法？

我重新回去讀需求規格、確認情境與步驟，再和 PM 來回討論，最後發現問題並不只是畫面該怎麼呈現，而是這個功能本身其實無法解決原本的問題。

設計因此暫停。

這次經驗讓我發現，我原本以為自己是在「接續 PM 已經完成的前期思考」，實際上卻是把 Prototype 當成了已經被驗證過的答案。

第二次踩雷：不是每個 UX 問題都需要再做一個解法

另一次，團隊有人提出一個 UX 問題。我判斷可以透過小範圍的 UI 修改改善，因此很快做了一個 Prototype，再和 PM 討論。

那個方案本身確實能解決問題。

但繼續往下看後，我們才發現：這個問題不一定需要另外被解決，因為產品裡原本就已經存在其他處理方式。

這讓我開始問自己：

有沒有可能在進入 Prototype、甚至進入設計稿之前，就先發現這些問題？

太早收斂問題

回頭看這兩個情境，都是太快相信已經出現在眼前的解法。

有時候是直接接手別人透過 AI 產出的 Prototype；有時候則是自己還沒有把問題釐清，就先和 AI 討論，從它提供的方案裡選一個看起來合理的方向，再一路往下做。

這其實等於把一部分原本屬於設計師的分析與判斷，太早交給了 AI。

AI 很擅長根據已知資訊快速生成常見流程與解法，但它並不是實際操作產品的使用者。即使提供很多上下文，它的回覆仍然會依照當下對話持續收斂。

這種感覺很像聚光燈。

一開始照亮的是整個問題空間，但當對話不斷沿著某個方向深入，光線會越來越集中。被照亮的區域變得更清楚，周圍沒有被討論到的可能性卻也更容易消失。

也像騎車速度越來越快時，視線會自然集中在前方。你看得更遠、更快，卻不一定看得到周圍。

Prototype 應該幫助思考，而不是取代思考

後來，當 PM 再次帶著 Prototype 進來時，我沒有直接把它轉成 Figma 設計稿。

我重新畫了 Wireframe 和 Flow chart，把不同情境、流程與可能性攤開來看。

這些產出不一定比 Prototype 精緻，也不一定更快，但它們對我有另一個作用：強迫自己重新建立對問題的理解。

我會重新確認：

• 我是否真的理解需求規格？
• 這個流程裡還有哪些情境沒有被看見？
• 現在看到的解法，是唯一合理的解法，還是只是目前最容易被呈現出來的那一個？
• 我們正在解決的是使用者真正的問題，還是 Prototype 已經替我們定義好的問題？

AI 讓 Prototype 變得非常便宜，這是一件好事。但當「做出一個看起來可以運作的東西」變得太容易時，設計流程真正稀缺的反而不是產出能力，而是在收斂之前，仍然願意把問題重新攤開來看的能力。

對我來說，Wireframe 和 Flow chart 的價值也因此變得更清楚。

它們不只是比較低擬真的設計產物，而是一種思考工具：在答案看起來已經出現時，提醒自己先不要急著相信它。