[讀者回函] OpenAI 說設計師的最好時代，多數公司卻只聽見「做快一點」(上)

序言：8 月 16 日，OpenAI Head of Product Design Ian Silber 在 Lenny’s Podcast 說，現在是史上最好當設計師的時代。他帶 OpenAI 產品設計約三年，ChatGPT 與 Codex 的產品體驗在他手上；此前八年在 Instagram（含 Reels），中間還做過 Instagram 創辦人的新聞 App Artifact。

多數組織把他聽成另一句話：AI 讓設計變快，所以設計團隊應該變小。

因為同一場訪談裡，Lenny 剛說完另一個畫面：設計師與使用者研究員是科技工作者中最不快樂的一群-最焦慮、最疲累、最不樂觀，也最不願意推薦別人進入這個職業。

Silber 沒有否認這種焦慮。

他說，設計師現在不清楚組織究竟期待他們做什麼：是不是要每天出程式？是不是得把原本受過訓練的工作方式全部換掉？

“We’re unclear right now what is expected of a designer.”

「現在不清楚一個設計師究竟被期待做什麼。」

“Do I need to be shipping code every day?”

「我是不是得每天都交付程式碼？」

還在職、晚上做 demo、準備把 AI 當成一人公司槓桿的人，面對的是另一個問題：你做出的東西是否帶走創業？那留到下一篇。

作者補充：Dana 與 Marcus 是顧問現場的借位，不是單一客戶報導。董事會把「工程 10x」聽成設計可以更小、主管把「高好奇心」聽成全員必須會用 agent-這兩種誤讀我聽過不只一次。下文工作坊是去識別後的現場紀錄：公司名、產業、產品線、編制拿掉；角色不可對號入座。產出變便宜之後，組織常先改編制、先改工具覆蓋，卻沒先改誰可以失敗、誰負責收斂。

Lenny 承接 Jenny Wen（Claude Code 設計主管）對傳統流程的描述：先 prototype、mock、測試、研究、迭代，再交給工程；他問，這套節奏還有沒有空間存在？

Silber 先說，設計工作沒有像工程一樣被直接壓縮。

“Engineers have 10 or sometimes like 100x their productivity, but our design team hasn’t.”

「工程師的生產力有時提高了 10 倍、甚至 100 倍，但我們的設計團隊沒有。」

他接著把時間花在哪裡講清楚。

“The design process still takes time.”

「設計流程仍然需要時間。」

“You think you have a great idea and you try it and it sucks.”

「你以為自己有好主意，試了卻很糟。」

“You give it to users or internal [people], you get feedback and it’s wrong.”

「交給使用者或內部同事後得到回饋，發現它仍然是錯的。」

“The design process is really still very messy and fluid.”

「設計流程仍然非常混亂而流動。」

AI 的確讓人更快把點子變成畫面、流程或可跑版本。但重點是：設計迴路沒有消失。

“You can get much more ideas out fast, but you still need that whole sort of feedback loop.”

「你可以更快地產出更多想法，但仍然需要整個回饋迴路。」

我在 11 月現場會把這條講得更清楚：動手畫之前，先把判斷寫成一份 UX 文件-要做哪些頁、哪些模組、使用者怎麼走、誰交接給誰。不必漂亮，能讀就行。Design 是畫面原型，Build 才是接上資料、登入、付款之後可跑的東西。

AI 壓縮了候選物的生產時間；它沒有壓縮問題定義、使用者理解、跨團隊對齊與後續維護。

甚至在大型組織裡，後者還是昂貴的。

“There’s the alignment of getting many people… especially in a bigger company, [which] still has a lot of overhead.”

「讓許多人對齊這件事-尤其在大公司-仍有大量協調成本。」

這是讀這場訪談的第一個分岔：只投資「生成得更快」、不投資研究、批評、決策與協調，得到的是更多待判斷的設計。

Silber 隨後描述 OpenAI 內部兩種看似矛盾、其實各有條件的工作方式。

有些 ChatGPT 功能，團隊會反覆打磨。

“There are certain features for ChatGPT where we really obsess and we really spend a lot of time.”

「ChatGPT 有些功能，我們會反覆琢磨細節，也會花很多時間。」

“We try 100 things, we throw out 99, we finally ship one.”

「我們試 100 個方向、丟掉 99 個，最後才出貨一個。」

另一些工作，例如 Codex，則採取截然不同的節奏。

“We really embrace building in public.”

「我們很積極採取公開建造、公開吸收回饋的做法。」

“You can try stuff and get instant feedback both internally and externally.”

「你可以試東西，立刻從內部與外部得到回饋。」

“Other things [go] idea to ship in like… four hours.”

「另一些事情，可能從想法到上線大約四小時。」

這兩種節奏看起來都很快，其實是兩種完全不同的組織許可。

第一種，允許大量失敗被正式認列為探索成本。我把它叫作丟棄許可。

試 100 個、丟 99 個的前提，不是團隊不在乎產出，而是那 99 個不會被算成「為什麼你花了這麼久卻沒有交付」。在經營上，這是做出較好核心體驗的探索成本，不該進交付團隊的失敗紀錄。

那 100 次可能混著設計、產品判斷、內部 dogfooding、A/B test 與用戶研究，不能單記成一門「研究」科目。

第二種允許未成熟方案上線後被撤回、改寫或放棄。前提是團隊真的能承受「推出後發現錯了」。

Silber 說得很直白：

“The technology might change in like a month.”

「技術可能一個月後就變了。」

“The latency profile has changed… the intelligence has changed.”

「延遲特性變了；智能水準變了。」

“Maybe not be so precious about it until it’s at the point where… this is kind of hardened.”

「在它還沒進入相對穩定、硬化的階段前，也許不必對它過度珍視。」

這就是四小時上線得以成立的條件：該層體驗還沒有被視為永久承諾，而且團隊能接受它隨技術變化被拆掉。

許多公司只抄四小時、不抄撤回，只抄 100 個版本、不抄丟棄，最後多的是 prototype、會議與等人評論；可被放棄的東西沒有變多。

Dana 經營一間中型產品公司。

當董事會讀到「工程師 10 倍、100 倍生產力」後，問她：設計團隊是否也能以更少人完成更多功能？

Dana 的第一反應可以理解。

現在一位設計師能用 agent 做介面、寫文案、產生不同方向、甚至做出可操作原型；以前需要一週的東西，現在可能一天就能出來。

問題是，她把產出量誤認為組織能力。

你不會用「我覺得這個介面很好用」來結束一場易用性測試。

那為什麼董事會可以用「我覺得快多了」來結束一次編制評估？感覺不能當數據。Ian 口述的工程 10x、100x 更不能當 headcount 公式。

OpenAI 能「試 100 個丟 99 個」，是因為它明確把自己視為研究型組織。

“We’re such an experimental company.”

「我們是一間高度實驗性的公司。」

“We are driven by research and we treat our company as a research lab.”

「我們由研究驅動，並把公司當作研究實驗室。」

“That DNA is deeply embedded in everything we do.”

「那種 DNA 深深嵌入我們做的一切。」

這裡的 DNA 寫進操作裡：失敗被如何解讀、什麼工作可被公開測試、何時可以改動核心體驗、誰有權說「這個先不要」、以及團隊是否有能力從錯誤中回收洞察。

Dana 的公司（金融產業）可以使用相同模型，卻沒有相同的許可結構。

如果她把「我們也要 100 個方向」交給原本只被允許交付一個方向的團隊，那 99 個被丟棄的方案很快會變成 99 個績效爭議。

如果她把「四小時 ship」套到不能出錯的付款、身份、醫療、教育、企業管理或無障礙流程上，那是把風險轉嫁給使用者與後台團隊，跟 product velocity 無關。

她真正該問的是：

這一季有哪些工作，失敗算作認可的探索；哪些工作一旦出錯，就會傷害信任、資料、權益與品牌？

這是資源配置題，會決定這季錢與注意力往哪裡走。

Dana 的下一步：把每個工作放進正確層級，先別問「設計可否 10x」。

我看過一份這季 OKR 草案，準備把「每位產品設計師每週交付更多 AI 原型」寫進目標；同一份草案也預設，部分原型可直接進客戶可見環境。文件沒有區分探索、受控實驗與核心體驗，也沒寫誰能撤回、誰負責批准。工作坊後，季度 OKR 加上了這三層。

Dana 若真的要調整編制，還有第二個不能略過的段落。

Silber 承認 PM、設計、工程的邊界正在變模糊。

“Those lines have always been blurry, but they’re becoming blurrier for sure.”

「那些界線一直都很模糊，只是現在肯定變得更模糊。」

但他沒有得出「因此大家都會變成一種 builder」的結論。

“I do still think that… you do still need people that have certain responsibilities.”

「但我仍然認為，你還是需要有人承擔特定責任。」

“If you have one person that’s expected to design, to rally a team around something, to align a whole company, to do all the work that a PM does… and also be engineering it, it might be hard to find one person that’s good at all of those different skills.”

「若期待一個人同時設計、動員團隊、讓整間公司對齊、完成 PM 的所有工作，還要負責工程，很難找到一個人在所有這些能力上都足夠好。」

他的說法很值得保留：不是職稱不可改，而是建造好軟體需要不同的「帽子」。

“There are different sort of hats that you need to wear to build great software.”

「要做出好軟體，有不同的帽子必須被戴上。」

創業時，Silber 會找能流動於不同帽子之間的通才。

“If I were starting a company right now, I would hire the best generalist people I could possibly think of.”

「如果我現在創業，我會聘用我能找到、最能在不同角色間流動的通才。」

但是，成熟組織不應把這句讀成「取消專責、每人兼三職」。

Dana 該做的是一張帽子地圖：誰負責收斂問題空間？誰動員多個團隊？誰把設計接進系統？誰對可靠性負責？誰在使用者受傷時說明、修正並承擔後果？

每頂帽子要有一位可被明確找到的最終責任人；協作可以多人，最後問責不能模糊。找不到人的那一格，本週先空著也要寫「待指定」。沒有問責人的揭露、原則頁、AI 委員會，都只是沒人負責的儀式。

Marcus 的公司沒有先談裁員，先下了另一種看似溫和的命令：三個月內，產品、設計與工程團隊都必須會用 Codex 或 Claude。

HR 參考 Silber 的招募語言，更新職缺：

“We do not expect you to have a background in AI.”

「我們不期待你有 AI 背景。」

“We definitely expect high curiosity about it.”

「但我們確實期待你對 AI 有高度好奇心。」

“Prototyping… has become more and more accessible.”

「原型製作已變得越來越容易取得。」

“Systems thinking is becoming more and more important.”

「系統思考變得越來越重要。」

這些句子沒錯，卻被改寫成工具覆蓋率-也就是多少人已登入、受訓或至少使用過 Codex、Claude 等工具。但覆蓋率不是成熟度指標。

兩週後，Marcus 的 評圖 桌上多出 40 個 agent 概念：漂亮的畫面、可跑的流程、不同風格的 onboarding、看起來有說服力的文字。

PM 問：哪個真的回答使用者痛點？

研究員問：哪個有證據支持？

工程師問：哪個能安全接進系統？

法務或資安問：哪個會帶來不可接受的外部性？

房間安靜下來。

Silber 所說的 systems thinking，講的是不要堆出一堆彼此孤立、一次性的體驗。