這篇文章整理的是我在數位產品設計（UX / Product Design）中，處理模糊需求時的思考方式。
在實務上，設計師最常遇到的問題，通常不是「沒有需求」，而是「需求很模糊、彼此矛盾，或無法直接轉成設計結構」。
相信大多數的設計師都有遇過類似的情境，接收到的需求看起來是明確的，但實際執行的時候卻頻繁遭遇變化，像是經常更改定義過的規則、用戶流程頻繁修改、畫面來回調整，有時甚至是在已經進入開發後，還在討論「這個到底要怎麼做」...等。
這不一定是設計師能力不足，有可能是這個需求主要解決的問題，在一開始就沒有被定義清楚。當問題本身是模糊的，後面的每一個決策都只是在不穩定的基礎上微調，自然很容易反覆。
舉個例子，當你接收到「提升購買後，填寫評價的操作體驗」的需求，這看起來好像是一個很具體的任務，但在你做了你認為可以提升體驗的設計改動後，在 design review 中還是收到上級不滿意的反饋，認為你是設計師怎麼沒考慮到這些情境。
設計師們很容易直覺往「是不是我哪裡沒想周全」去反思，但或許也可以換個角度思考看看：這個需求真正想解決的是什麼？
- 是「填寫評價的過程不順」？
- 或是「用戶沒有動機留下評價」？
- 還是「評價數量影響了商業指標」？
如果連問題的層級都還沒有被對齊，那設計再怎麼優化，都很容易被重新拉回來討論。
如果你是個正在提升自己視野和位階的設計師，不妨思考一下，你是否可以在設計之外，多做一步，幫助團隊把問題定義清楚。我整理在不同專案中反覆遇到這類情境的經驗，歸納出在面對模糊需求時，會做的幾個梳理方向：
釐清問題
挖掘需求背後的問題，確認現在要解的是哪一層面的問題。
同一個需求，可能同時包含用戶體驗、轉換、商業策略的目標等，如果沒有先釐清，很容易在執行過程中不斷被不同角度拉動。
收斂雜訊
從既有資料、行為觀察，以及不同角色的回饋中深掘洞察。
這個階段的狀況是雜訊很多，但彼此之間可能沒有關聯或互相矛盾。比起把所有意見都納入，更重要的是找出「反覆出現的問題模式」，以及哪些只是單一情境下的觀察，排除雜訊後才能在用戶的共同問題中找到核心的解法。
建立架構
利用流程、圖表或簡單的結構整理，將原本模糊的描述轉換成可以被討論的項目。
這一步不一定是完整的設計產出，更多時候是進入規劃期的定錨，透過可視化的圖表與資料，能更好的讓團隊可以對齊聚焦：現在在解的是哪一段流程、哪一種情境、優先順序是什麼。
在這樣的過程中，設計的角色其實會稍微往前移動一些，不單單只是回應需求，而是參與「這個需求到底在解什麼」的釐清過程。當問題被整理到一個相對清楚的狀態之後，後面的設計與決策，也會變得穩定也容易很多。
