最近這段時間，我在工作中用了愈來愈多 AI 工具。

我會用 AI 整理資料、發想方向、製作原型，有時也讓它協助寫程式。過去需要在不同工具之間來回處理的工作，現在確實可以更快完成。照理來說，設計師應該可以少做一點，或者至少輕鬆一些。

但我的實際感受卻不是這樣。

設計的產出速度變快了，工作量卻沒有明顯減少。為了配合工程端使用 AI 開發的方式，設計師反而要花更多時間研究工具、調整流程，還要檢查 AI 產出的內容。

這讓我開始懷疑：AI 提高的究竟是設計師的生產力，還是只提高了產出的速度？

做得更快，不代表設計也快了

OpenAI 產品設計負責人 Ian Silber 最近接受 Lenny’s Podcast 訪問時，談到類似的現象。（關於設計團隊生產力與回饋流程的討論約從 4:32 開始。）

他提到，工程師使用 AI 後，可能感受到十倍甚至更高的生產力提升，但設計團隊並沒有出現相同幅度的變化。因為設計仍然需要反覆嘗試、取得使用者回饋，以及協調組織內不同角色的意見。製作方案的速度雖然變快，這些判斷與回饋過程卻沒有以相同幅度縮短。

Silber 並不是說 AI 對設計沒有幫助，而是設計工作的進展，很難只用產出速度衡量。在這場訪談中，他提到設計流程依然需要時間，沒有像程式開發一樣被大幅壓縮。

這裡提到的生產力提升倍數，是 Silber 在訪談中描述的內部觀察，而不是經過公開研究驗證的統計結果。不過，他對設計流程的描述，確實呼應了我的工作經驗。

AI 可以很快產生介面，也能根據需求做出可以操作的原型。但設計師真正花時間處理的，往往不是「能不能做出來」，而是「為什麼要做這件事」。

設計流程是在建立判斷的依據

當 AI 能快速產生畫面與原型，我們很容易認為設計工作已經被大幅加速。

但在做出這些成果以前，設計師還需要訪談使用者、理解問題，並和產品、工程、營運及其他利害關係人確認不同限制。

即使畫面可以在十分鐘內完成，我們仍然要判斷：這是不是使用者真正需要的功能？它是否符合商業方向？工程上需要多少成本？不同部門能不能接受這樣的改變？

使用者訪談、需求釐清、方案測試與利害關係人討論，不只是設計流程中的必要步驟，也是團隊建立判斷依據的過程。少了這些工作，我們或許可以更快得到一個答案，卻不一定知道這個答案是否值得相信。

產出增加，判斷也跟著增加

AI 加快工程開發之後，設計師也多了一些新的工作。

為了讓設計成果順利進入開發，我開始花時間研究不同的 AI 工具，理解它們如何讀取設計系統、產生介面，以及如何把設計轉換成工程師能繼續開發的形式。這些學習可能帶來新的能力，但在現階段，它們也是增加的工作量。

而且，當製作方案的成本下降，我們不一定會因此做得更少。團隊可能提出更多想法、製作更多版本，也更容易在方向還沒釐清以前，就先做出看起來相當完整的成果。

以前的限制可能是「這個想法做不做得出來」，現在則變成「這麼多做得出來的想法，我們該選哪一個」。

製作的瓶頸變小了，判斷與溝通的負擔卻可能變得更大。

我們該怎麼衡量設計生產力？

如果設計師原本一天完成兩個畫面，現在可以完成十個，當然是一種效率提升。但如果多出來的八個畫面讓團隊花更多時間比較，也沒有讓我們更理解使用者，這些產出是否真的推動了專案？

或許設計生產力不該只看完成多少設計稿，或多快把內容交給工程師。它也應該包含：團隊是否更早發現錯誤方向、是否減少不必要的開發，以及是否更清楚知道自己為什麼做出這個決定。

AI 讓我們更快把想法變成看得見的東西。但當製作不再是最大的限制，我們也更需要回答另一個問題：在所有可以做的事情之中，什麼才真正值得做？

也許，AI 沒有讓設計師比較輕鬆，不只是因為工具還不夠成熟，而是因為設計真正困難的部分，從來不只是把東西做出來。

參考資料

• Lenny Rachitsky，〈OpenAI’s Head of Design: This is the best time in history to be a designer〉，Lenny’s Podcast，2026 年 8 月 16 日。
• YouTube 完整訪談，關於設計團隊生產力與回饋流程的討論約從 4:32 開始。

AI 協作聲明

這篇文章由我提出主題與問題，並在寫作過程中與 AI 討論，協助搜尋與整理資料、梳理論點及調整文字。文章中的個人經驗與觀點由我提供，最後也由我確認內容、完成編修，並對發表的文字負責。

涉及研究或外部資料的內容，我會盡量附上來源，並區分研究結果與自己的推論。若有疏漏或理解不周的地方，歡迎指出，一起把問題想得更清楚。