快速解答： 功能設計，是把已經驗證過的用戶問題，轉化成具體解決方案的過程。它分成三個階段——發散（腦力激盪出多種點子）、收斂（測試並篩選出最佳方案）、核准與對齊（取得利害關係人支持）。Claude AI 能在發散階段幫你根據限制條件生成、分類、篩選點子，大幅加速腦力激盪的效率。但決定哪個點子值得往下走，還是得靠你自己判斷。
你是不是也曾經興沖沖地把一個「我覺得超酷」的功能點子，直接丟給 Claude Code，叫它生成程式碼？
先停一下。
在前面幾篇文章，我們走過了功能機會驗證的完整流程——確認策略契合、精煉用戶價值、驗證商業價值，最後把這些洞察講清楚，拿到團隊和領導層的核准。這一步完成之後，你手上應該已經有了一個經過驗證、值得投入資源的問題。
但接下來呢？光是知道「用戶有這個問題」，並不等於你知道「該怎麼解決它」。這中間的距離，正是功能設計要填補的空白。這篇文章，我們要走進產品開發的第二根柱子——功能設計，並且看看 Claude AI 能怎麼幫你在發散階段做得更快、更準。
功能設計，是從問題走向解法的旅程。
它的任務很單純：定義你打算用什麼方式，解決你已經驗證過的那一個用戶問題。多數科技公司採用的設計流程，通常包含三個階段。
這聽起來很直覺，對吧？但現實是，多數初學者從來沒被教過怎麼走完這整個流程。網路上散落著各種局部框架——怎麼做原型、怎麼主持腦力激盪——卻很少有人把它們，跟前面的機會驗證、後面的功能開發，串成一條完整的線。
結果呢？功能設計，變成了初學者最容易迷路的環節。你會發現自己不知不覺地，掉進了兩種極端。
第一種極端：把設計當成別人的魔法。
如果你是團隊裡的一員，你可能會把「想解法」的工作，整個丟給設計師，期待對方變出一個完美方案讓你評論。
問題是，設計師沒有你手上的脈絡。你花時間驗證過的策略契合、用戶價值、商業價值——如果你沒有把這些限制條件講清楚，設計師只能憑空發想。
想像一下，你負責 Figma 的一個功能，要解決用戶「記不住留言」的問題。你請設計團隊發想解法，他們興沖沖地交出一長串點子——從簡單地加篩選器，到打造一個全新的留言收件匣。
但你心裡其實早就知道，這個專案的時間、資源都有限，你卻沒有事先告訴設計團隊。結果他們鑽進了一堆不可行、不值得做的點子裡——現在他們可能會覺得，你根本沒把限制條件講清楚就丟球給他們。這種挫折感，會慢慢侵蝕你們之間的信任。
第二種極端：自己下場當設計師。
另一群人走向另一個極端——他們覺得自己得親自主導設計，對設計團隊下指導棋，甚至早早鎖定一個自己心裡認定「對」的方案，要求對方照做。
這同樣行不通。你的專長不是設計本身，而是連接用戶、公司、設計團隊的那座橋。就算你真的很會設計，第一個冒出來的點子也很少是最好的——每個優秀的產品，都需要反覆迭代，甚至砍掉重練。太早鎖定一個解法，只會傷害你真正要解決的問題。
這兩種極端，都會導致同一個結果：設計品質下降、時程因為重工而拉長、你和設計團隊之間的信任慢慢瓦解。
有。這個做法叫做「有限制的發散」（constrained divergence）。
它的核心邏輯很簡單：在腦力激盪開始之前，先把你驗證過的三個機會元素——策略契合、用戶價值、商業價值——加上任何專案特定的考量，轉化成一組明確的限制條件。再把這些限制條件，事先傳達給設計團隊。
你可能會想：限制不是會扼殺創意嗎？
恰恰相反。限制不是牢籠，是護欄。當限制被正確定義，它反而讓團隊能更有信心地發散思考——因為你已經先幫他們封鎖了不值得探索的方向，他們能把全部的創意能量，投入在真正有意義的空間裡。限制聚焦腦力激盪，不是限制它。
限制條件分成三個類別——渴望性、可行性、可執行性。最好的解決方案，誕生在這三者的交集上。
渴望性根植於用戶價值，可以拆成兩個子類別。
核心功能限制，是解法必須具備的最低門檻——想像一份聖代冰淇淋，這就是那球冰淇淋。沒有它，整份甜點根本不成立。
拿 Gusto 舉例。這是一個幫中小企業處理薪資、招募、員工福利的平台。他們發現企業在幫新員工辦入職時，常常漏掉期限、輸入資料出錯。這轉化成一個核心功能限制：入職流程必須零錯誤，並且能追蹤截止日期。
差異化限制，則是聖代上的配料——巧克力醬、彩色米、櫻桃。這些是讓解法在替代方案之中脫穎而出的關鍵。
判斷差異化限制的門檻高不高，要看用戶現有的替代方案有多完整。如果替代方案很陽春（例如 Gusto 發現許多中小企業還在用 Excel 儲存敏感的員工資料），你的差異化門檻就低——安全的資料儲存，就足以讓你的功能立刻超越現況。但如果替代方案已經很成熟，你就得追求更高的用戶體驗，甚至是驚喜感。
可行性關注的是解法如何呼應公司的整體策略與目標。
以 Toast（餐廳管理平台）為例。假設你在打造一個「常客檔案」功能，讓餐廳能追蹤並行銷給熟客。從策略契合的角度，這個功能需要對整個餐廳生態系有利——對顧客來說，填寫檔案的體驗要快速順暢；對餐廳來說，顧客行為資料要容易彙整分析。從商業價值的角度，這個功能需要驅動 Toast 的核心營收指標——讓餐廳能用顧客資料發送獎勵和促銷，藉此提高回訪率，進而透過付款手續費為 Toast 創造營收。
可執行性直接跟專案本身有關，分成三種。
時間——你的專案可能有明確的截止日期。例如一家 A 輪或 B 輪新創，只剩 12 個月的資金跑道，這代表你的解法必須在 6 個月內上線，才能對下一輪募資造成影響。這會直接淘汰掉需要更長開發時間的方案。
資源——分成專案資源（你團隊裡的設計師與工程師人數）和共享資源（需要跨部門協調的專家，例如一位身兼多個專案的自然語言處理工程師）。
技術——你產品目前的技術架構，是否讓某些解法變得更難實現。舉例來說，假設 Webflow 想像 Figma 或 Miro 一樣，提供即時協作功能，避免用戶在跨團隊工作時遺失未儲存的變更。但要做到這件事，Webflow 得重新架構整個產品——這個工程量太龐大，技術現況因此變成了限制條件。判斷技術限制時，務必跟工程團隊討論，他們能快速告訴你技術到底會不會是關卡。
限制條件定義完，接下來要做的，是把它轉化成能激發創意的腦力激盪。這裡有三個關鍵動作：問對問題、鼓勵發散思考、把點子分群。
好的腦力激盪問題，主要錨定在渴望性限制上——因為它能確保點子直接跟用戶問題相關。你可以用這個模板：「我們可以怎麼做，來（解決某個渴望性限制），讓用戶（達成某個效果）？」
以 Airbnb 想改善房東行動裝置留言體驗為例，其中一個限制是「留言功能需要顯示已發送的訊息，並跟網站自動同步」，轉化成的問題就是：「我們可以怎麼讓行動裝置更準確地顯示資訊，讓房東願意經常使用它跟房客互動？」
寫這類問題時，記住三個原則：把負面陳述改寫成正面目標、聚焦在體驗而不是解法本身（太早鎖定解法，你就會不小心變成前面提過的「指導棋」型 PM）、把相似的限制合併分組，讓腦力激盪更聚焦。
Crazy Eights 是個經典練習——針對一個「How might we」問題，在 8 分鐘內想出 8 個不同的解法。你可以在 Figma、Miro 等工具裡輕鬆找到現成模板。
這正是 Claude AI 能派上用場的地方。 把你定義好的限制條件和「How might we」問題丟給 Claude，請它幫你生成初步的點子清單、模擬不同角度的解法，甚至幫你檢查某個點子是否偏離了限制範圍。這能讓你的腦力激盪會議，一開場就有紮實的素材可以討論，而不是從一片空白開始。
但別忘了：Claude 生成的點子，只是起點，不是終點。哪個方向真正值得深挖，還是得靠團隊的判斷力，還有你對用戶脈絡的理解。
腦力激盪結束後，你手上通常會有一堆點子，裡面藏著重複、模式、主題。這時候，把點子分群，是準備進入下一階段「迭代收斂」的關鍵。
常見的分群方式有三種：依照產品的介面區塊分群（例如依照不同的頁籤或頁面）、依照用戶類型分群（例如小型團隊 vs. 大型企業客戶）、依照漏斗階段分群（例如提升轉換 vs. 提升留存）。
以 Airbnb 為例，經過限制條件下的腦力激盪，團隊產出了 17 個解法點子，最後歸納成 6 個廣泛的解法群組——資訊架構與版面、收件匣效能、收件匣新功能、行事曆頁面功能、跨功能整合、統計頁面優化。這正是 Claude 能幫上忙的另一個環節——把一長串零散的點子丟給它，請它幫你辨識重複的主題、草擬初步的分群架構。這能把原本要花上好幾小時的整理工作，壓縮到幾分鐘內完成，讓你有更多時間，專注在判斷哪個群組最值得優先推進。
發散完成，只是功能設計的第一步。接下來的迭代收斂，你需要跟設計團隊緊密合作，依照渴望性、可行性、可執行性三大限制，篩選、排序這些分群後的點子，把它們轉化成原型並反覆測試——決定用什麼精細度的原型、怎麼主持測試、怎麼把學到的東西轉化成設計產出。
收斂完成之後，最後一步是取得核准與建立對齊。你需要跟設計團隊一起，向產品和設計領導層爭取核准，並且跟核心團隊、跨部門利害關係人對齊最終設計。這個階段，最好把最終產出，連同背後的原則和思考過程一起分享——這能避免團隊、工程師、其他利害關係人，因為不認同背後的邏輯，而在後期製造不必要的重工。
知道流程還不夠。實際執行時，新手常常會掉進這幾個陷阱：
這些陷阱背後，其實只有一個共同根源：把「感覺對」，當成了「驗證過」。 有限制的發散，正是逼你把每一個假設攤開來檢驗的紀律。
走完這一輪流程，你應該已經看出功能設計真正的邏輯：發散、收斂、核准，三個階段環環相扣，缺一不可。
Claude AI 能在發散階段幫你生成點子、分群整理、加速腦力激盪的效率——但真正決定哪個限制條件最關鍵、哪個點子值得深挖、哪個方案該拿去核准的判斷，永遠得靠你自己。
下次你準備打開設計工具，或是叫 Claude Code 開始寫程式之前，先問問自己：我的渴望性、可行性、可執行性限制，都定義清楚了嗎？我的團隊，知道這些限制嗎？
最好的功能設計，從來不是從一張空白畫布開始的。是從一組清楚的限制開始的。
功能設計的三個階段，通常要花多久時間？
視專案規模而定。小型功能可能幾天內就能走完發散、收斂、核准三階段；大型或跨部門的功能，可能需要兩到三週，涵蓋多輪原型測試與利害關係人對齊。
我完全沒有設計背景，也能主導功能設計嗎？
可以。你的角色不是取代設計師，而是提供清楚的限制條件，讓設計團隊能更有效率地發揮創意。搭配 Claude AI 整理限制、草擬「How might we」問題，你不需要懂設計技巧，也能扮演好這座橋樑的角色。
如果不先定義限制，直接讓團隊自由發散，風險是什麼？
最大的風險，是團隊花時間探索了大量不可行或不被需要的方案，導致重工、時程延誤，甚至因為缺乏共同基準，而在事後產生分歧與不信任。
Claude AI 在功能設計的哪個階段最有幫助？
發散階段最明顯——它能根據你定義的限制，快速生成點子、模擬不同角度的解法，並協助把大量點子分群整理。但收斂階段的優先排序、以及核准階段的溝通，仍然高度仰賴人的判斷。
這套功能設計流程適合什麼樣的人學習？
任何正在把驗證過的用戶問題，轉化成具體解法的人都適用——不管你是團隊裡的產品經理、設計師，還是正在用 Claude 獨力打造軟體產品的初學者。
iThome鐵人賽
看影片追技術