快速解答： 迭代收斂,是把發散階段產出的一堆解法點子,透過「優先排序」和「原型測試」兩個階段,一步步縮小成一個經過用戶驗證的功能設計。你先用渴望性、可行性、可行性三大限制篩掉不合格的點子,再透過低成本原型測試,反覆驗證剩下的假設。Claude AI 能幫你彙整篩選標準、草擬測試大綱、整理用戶反饋——但哪個點子真正值得往下走,還是得靠你自己判斷。
你是不是也曾經在腦力激盪結束後,看著白板上密密麻麻的 20 幾個點子,心裡冒出一句:「所以...到底要做哪一個?」
先停一下。
上一篇,我們談過怎麼用「有限制的發散」,把一個模糊的問題,變成一堆具體的解法點子。但發散只是功能設計的前半場。點子生出來了,不代表你已經知道答案——你只是把選擇題,從「該怎麼解決」變成了「該選哪一個」。
這篇文章,我們要走進功能設計的下一步:迭代收斂。你會看到怎麼用兩個階段——優先排序和原型測試——把一堆點子,收斂成一個真正值得開發的功能。
迭代收斂,是把發散出來的點子群,收斂成一個經過驗證的原型的過程。
如果你習慣瀑布式的做法,你可能會想:先開會決定一個方案,直接進開發,不是比較快嗎?
不。這種做法,才是真正的慢。
瀑布式開發的問題在於,你把所有的假設都壓到開發階段才驗證。等工程師寫完程式碼,你才發現用戶根本不想要這個功能,或是某個 UI 設計讓人一頭霧水——這時候要改,代價已經是重寫程式碼,不是修改一張草圖。
迭代收斂反過來做:PM 和設計師持續合作,不斷地優先排序、原型、測試,在真正投入開發資源之前,先把所有的假設和限制條件驗證過一輪。Claude AI 在這個過程裡,能幫你分析解法之間的取捨、快速彙整測試回饋、整理跨方案的比較資料——大幅壓縮你原本要花在資料整理上的時間。
這樣做,是不是比較慢?短期看,是。你多花了幾天做原型、跑測試。但長期看,你省下的是幾週,甚至幾個月的開發重工。
這正是收斂的核心邏輯:在設計階段測試假設,遠比在開發階段測試便宜。
收斂的第一步,是優先排序——把發散出來的解法縮小成一個更小、更聚焦的清單。
還記得功能設計一開始,我們定義過三種限制:渴望性、可行性、可執行性嗎?
發散階段,你主要用渴望性限制來引導腦力激盪。現在,輪到可行性和可執行性上場了。
判斷可行性,你要問:「這個解法能不能創造我們設定的商業價值?它符不符合團隊、產品、公司的策略方向?」
判斷可執行性,你要問:「以公司現有的時間、資源、技術能力,這個解法做得出來嗎?」
這一步,強烈建議拉工程團隊進來一起看。他們對「做不做得到」的判斷,比你自己猜準得多。
如果你要一個一個評估點子,20 幾個點子夠你忙上一整天。
更聰明的做法,是善用你在發散階段已經做好的分群。記得嗎?腦力激盪結束後,你把點子依照主題分成幾個群組。現在,你可以分兩層篩選:
篩完之後,你手上通常會有一個「數量合理」的清單。但就算篩過,你可能還是沒辦法把每個點子都做成原型測試。這時候,你有兩條路:
來看一個實際案例。Airbnb 想改善房東的行動裝置留言體驗,藉此提升 App 使用率。發散階段結束後,團隊產出了 17 個解法點子,分成 6 個群組——依照產品介面區塊和變更類型分類。
**第一輪,團隊先看可行性。**策略契合上,解法必須直接聚焦房東體驗,提供實質價值。商業價值上,目標是把房東的行動裝置使用率從 50% 拉到 70%——這代表小修小補的效能優化,根本不值得優先處理。
**接著看可執行性。**Airbnb 希望在半年後的房東大會上發表這個功能,這代表團隊只有 6 個月能做出可上線的版本。
在這兩個限制下,團隊先在群組層級砍了兩組:「收件匣整合」需要一個目前還不存在的完整行動版收件匣,6 個月內做不完;「統計頁面」雖然有價值,但只有少數房東會用,難以帶動 20% 的使用率成長。
留下 4 個群組——資訊架構、收件匣效能、收件匣新功能、行事曆功能。前兩組因為能確保「房東找得到、用得順」收件匣,團隊直接全數保留。
第二輪,團隊深入剩下兩組,找工程團隊一起評估。因為前兩組已經佔用了大部分開發量能,工程團隊估計只剩capacity做 3 個新點子。搜尋功能升級、附件上傳、行事曆直接編輯預訂,這三個都被標記為「複雜度太高,做不完」,直接淘汰。
剩下 9 個點子,團隊還得再砍 2 個。最後,他們選擇留下訊息範本、行事曆手機版檢視、行事曆同步——因為這三個最能讓 Airbnb 跟 WhatsApp 這類競品做出差異化。
從 17 個到 9 個,再到最終的一小群方案——這就是優先排序的完整過程。接下來,這些倖存的點子,要進入原型測試,才能真正知道用戶買不買單。
優先排序,幫你篩掉了不可行、不可執行的點子。但篩剩下的,依然只是「假設」——你還沒問過真正的用戶。
這正是原型測試要解決的問題。
原型,是功能設計的實體呈現——可以是一張紙上的手繪草圖,也可以是一個能點擊互動的高擬真介面。原型測試的邏輯很簡單:做出原型、拿去給目標用戶測試、根據學到的東西調整——一輪一輪重複這個循環,直到你手上有一個經過驗證的設計。
原型測試有三個明顯的好處:
要跑一場有效的原型測試,你需要先定義四個元素:受眾(誰來測)、擬真度(原型做得多細)、主持方式(怎麼引導受眾互動)、綜合分析(怎麼把結果變成設計產出)。
受眾很單純——用你在驗證用戶價值階段就定義好的目標用戶群即可。真正需要花心思的,是後面三個。而這三個,又取決於你的測試目標:設計探索還是設計驗證?
設計探索,是測試多個解法和設計選項,找出哪個對用戶最有吸引力。通常發生在優先排序剛完成、你手上還有好幾個可行方案的時候。
設計驗證,則是針對一個已經鎖定的解法,測試、優化、排除風險。適合用在你已經有足夠證據、只剩下細節需要打磨的階段。
怎麼判斷自己該做哪一個?問自己三個問題:哪些點子或元素比較受歡迎?用戶偏好哪種設計選擇?不同用戶輪廓的偏好,是不是有落差?
如果你答不出來,又找不到現成的資料——像是用戶行為紀錄、熱點圖、客服反饋、簡易問卷——那就代表你還沒準備好驗證,得先做探索。
用 ClassPass 的假想情境來說明差異。假設 ClassPass 想做一個連接教練和會員的聊天功能,但還沒有明確的設計假設。他們可能會先做探索:做出兩個原型,一個是輕量的預設訊息互動(像「上課時間是幾點」這類範本訊息),另一個是開放式的搜尋加聊天介面。把兩者都拿給用戶測,看哪個更符合渴望性限制。
等他們確定了整體聊天設計的方向,才進入驗證階段——做一個高擬真、可點擊的原型,觀察用戶實際互動時,哪裡會卡住、哪裡會誤解。
擬真度低一點,反而更有效率。
在探索階段,你要的是高層次的偏好反饋,不是逐一像素的細節意見。所以原型可以偏向低擬真——紙上草圖或簡單線框都行。但要注意:你想測試的那個功能點,仍然需要做到「可以互動」的程度,其餘部分維持低擬真即可。
拿 Slack 的例子來說。假設 Slack 想在側邊欄加入「分類頻道」的功能,但還沒決定用哪種操作方式——右鍵選單、點擊加號,還是點三個點。整體原型可以維持粗略,只要讓用戶知道自己在哪、要做什麼就好。但這三個操作選項本身,得做到可以真的點擊,才能測出用戶真正的偏好。
新手最容易犯的錯,是直接問用戶:「你喜歡這個設計嗎?」
用戶不知道怎麼回答一張粗略的草圖。更糟的是,直接問「你不喜歡哪裡?」,會把用戶架在一個尷尬的位置——沒有人想在訪談裡,對著你辛苦做出來的東西講壞話。
正確的做法,是讓用戶跟原型互動,你在旁邊觀察,再從行為裡推導結論。整場測試分成三段:
在探索階段的鋪陳,你需要先建立問題意識,讓用戶帶著問題去感受原型。同時,你要明確告訴他們:「我們不是要你評論設計細節,只想聽你對這個概念的整體反應。」
到了提問階段,別只問「你喜不喜歡」,要問「為什麼」。像是:「你比較可能用哪一個?為什麼?」「什麼情況下你不會用它?」把問題錨定在用戶剛剛的具體行為上,而不是泛泛的印象。
這是整個流程裡最容易走偏的一步。
用戶說「按鈕再大一點就好了」,你很容易直接照做。但真正的問題,可能是整個畫面資訊太雜,用戶根本找不到按鈕——放大按鈕治標不治本,重新設計版面才是解法。
記住:**用戶是自己問題的專家,不是設計方案的專家。**你的工作,是把他們的反應,翻譯成設計語言。
在探索階段,你的綜合分析要回答三個問題:哪個解法更受歡迎?哪些設計選擇被偏好?不同用戶輪廓之間,偏好有沒有差異?最終產出,應該是一個標註過的低擬真原型,清楚標示哪些是核心功能、哪些是差異化亮點。
而在驗證階段,你要找的是設計問題(擋住核心功能的 UI/UX 選擇)和易用性風險(功能本身造成的認知負擔或操作阻力)。以 StoryChief 想優化的入職問卷為例,如果測試發現某些選項的用詞讓用戶困惑,這是設計問題,當下就該修正;但如果用戶因為「想達成的目標太多」而選不出答案,這更像是一種難以完全靠設計解決的易用性風險,得標記起來,留到開發階段持續觀察。
整個收斂過程,PM 和設計師不是各做各的——是要肩並肩走完每一輪迭代。
PM 的角色,是把限制條件、用戶脈絡講清楚;設計師的角色,是把這些限制轉化成具體的視覺和互動方案。優先排序時,PM 該主動拉工程團隊一起評估可行性和可執行性;原型測試時,PM 很適合跟設計師一起主持訪談,因為你對用戶的理解,能幫忙判斷用戶反應背後真正的原因。
維持對齊的關鍵,是頻繁地同步——別等到一輪測試全部做完,才跟設計師分享觀察。每次訪談結束,就一起debrief;每完成一輪收斂,就一起確認,接下來要探索還是驗證。
這是迭代收斂真正的商業邏輯:越早發現問題,修正的成本越低。
在原型階段改一張草圖,可能只要幾分鐘。在開發階段改一段已經寫好、甚至已經上線的程式碼,代價是重寫、重新測試、重新部署——這還沒算上因此延誤的時程。
迭代收斂還有一個常被忽略的好處:它能防止範疇蔓延。因為你在設計階段,就已經用渴望性、可行性、可執行性三大限制,把不該做的點子篩掉了。等到真正進入開發,團隊手上是一份經過反覆驗證的清單,不會在開發中途,又冒出「要不要順便加這個」的念頭。
**Claude AI 在這整個過程裡,扮演的是加速器的角色。**它能幫你彙整篩選標準、草擬測試大綱、快速整理跨輪次的用戶反饋、標示出跟你原本假設矛盾的地方。這能把原本要花上好幾天的資料整理工作,壓縮到幾小時內完成——讓你有更多時間,花在真正需要人來判斷的地方:哪個問題值得解決、哪個信號值得相信、哪個原型該進一步打磨。
走完這一輪流程,你應該已經看出迭代收斂的核心邏輯:先用限制條件篩選點子,再用原型測試驗證假設——一輪接一輪,直到你手上有一個真正經過用戶檢驗的設計。
Claude AI 能在每個環節幫你分擔資料整理的工作——篩選標準、測試大綱、反饋彙整。但真正決定「這個點子值不值得留下」「這個用戶反應代表什麼」的判斷,永遠得靠你自己。
下次你的腦力激盪結束,面對一堆點子時,別急著挑一個「感覺最好」的方案。先問問自己:我篩過可行性和可執行性了嗎?我準備好用原型去問用戶了嗎?
最好的設計,不是選出來的。是收斂出來的。
迭代收斂通常要花多久時間?
視功能複雜度而定。小型功能,優先排序加上一到兩輪原型測試,通常一到兩週內可以完成;規模較大或風險較高的功能,可能需要三到四週,涵蓋多輪探索與驗證測試。
我完全沒有設計背景,也能主導原型測試嗎?
可以。你不需要會做出精美的原型,重點是懂得怎麼定義測試目標、設計提問方式,並且正確解讀用戶反應背後的原因。搭配設計師的視覺專業,加上 Claude AI 協助整理反饋,你完全可以參與甚至主持這個流程。
跳過原型測試,直接把優先排序後的點子交給工程開發,風險是什麼?
最大的風險是,你依然只驗證了「這個點子理論上可行」,卻沒驗證「用戶真的想用」。等到開發完成才發現用戶不買單,修正成本會遠高於在原型階段就發現問題。
設計探索和設計驗證,可以同時進行嗎?
不建議。這兩者應該依序進行——如果你還沒有足夠證據鎖定單一方向,就該先做探索;等方向確定後,再用驗證測試打磨細節、排除風險。同時做容易讓測試目標混淆,拿到不乾淨的資料。
這套迭代收斂流程適合什麼樣的人學習?
任何正在把設計點子轉化成可開發功能的人都適用——不管你是團隊裡的產品經理、設計師,還是正在用 Claude 獨力打造軟體產品的初學者。只要你手上有一堆點子需要收斂成一個方案,這都是你該走過的流程。
iThome鐵人賽
看影片追技術