l

2013年6月24日 星期一

把Design Thinking放入Scrum與Pattern之中

June 21 15:20~17:15

image

 

最近幾個月在不同的場合有機會跟幾位「介面/互動設計」領域的朋友聊天,不知道為什麼這些所謂的「設計師」總是不約而同地談到「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並沒有規範。

螢幕快照 2013-06-21 下午4.01.25

 

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

螢幕快照 2013-06-21 下午4.04.41

***

把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畫了一張 曠世巨作 圖:

螢幕快照 2013-06-21 下午4.37.57

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

***

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

***

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

沒有留言:

張貼留言