把Design Thinking放入Scrum與Pattern之中

June 21 15:20~17:15

 

最近幾個月在不同的場合有機會跟幾位「介面/互動設計」領域的朋友聊天，不知道為什麼這些所謂的「設計師」總是不約而同地談到「Design Thinking」這個名詞。在聊天的過程中，Teddy試著從設計師朋友的描述中來建立起對於「Design Thinking」的了解。但每次聽完之後，腦袋中只記得以下幾個名詞：以人為本、同理心、創意、洞察力、使用者需要、發想、腦力激盪、不要批評、發散、點子越多越好、不要考慮實作限制、分類、收斂、快速原型實作、驗證。

每次聽完之後Teddy內心總是湧現一個小小的吶喊：「然後哩？」這些東西不就是「腦力激盪」加上「快速原型實作」，然後冠上「以人為本、以使用者為中心」這個好聽又不跳針的口號。「Design Thinking」到底解決了產品生命週期那幾個階段的問題？原型做出來之後設計就完成了嗎？後續實作這一段是不是就不關「Design Thinking」的事?

***

後來斷斷續續花了一點時間翻了幾本「Design Thinking」的書，可能是沒選對書，總覺得沒什麼fu。但既然「Design Thinking」這個方法在「設計師」領域這麼流行，想必應該有它的獨到之處…吧（在否定之前自己要先實踐《傻的願意相信》的精神）。今天Teddy從Scrum與Pattern的角度，試著把「Design Thinking」裝在這兩個框架裡面，這樣子嘗試看看自己以後會不會對於「Design Thinking」比較有fu一點。

 

把Design Thinking裝在Scrum裡面

下圖是Scrum活動與產出物的概念圖，在Scrum框架中，需求是由Product Owner（PO）負責管理，至於PO如何從Vision「生出」需求，Scrum並沒有規範。

 

一般的概念是，PO從stakeholder與開發團隊獲得產品的需求。PO可以用傳統的訪談與觀察方式來獲得需求，或是依靠自己的經驗來產出需求。但是如果所要開發產品的需求並不明確，或是PO本身對產品的需求掌握度不高（可是能老闆只有一個大略的概念，例如要開發App或是提供某種雲端服務），這時候就可以結合「Design Thinking」，將其應用於需求或創意發想，以便產生專案的Product Backlog（產品需求清單）。

***

把Design Thinking裝在Pattern裡面

原本Teddy也沒發現「Design Thinking」和Alexander的pattern理論有何關係。在寫了《關於設計與品質的抽象思考》之後，今天又重讀了維基百科上面解釋《Design thinking》的文章，對於兩者的關係，突然有點fu了。

以下是維基百科對於「Design Thinking」解釋的第一句話：

As a style of thinking, design thinking is generally considered the ability to combine empathy for the context of a problem, creativity in the generation of insights and solutions, and rationality to analyze and fit solutions to the context.

讀完這句話之後Teddy畫了一張 曠世巨作 圖：

對於問題發生的環境（context）要有同理心，對於解法要有創意（form就是solution）。要能夠洞察問題與影響解法的作用力（force），如此才能平衡這些作用力，以設計出好的作品。最後，把整個設計結果視為整體（包含context與form），要能夠驗證這個設計產出物的合理性。

***

結論就是，要變成武林高手，除了修練「九陰真經」或「九陽神功」以外，有點「吸星大法」的底子，也是滿受用的。

***

友藏內心獨白：設計師應該要尋找自己收納知識的框架。