我如何用設計思考陪伴團隊解決問題（下）

上一篇：我如何用設計思考陪伴團隊解決問題（上），我跟你分享：

• 爲什麼我不建議用設計思考，一次性解決很大的社會問題
• 我如何判斷團隊所處的「行動脈絡」、「團隊所處的階段」，調整引導手段

這週，我沿著上週內容，跟你分享更多「以設計思考，陪伴團隊解決問題」的方式，以及我的觀點

為什麼是「設計思考」？

你可能會想知道「為什麼大家那麼愛談設計思考」？

我認為關鍵是，設計思考每個步驟，都有「能解決問題」的有效工具

• 想要了解使用者碰到什麼問題？訪談、觀察
• 想要定義使用者的真實問題？POV (Point Of View)、行為模式圖
• 想要創意發想？瘋狂故事接龍
• 想要測試自己的點子是不是真的有效？原型測試+迭代

設計思考，就是一個「大型工具箱」。我們會依據情境，從裡面挑選工具來組合使用，就像很多人曾被反鎖在家門外，只好請鎖匠來開門的經驗，概念是相近的

我上一次把自己反鎖在門外，就馬上打電話求救鎖匠大哥。看著他用一些方式研究鎖孔，並且很快地從他的工具箱中掏出看起來很厲害的工具，30 秒以內就俐落完成開鎖

設計思考教練也是這個角色，我們會聽完團隊的問題，簡單問幾個問題釐清狀態，就會馬上生出協助團隊推進進度的「工具」，現場開始示範、教學

對 TA 越了解，解方越可能「真的解決問題」

在商業競賽、社會議題行動計劃中，如果我是中間才加入協助團隊，且我看到團隊已經產出一個解決方案，我的第一個問題是「這個解方感覺很棒，但想先好奇你們是怎麼做出來的？」

這問題的目的是，了解團隊對於使用者的認識程度

就像一組大學生團隊想解決貧窮議題，跟耕耘好幾年的人生百味比起來，對於「貧窮議題」的認識一定有差別。這問題會很直接幫助我知道，團隊是基於什麼觀點、脈絡，判斷這個解方本身，是「猜來的」、「拼出來的」、「拼出來且已經測試過的」還是「一步一步長出來的」

差別在哪？

• 猜來的：對使用者認識少。團隊可能因為沒時間、沒手段、沒資源找受訪者、發現受訪者的問題不是問題、受訪者答非所問⋯⋯等，團隊還沒找到好的「解決問題著力點」，但又受限於資源有限，因此先隨便想一個解方出來，賭賭看這會不會討評審、使用者喜歡
• 拼出來的：團隊對使用者有一定程度的認識，通常有做過一些使用者研究，收斂幾個方向，並且有明確且完整的故事。但團隊生出來的解方，還不一定有完整測試跟迭代，因此迭代跟碰壁的過程，在未來不會少
• 拼出來且已經測試過的：這通常是已經走一陣子的團隊，碰過挫折、但也在問題上努力一陣子，因此有不錯的經驗跟故事，他們在解決問題這件事上也長出自己的心得，已經有一定基礎
• 一步一步長出來的：團隊有「明確的」依據，說得出為什麼解方能「真的」解決問題。團隊很認識自己的「使用者」，包含做研究、做訪談，並且長出自己的解決方案後，拿出去測試過一輪，並也迭代過了。在我的經驗中，已經做到這個程度的團隊，很多都已經是「創業團隊」

上面文字有點多，但總結很單純，團隊越認識要解決問題的那一群人，也就是「使用者」，就越有機會找出能夠解決使用者的方式

視覺化介面：同步想像

設計思考有效的關鍵之一：「視覺化介面」

視覺化介面，幫助團隊處理「同步團隊對於同一件事的想像」

有一個很簡單的例子是，「請團隊畫出要解決問題的使用者樣貌、特徵」

剛起步的團隊，一定每個人都畫得不一樣、描述也不一樣，這是很正常的事情。因此，設計思考的「視覺化介面」，就可以很好地幫助團隊建構討論的基礎點，不會每個人想的都不一樣

視覺化介面：建構流程

延續上一點，在「設計」設計思考工作坊的時候，會考慮到「流程」這件事

流程不只是什麼時間點要做什麼事情，也包括團隊討論的視覺化「流程」，像是下圖

團隊會從一個端點開始討論，比如從左到右，一步步展開要做的事情、成果

今天團隊訪談完了，那就從一片大白板：整理訪談資料開始，提出事實、假設，畫出 Persona ，畫出使用者旅程地圖等等

接著挪到中間，開始定義使用者真正的問題，過程中可能會在白板上不斷劃線、分析，就像上面那張圖一樣，大家會邊討論邊走來走去，看著不同的整理、彼此提出的觀點，深度討論

今天團隊到了下一個階段，有了產品且開始測試，那上面的「流程紀錄」，也會很有效幫助自己在需要的時候，隨時回顧團隊歷程，確保方向不失焦

結論

雖然是下篇，但這兩篇只涵蓋我的少數經驗而已，未來我還會再針對設計思考的主題，分享不同知識跟觀點、經驗！

如果我很幸運，能讓您看完這篇落落長的內容，請不吝回覆我，分享您的心得！或是對於內容想了解更多、提問，也歡迎寄信到我的 Mail: ashan204054@gmail.com

PS. 這篇是我這週的電子報內容，且我同時也有在經營 Threads、一個 400+ 人的永續工作者社群。