設計思考是什麼？

這篇文想用一個清楚明瞭的視角，跟你分享「設計思考」到底是什麼，以及可以如何運用在個人、組織的日常中！

設計思考到底是啥？為什麼那麼多人喜歡用它？

設計思考是一個「以人為本、創新、解決問題」的方法論，已經被廣泛運用在各行各業，最知名的莫過於是 IDEO 這間創新顧問公司，以及 Stanford d.school。

設計思考這麼盛行的關鍵之一是，設計思考五步驟的每個步驟，都有能夠對應「解決問題」的有效工具。

用我最熟悉的五步驟來說明：同理、定義、發想、原形實作、測試。

設計思考第一步：同理

設計思考的第一步「同理」，是透過訪談、觀察等方式，認識我們要解決問題的使用者「輪廓」。

在這過程，我們會依據專案目標，搭配不同的工具，像是同理心地圖、顧客旅程地圖、人物誌、等工具，具體描繪出我們想研究的「使用者」樣貌。上述提到的工具，都有很明確的使用情境、目標。

這幫助團隊不只是「我們看了網路文章，覺得這群人的真正問題是⋯⋯」、「我們跟對方聊了十分鐘，覺得他們需要⋯⋯」，而是「我們在對方的某段對話中，發現他背後的需求可能是⋯⋯」、或是「我們發現在他做這件事的過程中，有個地方怪怪的，因此我們推測他的需求可能是⋯⋯」

以「人物誌 Persona」這個工具而言，就是一個「用來描繪議題利害關係人」的好工具，經過訪談、觀察之後，我們會得到許多對不同人的資訊，再將這些資訊的共同點萃取出來，成為我們進到下一階段「定義」的基礎背景資訊。

（當然人物誌的概念遠不止於我上面的描述，這邊簡單介紹哈哈）

設計思考第二步：定義

當我們透過訪談、觀察，使用各種工具建構對於「使用者」的樣貌，過程訪談很多人、紀錄夠多，或甚至團隊本身就是自己議題的「使用者」時，接著我們就可以用 POV (Point Of View) 、事實與假設等等方式，進一步收斂並聚焦使用者的問題，成為能夠行動的「問題著力點」。

我自己最常使用的工具是 POV，這個工具乍看只是一句話：

「OO （有生動描述的使用者），需要 OO ／需要一個方法來回應 OO（需求），因為在他的世界中，OOOO 很重要（洞見，需求背後真正原因）」

看似是簡單的一句話，但在解決真實世界的議題，這句話往往代表很多種行動、解決問題的出發點可能性。

因此，我在帶工作坊時，會跟團隊，以不同例子，分享「什麼是好的 POV」，「什麼是團隊會動不了的 POV」。我會在另外一篇文章，跟你分享什麼「什麼是好的問題觀點」！

設計思考第三步：創意發想

設計思考其中一個特色，是強調「創意思考」。不可能第一個點子就能夠完美符合使用者的需求和期待，一定需要大量的淘汰、篩選。

設計思考非常強調以「大量且天馬行空的點子」，來試著回應我們上一階段「收斂並定義後的問題」。

在這個階段的前期，我們不會批評任何人所提出的點子。是因為發想點子 vs. 評估點子，這兩件事情在本質上互相衝突。我們沒辦法一邊評估點子的好壞，一邊想出超瘋狂的點子。

我會使用「瘋狂故事接龍」！

「瘋狂故事接龍」舉例：請大家在三分鐘內，以「小明早上九點出門」作為開頭，「小明最後不小心跟一千年後的曾曾曾曾曾曾⋯⋯孫女結婚了」作為結尾，並且想辦法讓這中間的故事情節合理

等到團隊進入了「創意發想」的模式，就能進入正題，開始發想創意解方來試著回應前面定義階段的「POV」！

不可否認，有些人就是天生鬼點子特多，旁人完全抓不到他的腦迴路構造。

但其實，能夠想出創意點子這個特質並不是「天生的」，很多時候來自「有沒有進入允許瘋狂發想的環境」、「有沒有相互疊加點子」、「有沒有看過夠多很棒的例子」哦！

設計思考第四、五步：創意發想、測試

「原型實作」強調「用最小的成本，取得最快的失敗，並從中學習」。

在發想階段，需要盡可能產出「很多的點子」，並且用一些標準來篩選出團隊想往下發展的點子，進入到「原型實作」的階段。

因為你一定不想花大錢，做出「不能用的東西」。

在解決問題的初期，我們找到的受訪者、定義的問題、發想的解方，通通都不一定是「真的」，若我們發想完解決方案，就馬上砸大錢、花時間做出來，但最後發現這根本不能解決問題，那就會很尷尬。

在原型實作階段，相對重要的一定是「快速把 Prototype 搞定」，並且找到使用者來進行測試，回答「我們做出的 Prototype，到底是不是使用者要的？」

如果用設計思考的術語，就是這東西能不能回應，我們在定義階段收斂出的「需求、洞見」？

設計思考第六步：迭代

什麼？你不是說設計思考只有五個步驟嗎，怎麼現在突然有第六個步驟了？

設計思考不只重視完成前五個步驟，更重要的是第六個潛在步驟：迭代。可以說如果團隊沒有迭代，就不可能有成功的產品。沒有任何成功的產品是沒有經過迭代的。

迭代會在什麼時候進行？

在原型完成後，收集市場回饋，再回頭檢視整個流程——訪談是否足夠、問題定義是否正確且精準、點子是否需要增加、修改、原型是否到位？

要迭代什麼？具體來說，我們進行使用者測試後，收到了許多有價值的回饋，這些回饋，會分別隸屬於不同的「迭代方向」：

• 「我想像不到自己會在什麼情境下用到這個東西」：製作方向完全錯誤、或是完全解決錯誤的問題
• 「我會用，但如果能加上某些功能會更好」：有解決到問題，但在點子、原型完整度上還能更好
• 「很醜，但還算能動、能用」：UI 、外觀問題，可以多問其他回饋方向
• 「如果增加 OO 功能，我會願意試試看」：跟第二點一樣

我們可以從點子發想、原型實作，到測試過程中，判斷之後應該往哪個方向調整。

如果使用者回饋說「這東西根本沒辦法用」，那可能代表我們一開始就定義錯問題、找錯需求，甚至這個問題根本不存在，這時就需要回頭重新理解問題本身，甚至團隊重新對焦需求。

如果使用者說「我會用，但…」，那表示方向是對的，只是產品還需要微調——也許是功能要補強、體驗要改善。這時我們可以回到原型設計或早期製作階段，針對這些具體建議做優化，讓產品更貼近使用者需求，真正被市場接受。