需要一個廣泛且通用對設計的定義嗎？

June 25 17:04~18:20

 

某學弟Spirit Du看完《設計的定義》，在留言區提了一個問題：其實我們需要一個廣泛且通用對設計的定義嗎？這個問題對Teddy在《設計的定義》文中鬼扯了一堆的有的沒的內容提出一個根本性的質疑：Why？幹嘛吃飽沒事幹寫這些有的沒的？

這是一個很好的問題，正所謂「Quality Without A Name」，設計不就是…設計…嘛，當你自己做過設計，接觸到設計的產出物，你就知道設計是什麼了。更何況設計的形式與標的物種類繁多差異性又很大，例如建築設計、室內設計、軟體設計、互動設計、節目設計、對話設計、仙人跳設計…等等，怎麼可能整理出一個廣泛且通用的設計定義呢？就算可以，這種定義，有用嗎？

***

Teddy的經驗告訴自已，正因為設計的領域、方法、策略、思考模式各不相同，因此更應該整理出一個廣泛且通用的設計定義或概念框架，以便拿來學習與容納各種不同的設計方法或理論。舉個例子，Alexander提出的context、form、force這些概念，原本是用來解釋建築或都市設計。同樣一套方法，拿來解釋軟體設計，行得通；拿來設計使用者介面，也行得通。用Alexander的方式來設計軟體架構Teddy已經提過好幾次了，這裡有一個影片，是37signals的設計師Ryan Singer分享如何用Alexander的方法來設計web-based應用程式的使用者介面，內容非常精彩，推薦給鄉民們欣賞。

再舉個例子，今天假設鄉民們不小心聽到了Design Thinking（設計思考）或是Service Design（服務設計）這兩個「名詞」。一種最直接的學習方式是去理解這個領域的人如何介紹Design Thinking與Service Design。學習一個新的知識，光是要入門就需要一些時間。如果要變成專家，那所耗費的時間更不易估計（至少也要《一萬個小時的練習》吧）。今天如果鄉民們有一種方法，可以新學到的東西，與自己熟悉的事物建立起關聯性，那麼學習的效果將會變得很好，不但新的事物不易忘記，還可以沿用原本的經驗到新的領域中。

***

今天上午Teddy和同事到導入Scrum的客戶端進行觀察與訪談，訪談結束之後，Teddy就套用Alexander的方法，請同事分析輔導團隊所面對的問題、影響這些問題的作用力（force）。最後，Teddy詢問同事：「假設你是團隊的ScrumMaster，你會建議採用哪種方法（form or solution），來協助團隊平衡這些作用力」。

同樣一套方法，一魚多吃，Teddy自己就應用到軟體（架構）設計、介面設計、Scrum導入、問題分析，還有早年的e-learning領域中。現在則是想要繼續套用「吸星大法」，把Design Thinking吸入這個框架裡面。但因為時間有限，所以「吸」的速度很慢，目前只吸到皮毛而已。

***

結論就是：發明USB的人真的滿偉大的。

***

友藏內心獨白：這樣還可以避免被一堆流行名詞一再打臉。