03 The apparent problem probably isn’t the real problem.
顯而易見的問題可能並不是真正的問題。
《好產品的設計法則》
書中作者講了這個例子：
設計師接到設計委託案，要為不願意直接接觸狗便便的飼主設計一個更好的便便鏟 (better pooper-scooper)。
這很合理，因為
- 問題：不願意直接接觸狗便便。
- 解方：設計一個不必碰到狗便便的工具。
但，這是真的問題嗎？
But research might reveal that owners simply forget to take bags on their walks. A new scooper would not solve this problem.
研究之後或許發現，或許是飼主外出溜狗時忘記帶便便收納袋出門，就算新的便便鏟也不能解決問題。
So the problem must be reframed as one of placing bags where dog walkers need them-perhaps within the leash handle, in a dispenser at the dog park, or at key locations on city streets.
所以這個問題必須重新定義 (專有名詞為『重構』) 問題：
如何將便便收納袋放在遛狗者需要的地方？
也許是在狗鍊把手裡面有空間放，或是在寵物公園或市區內的重點區域內的站點。
作者的結論是這樣：
An apparent problem is usually a symptom of an underlying macro-problem, and sometimes of an entirely different issue.
顯而易見的問題，通常只是宏大問題的外顯現象，有時其所牽涉的可能是截然不同的議題。
我的經驗
其實這一則讓我想到的是「重構問題」這個主題。
線性地把看到的問題和可以解決的方式連繫在一起，看似很有道理，實際上可能一點作用或幫助也沒有。
例如，
- 問題：一個便當我吃不飽怎麼辦？
- 解方：那就再多吃一個。
重構問題需要的是洞察，讓人一看到/聽到就點頭稱是的洞察，一點都不容易。
很多時候，包括我自己在做專案的時候，雖然不是每次都能重構成功。就算提出也會被客戶無視或提醒：
你可以做我們要你做的就好了嗎？
但，總要試試，對吧。
另外，重構問題常用的手法是用 How Might We (HMW，我們如何…)。這個工具我常在專案一開始的第一次接觸就會採用。顧客訪談用，企業訪談也用，總之就是列出許多則 HMW，然後再來挑選。
以上述狗便便案例來說，避免線性一對一的「問題」vs.「解方」思考模式，HMW 就是一個破框 (break the frame) 的利器。
