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

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的人真的滿偉大的。

***

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

想到銀河英雄傳說

June 26 21:41~22:52

「楊威利」名言：

• 政治腐敗並不是指政治家收取賄賂之事，那是個人腐敗而已。政治家收取賄賂，卻沒有人能加以批判，這就是政治腐敗。
• 社會有兩種思潮。一說真理比生命重要，一說生命比任何事都重要。當人類要發動戰爭，會以前者為借口；要結束戰爭，又拿後者作理由。

***

今天晚上Teddy陪朋友去醫院回診，由於約診號碼是6號，所以想說早點到醫院，等看完醫生之後再吃晚餐。19:30左右到達醫院，發現看診號碼已經跳到16號了，趕緊敲門跟護士報到。沒想到護士開門之後說：「醫生不在，人在急診處」，沒再多說什麼就把門關起來了。看了看門上的掛號單，沒想到今天晚上掛號的人只有6位。疑，那電子號碼跳到16號什麼意思？

不管了，既然醫生去急診支援救人，那就乖乖地在外面等吧。過了約5分鐘之後，醫生回來了，看了一個病人之後，人又消失。嗯，應該是又趕去急診救人。繼續等了10幾分鐘，越想越不對。因為不知道醫生在急診會忙多久，一直傻傻等下去也不適辦法。想說先去吃飯，晚點再回來。離開前先通知一下護士小姐，告知他我們大概21:00回來，沒想到護士小姐居然說：

醫生在急診值班，要值班到22:00。

Teddy內心獨白：什麼，在急診值班，不是在急診救人？

Teddy：為什麼醫生有排門診卻又跑去急診值班？

護士小姐：不好意思，因為我們醫院找不到急診醫生，只好讓醫師去急診值班。

Teddy：問題是你們的醫生有排門診，現在卻又跑去急診值班，那請問要看門診的病人怎麼辦？難道我們要等22:00醫生急診值班結束之後再來看門診嗎？

護士小姐也是很為難，情急之下她請我們等一下，她跑去急診處找醫生。過沒多久醫生回到門診處，看不到2分鐘就結束了（PS：急診處離門診的距離大約20公尺而已）。

Teddy不知道門診醫生同一時間跑去急診值班是否符合衛生署的規定，但除非醫生練就「分身術」的本領，否則這種作法應該不太合理吧？

***

不知道鄉民們有沒有看過《銀河英雄傳說》這部小說、漫畫、或是 卡通 動畫。《銀河英雄傳說》的動畫Teddy在N年前看過好幾次，依稀記得其中有一集提到「楊威利」從「伊謝爾倫要塞」還是哪個外太空回到自由行星同盟首都「海尼森」。當時楊威利和隨從一起搭車要到某處，在途中遇到大塞車。隨從詢問路上指揮交通的警察為什麼會塞車，得到的答案是：「因為瓦斯管線年久失修，所以發生爆炸」。

楊威利聽了之後很感慨，於是對身邊的隨從說：「多年來與帝國的戰爭，不但耗費了自由行星同盟大量人力與資源，連帶造成官僚系統的僵化與腐敗。從基礎建設缺乏維修資源，便可看出危機的端倪」（以上敘述可能與實際內容有些出入，不過大意應該是如此）。

***

一個國家、社會、社區、家庭、乃至於個人的衰敗，通常不是一夕之間造成的。從「門診醫師被抓去急診值班」這的事件，感覺好像可以預料到台灣的未來，在某種程度上跟「自由行星同盟」還真有點類似。

等一下，「自由行星同盟」最後的下場是…被「新銀河帝國」給統一了。

***

友藏內心獨白：希望Teddy的烏鴉嘴這次不要靈驗才好。

軟體架構也可逐步成長（6）：Piecemeal Growth的啟發

June 0 21:37~23:08

 

Teddy在《軟體架構也可逐步成長（5）：Piecemeal Growth》這一篇未了留下了一個伏筆：

請鄉民們先思考一下，Piecemeal Growth的三個子規則，與軟體開發活動有沒有對應關係？如果有，這些對應關係是什麼？這三條子規則對於平常的軟體開發與架構發展有沒有幫助？

幾天過去了，不知道鄉民們針對以上問題有沒有什麼看法？今天來談討一下將Piecemeal Growth這三條規則應用在Scrum敏捷開發方法中，如何支持軟體架構逐步成長的作法。首先複習一下Alexander幫Piecemeal Growth列出的三條子規則：

• 任何單一的建築增長計畫規模不可太大。
• 混合合理大小的建築增長計畫。
• 建築功能的分配要合理。

***

現在把節目場景轉到Scrum身上，曾經採用過Scrum的鄉民們幾乎都會遇到相同的問題，那就是「在Scrum或是其他敏捷方法中，何時設計軟體架構？」Teddy在《Iteration 0 要幹麼？》介紹過一種「偷吃步」的方法，在專案正式開始之前，先偷偷地安排一段不太長的時間來設計軟體架構。但這種作法許多「敏捷狂熱分子」是不屑採用的，他們不贊成事先安排一段時間來做所謂的專案啟動前的準備。但無論如何，當組織與團隊還「不夠超級敏捷」的時候，實務上iteration 0也不失為一種可行的方案。

另一種理想的狀況是，團隊並沒有事先花費額外的時間來設計或規劃軟體架構，而是靠著一個、一個story的完成，讓軟體架構逐漸慢慢成形。

從以上兩種做法，可以觀察到兩個相衝突的force（作用力）。

• 只要需求不變，事前花越多的時間設計架構，事後重改的機會就越少。但只要需求改變，有可能導致架構改變，事前設計所花的時間可能就白費了。
• 因為需求一直在變，所以不要花（太多）時間做事前架構設計。但是讓架構隨著需求實作而慢慢成長，長壞掉需要打掉重做的風險又很高。

問題的關鍵點是，要如何在這兩者之前取得平衡。

***

鄉民甲：看到這邊還是不知道敏捷專案的軟體架構設計和Piecemeal Growth的三條子規則有何關係？

Teddy：恭喜老爺，賀喜夫人，此為正常現象。

請再看一次這三條子規則：

• 任何單一的建築增長計畫規模不可太大：如果真的需要事前花時間設計軟體架構，那麼「單一回合」所設計出的軟體架構涵蓋範圍不可太大。例如，一個6個月的專案，如果連續花2個月的時間在設計軟體架構上，感覺耗費的時間就太長了。如果每一個為期6個月的開發週期，安排1~2週來決定初始軟體架構的雛形，這樣的大小感覺比較合適。
• 混合合理大小的建築增長計畫：一個系統設計是好是壞，不光只是由選擇軟體架構這種 「大尺度」的設計決定，還包含模組化與物件導向設計的程度、設計模式的套用這種「中尺度」的設計決定，以及類別設計、函數或方法（method）設計、命名等「小尺度」的設計決定。專案要合理分配花在這三種尺度的設計時間，把全部時間都花在大尺度的「架構設計」，而忽略了模組化或是變數名稱等中、小型設計議題，最終的軟體設計品質也不可能會好。只關注物件導向設計原則、單一類別設計、每個函數要寫幾行、變數怎麼取名等中、小型設計議題，忽略了大的軟體架構，當然整體的設計品質也不可能會好。
• 建築功能的分配要合理：最後這個概念，有點像是「end-to-end story」的味道（請參考《End-to-end stories：鄉民要求篇》），或是RUP（Rational Unified Process）提到的「Use-Case Driven」的概念（使用案例驅動系統與架構的成長）。翻成白話文就是說，透過完成story的方式來讓軟體架構逐步成長的過程中，story要橫跨架構的每一個層面，不能只涵蓋某一個階層（layer）。換句話說，儘量不要用functional team或component team的方式來成長你的軟體架構（關於functional team的說明，請參考《Scrum框架下的跨界開發(4):分組方式》）。

***

以上，看起來像是天書，但只要經歷過「軟體架構逐步成長」過程的鄉民們，多多少少應該可以體會Teddy解釋的這三點精神。如果還是不行但是又想要學的話，只好等Teddy以後有空開「軟體架構逐步成長設計課程」的時候再來報名了。

***

友藏內心獨白：這種偏門的課，可能要排到民國XXX年。

設計的定義

June 24 15:30~16:54

 

去年寫了一篇《設計、設計》，文章中提到不同領域的人對於「什麼是設計」有著不同的看法。由於不同領域的人都用到「設計」這個詞彙來描述不同的方法、流程、與產出，要得到一個大家都可以接受關於「設計的定義」，真的很難。有些定義，例如「設計是漂亮的解法」、或是維基百科上面的定義：「設想和計劃，設想是目的，計劃是過程安排」，讀完之後還是沒什麼fu，這樣的定義感覺幫助不大。

最近因為寫了《關於設計與品質的抽象思考》與《把Design Thinking放入Scrum與Pattern之中》，加上重讀了Alexander的《Notes on the Synthesis of Form》，對於「什麼是設計」的輪廓覺得有比較清楚一些。在《關於設計與品質的抽象思考》中，Teddy介紹Alexander對於設計的看法：

***

一個設計問題必須考慮兩個元素：

• Context：環境，定義問題（the context defines the problem）。
• Form：形式，問題的解（the form is the solution to the problem）。

Form是問題的解答，而Context限定了問題。當討論到所謂「設計問題」的時候，考慮的對象不僅僅是form本身而已，而必需要考慮form與context所組成的「整體」。當設計師以某種方式將「整體」分為form與context的時候，如果這個form可以良好地適應於context之中，那麼我們就認為這個設計符合我們對於「品質」的期待。

***

既然好的設計可視為「form與context的良好適應關係」，那麼「設計的定義」是否可視為「決定form、context，以及兩者之間的關係」？

***

昨天同事告訴Teddy著名的美國平面設計師Paul Rand在《Paul Rand: Conversations with Students》提到設計的定義：

Design is relationships. Design is a relationship between form and content. (可參考這裡)

Teddy看到這個定義的第一個反應就是「字是不是打錯了，把context打成content？」Context是環境，content是內容，字很像但是意思不同。後來找到這份資料，發現沒打錯，Paul說的真的是content。在這份資料，還包含一段Paul關於form與content的說明：

«Design is the manipulation of form and content… Content is the idea, or the subject matter. Form is what you do with this idea. How do I deal with it? Do I use color? Do I use black and white? Do I make it big? Do I make it small? Do I make it three-dimensional or two-dimensional? Do I use trendy stuff, or do I use more serious stuff? Do I use Bodoni or do I use Baskerville? These are all the questions you ask. This is part of the manipulative aspect of design.» — Paul Rand

***

不知道是不是因為Paul是平面設計師的緣故，所以他認為「設計是形式與內容的關係」（平面設計主要考慮的因素是用何種形式來展現內容，可以這樣說嗎？）廣義的來講，Teddy還是比較喜歡從Alexander書中推論出來的看法：

• 設計是決定form、context，以及兩者之間的關係。
• 好的設計是form與context的良好適應關係。

以上，提供給鄉民們參考。

***

友藏內心獨白：感覺好像在推導數學公式。

把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），要能夠驗證這個設計產出物的合理性。

***

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

***

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

2013馬祖考察之旅Day4-C魚路古道的入口、大埔石刻

June 21 21:18~21:49

離開大埔漁村之後來到魚路古道的入口，由於這次時間太趕，等一下就要搭下一班傳回南竿，所以沒時間去走魚路古道。

 

魚路古道應該就是這條小路。

***

離開魚路古道之後來到大埔石刻。這的景點緊鄰著營區，地理位置非常…險要。

 

沿著階梯往下走首先來到老頭大王廟，好特別的廟名啊。

 

大埔石刻就放在庭中的地面，有其他遊客到了之後找不到來問Teddy石刻放在哪裡。

 

石刻的年代是明朝萬曆年間，置放石刻的亭子旁有一塊碑文說明石刻的歷史。

 

繼續往前走幾步路就來到了海邊，有一個小島嶼在退潮的時候可以走過去。

 

很貼心的設計。

 

有釣客在附近釣魚。

 

馬祖的景點幾乎都有廁所，這棟蓋得很有味道的建築物就是廁所。

 

隔著一道小圍牆旁邊就是軍方的營區。

***

友藏內心獨白：古人到此一遊的痕跡，日久成古蹟。

2013馬祖考察之旅Day4-B神祕小海灣、廢棄軍事據點、大埔漁村

June 21 18:10~18:38

離開東犬燈塔之後來到「神祕小海灣」，這個景點其實就是一個亭子，在裡面可以優閒地欣賞東莒美麗的海景。真的好舒服啊，沒有其他遊客，獨享整個海灣。美中不足之處就是這裡沒有賣咖啡啊。

 

波光粼粼的大海加上非常乾淨的海岸。

 

東莒島上的道路，非常平整。天龍國的國王應該來這裡考察一下，就知道天龍國的「路平專案」還有很多改善空間啊。

***

繼續往前走來到一個廢棄的軍事據點。

 

離東犬燈塔已經有一小段距離了。

***

繼續往前走來到大埔漁村。

 

這是一個很小的漁村，村內貼著兩幅大大的「花漾」電影海報。這部電影，怎麼好像很陌生的感覺。

 

村裡面肥美的放山雞。

 

大埔漁村是一個很美麗的漁村，光是這片無敵海景就是無價之寶。

 

大埔漁村有一個觀景庭，可以遠眺林坳嶼。

據說此島為釣友兵家必爭之地。

海面上有許多作業中的漁船，不知是左岸還是右岸的船。

***

友藏內心獨白：東莒的大海好美啊。