什麼是 Design Hackathon？

12-17

看到一個名為 Design Hackathon 的產品設計方法，網上查了一下，國內沒看到相關記錄，國外倒是有一些，但都是活動介紹，並沒有說明白，求達人指教。

剛好最近在 ixdc 互聯網產品大會上做了一個工作坊是關於 design hackathon 的，這個方式原來在 Google 、現在在豌豆莢做產品設計的時候都經常用到，已經是我自己最喜歡也最熟悉的方法之一了。

介紹下什麼是 Design Hackathon？

Hackathon，即「黑客馬拉松」，是一個流傳於技術愛好者中的活動。在該活動當中，很多程序員相聚在一起，以合作的形式去編程，而且整個編程的過程幾乎沒有任何限制或方向。Design Hackathon 更類似用「黑客馬拉松」的思維做產品設計，這種方法論融合了來自 Google，IDEO 等業界頂尖公司的產品設計工具和方法，它將所有的產品設計師、視覺設計師甚至工程師聚在一起，在一定的時間內，以頭腦風暴的方式，最大範圍地搜集產品的各種可能性，然後抽象地整理出這些想法背後所隱藏的核心概念和產品需求，快速梳理出正確的產品設計方向，之後將想法轉化成可視的手稿和線框圖，最終變成產品雛形。

快速發現海量可能性

Design Hackathon 非常適合產品定義階段。在產品定義階段，面對確定的需求，設計方向和目標尚模糊，產品形態發展的可能性非常多。如果僅僅採用傳統的設計手段（比如單人決策），非常容易走向片面和狹隘的方向，既可能出錯，也會喪失許多機會。Design Hackathon 將所有與產品相關的人員聚在一起，利用頭腦風暴法，快速產生海量想法和點子，讓產品設計從個人經驗、老闆意願和競品預設的桎梏中脫離出來，搜集最大範圍的產品可能性。

確定方向的同時，擁有可落地的細節

Design Hackathon 遵循了一個「從發散到抽象再到具體」的過程，從最直接的個人經驗、想法或者靈機一動的點子出發，抽象地歸納出這些想法背後所隱藏的核心概念或產品需求，最後再回歸到具體的產品設計草圖表達當中。這個由「發散到抽象再到具體」的過程，既保證了思維發散階段的豐富性和靈感的多元化，又能達到將想法現實化的目的。

激發團隊不同角色的創意

Design Hackathon 參與人員並不局限於產品設計師和交互設計師，而是可以拓展到工程師等其他產品相關人員。不同背景和角色的人通過討論和互動，能夠相互激發靈感，獲得豐富的創意。在產品的設計過程中，設計師、工程師和高層領導者由於背景和理解問題的角度不同，常常會產生分歧和爭議，使產品設計的時間周期變得不可預測。Design Hackathon 的方法論可以讓整個產品團隊都加入其中，在平等、專註且高效的狀態下，通過分類的方法，將所有人思考的亮點條理化，匯聚到最終的產品設計中。

如何操作？

在歐美等設計業成熟的國家，Design Hackathon 是很多設計機構普遍採用的方法論。然而這種方法論目前尚未被公開引入國內。豌豆莢 2011 年開始就已經比較多的用 Design Hackathon 的方法論做產品設計了，豌豆莢的主要產品，例如 Windows 端和 Android 端，2013 年 8 月發布的 Windows 端新版歡迎頁，以及 9 月剛剛發布的視頻搜索產品，都是用這個方法來完成產品設計的。積累了一些心得分享給大家吧：

發散：解決問題的方式

在開始一切之前，我們首先需要明確自己要解決的問題是什麼。我們可能是需要設計一個全新的產品，但我們對這個產品只有模模糊糊的想法，譬如想做一個視頻產品，或者想做一個即時聊天產品，我們已經了解到一些用戶遇到的困難和問題，但是這個產品具體會以什麼樣的方式什麼樣的切入點來解決這些問題，我們並不清楚。

解決任何一個問題的方式都是多種多樣的，我們可以使用「How might we……」的句式，從各個不同的角度分解問題，找出所有可能解決問題的方式。在這個階段，我們需要的注意的是：

開闊思路，追求的是全面的、打破常規的思維和方向，不需要評價它是不是嚴謹，是不是可實現，甚至是不是反常識
不需要提出具體的解決方案，解決方案將會在後續階段補充。

舉個例子吧，如果我們的問題是，到了一家餐廳不知道吃什麼？

那麼，我們需要使用「How might we……」的句式，從所有可能的角度來分解這個問題：

如何讓點菜的過程變得有趣（既然點菜的過程很麻煩）？
如何不去餐廳（不去餐廳也就不存在點菜的問題了）？
如何讓大家不吃飯呢？（不吃飯也就不存在點菜的問題了）
如何知道大家最愛吃什麼？
如何讓大家口味都變得一樣（這樣就解決了眾口難調的問題了）？
如何事先知道這個菜大家喜歡不喜歡？
如何點主菜、素菜、湯（點一整桌菜可能很麻煩，但是只點一個湯就好多了）？
如何讓大家進入餐廳就自然知道點什麼菜？
……

關於這個方法論，斯坦福大學設計學院有個英文版的例子，請看這裡：

http://dschool.stanford.edu/wp-content/uploads/2012/05/HMW-METHODCARD.pdf

頭腦風暴

通過前一步的預熱，我們已經整理出產品開發中可能遇到的問題了。請從這些方向中選擇一個自己最喜歡的。進一步要做的，就是在當前這個方向下，讓我們自由地、無拘無束地闡述解決方案。

譬如，在第一步的點菜問題上，針對「如何讓進入餐廳就自然知道點什麼菜？」，我們可能會有很多的想法：

可以在餐廳門口放上菜單，任顧客翻閱瀏覽；

可以做招牌菜的海報或易拉寶展示；

可以做食客最多點選的菜肴 list；

甚至可以像風波庄那樣，根本無需點菜，只需要食客告訴服務員用餐人數和忌口，服務員馬上就能為你上菜……

頭腦風暴其實是最難的一部分。

常見的頭腦風暴都是大家在一起，你一言我一語的討論。但是發散思維和群體討論都是兩件很容易失控的事情，所以一般的頭腦風暴容易存在以下問題：

辯論會：對別人的想法進行判斷，覺得「不靠譜」，甚至變成了辯論會
一言堂：強勢的參與者，通常是老闆，說「這個好」，然後大家都順著這個思路往下做
假大空：提了一些類似「一定要做好產品」這樣的想法
各說各的：大家都有自己的思路，不從別人的想法上展開，失去了群體討論的意義
自我限制：「這樣實現成本太高」「這樣可能別的部門不支持」

所以在豌豆莢做頭腦風暴的時候，我們有個規則是：不！要！討！論！

所有人提出的 idea 需要寫在 post 貼上，最好是畫出來。採用 N × 5 × 5 的方式。N 表示所有參與頭腦風暴的人總數，這個式子表示需要每人在 5 min 的時間內寫下 5 個想法，然後將這 5 個想法傳給下一個人，同時接收上一個人傳來的 post 貼，再寫一輪，如此類推，N 輪過後，每個人手中都會有 5N 個想法，所有人共有 5 × N × N 個。所有人都要寫，但是相互之間不要交流，這樣子其實避免了常見的幾個問題：

沒有討論，辯論會的情況就不會發生。
沒有討論，老闆想要完全控制方向是不太可能的。
傳遞 post 貼，所有人都會看到之前其他人的想法並且一次為基礎發散，站在巨人的肩膀上了。
五分鐘內五個想法，是個高強度的腦力訓練，強迫參與者打破一切限制，尋找任何可能的思路，參與者往往會比較積極的參考別人的想法。

卡片分類和完善

通過上一步的頭腦風暴，我們會搜集到 100 - 200 個 post 貼，甚至更多，這些 idea 都是感性的、靈光一閃的、零散的。這一步，我們需要將這些 idea 組織起來，抽象出其中暗含的邏輯關係，這個會對應之後產品的方向。我們需要對搜集到的所有 post 貼貼在牆上，通過移動 post 貼來做卡片分類，大概分成 5 - 7 類，每個類別都需要有一個概括性的標題。分類沒有一定的規則，大家會根據這些 idea 之間的關聯或者自然屬性來分類。每類下包含 idea 的數量應該差不多。如果有某個類別所包含的 idea 數量明顯多於其他組，則需要把大的分類打散，直到所有類別下 idea 的數量大致相等。

譬如，關於上一個點菜的問題，我們可能產生了很多的想法，這其中有一些是關於菜單設計的，有一些是關於服務員服務技巧的，還有一些是關於餐廳制度的，等等。

方案設計

經過分類，這些頭腦風暴產生的零散想法之間就有了關聯，每一個類別下的想法，對應的就是一類個產品方向。截至此階段，設計師們也會開始產生一些具象化的內容。這一步，我們需要發動所有的設計師參與和貢獻：將所有的設計師分組，每一組設計師領走一個類別的卡片；根據這些卡片上的信息，設計師可以做具體的設計了，設計 storyboard、workflow 以及開始繪製大量的草圖和線框圖。對於每個組，繪圖的過程和方式比較靈活，可以是每位組員分工做，根據所拿到的 idea 做不同方面的草圖，也可以組員一起討論出一個草圖。對 idea 的取捨由設計師自己確定。

怎麼把產品的想法組織並且表達成具體的產品，關心產品設計的人對此都非常熟悉，我就不展開描述了。

總結

Design Hackathon 遵循了「從發散到抽象再到具體」的思維過程。通過『How might we...』和頭腦風暴來發散保證了我們不會錯失有關產品設計的各種可能性和細節，通過卡片分組來抽象我們整理出想法中的產品邏輯和需求層次，而具體的 storyboard、workflow 和線框圖的過程則保證了我們所有的想法和需求都能落地成為可見的設計。

最後

你都看到這裡了，麻煩點個贊吧！
豌豆莢一直在招聘，你懂的：豌豆實驗室招聘

上周六有幸參加了一回豌豆莢舉辦的由@liuyaping 老師主持的Design Hackathon 活動，與一些業界的小夥伴們一起嘗試了一下這種產品設計方法。

簡單說下我對Design Hackathon的理解 ——它是一種在頭腦風暴階段儘可能挖掘產品思路，然後通過分類整理來收縮和篩選，最後決定產品方案的一種設計方法。在豌豆莢舉辦的這次活動中，每組有6個人，圍繞「和朋友一起出去吃飯，不知道怎麼點菜」這個問題來設計具體的解決方案。

首先是問題拆解，Design Hackathon 使用「How might we……」的方式來拆解，提出多種拆解方案。

但其實我個人認為在進行這一步之前應該做的另一個拆解是針對」不知道怎麼點菜「找出各種可能存在的原因，比如說因為」不知道大家的口味「、「不知道這家餐廳什麼好吃」、「不知道點多少菜合適」、」礙於面子「……等等，然後才涉及到「如何」的問題，不然會稍微有點跳。

然後是針對分解的問題展開頭腦風暴，5分鐘內寫下5個，然後傳給下一個人，我們做了4輪。4輪過後，在場的產品經理們多半已經呈現出被爆腦後的奄奄一息狀，我忍不住在心裡為劉亞平老師這為民除害的義舉高聲喝彩……幹得好！

這個環節中有幾個需要注意的地方：一是不討論，二是在接到上一輪的人的idea後，要快速看一遍，儘可能在自己沒有想到而得到了別人啟發的分支上去拓展。第一點尤其重要，因為這個環節最重要的目的就是快速產生大量的想法，而討論會直接導致進入「可行性」判斷上，會扼殺可能誕生的新思路。

頭腦風暴後，要把這些idea進行分組並定義類型，然後選擇其中一組進行深入挖掘，我們組一共分了6類，最後選了以自身條件出發的那類。下意識選擇後者的原因大概是因為這個最貼近用戶，最符合把自己模擬成用戶的方式去思考。

然後劉亞平老師要求我們進入原型設計階段，這裡他為了節省時間略去了一個環節，但在實際的工作中是無法避開的，就是產品目標用戶群定義，明確產品需要解決目標用戶群的主要問題和次要問題是什麼，明確動手前提條件，決定產品框架。所以面對這種詭計（並不是），我們組只好花時間討論了一下，最後決定解決」當顧客到店後，沒法快速知道這裡什麼菜適合他們吃「這個問題，並同時兼顧健康影響。

下面是個人的一點拙見——總的來說我認為Design Hackathon是一個非常」設計師「化的產品設計方法，它最有用的地方在於idea收集階段。因為其實說白了，互聯網科技的發展，主要是技術在進行推動，產品經理這種細分職分的出現要遠遠晚於研發工程師，所以在某種程度上制約了產品經理的思維模式，導致他們會下意識地考慮」能不能做「，而這樣的idea收集方式，有助於幫助產品經理拓展思路。

Design Hackathon是一種非常開放的設計方法，它歡迎各種各樣的想法，但是它的缺陷和矛盾之處也在於此，如果在問題拆分的階段不能去掉那些不需要重點解決的問題的話，下面的idea階段就會有很多過於發散的浪費，導致「收」的時候不好收，整理的時間花費太長。所以在實際應用時，要針對不同的公司，不同的項目，結合其它問題綜合考慮後進行調整才能方便應用。

所有名字裡帶 Hackathon 的活動的意思都是拉一幫人來在短時間內做到死。可以理解爲一種頭腦淫亂派對。

#BeIntellectuallyPromiscuous

Yaping 老師和翅膀老師已經從理論和經歷方面闡述了 Design Hackthon 的一些方式。Design Hackthon 的完整流程通常是 5 天左右，正巧最近職人社 × 光澗實驗室每月都在舉行這樣的產品設計線下活動，考慮到可實施性我們把活動壓縮到 1 天之內，用工作坊的方式把這種來自 Google 的優秀設計方法帶給更多的人。

我參加過不下 5 次 Design Workshop 的活動，每次都有不同的感受。2011 年我在知乎工作，8 月的一天收到俊煜的郵件，邀請我作為評審嘉賓參加豌豆莢內部的 Hack Day。在那次 Hackathon 里，我看到了 7 支內部小團隊在短時間內迸發出了無限的想像力、創造力和實際動手能力，第一次為這種新穎的產品開發形式所吸引。

圖來自王俊煜個人公眾號貓窩

2014 年初，我加入豌豆莢團隊，當時的項目對我而言是一個陌生的行業。面對多樣、雜亂的需求，當時搭擋的設計師主持了一場團隊內的 Design Hackathon，通過高效的 Brainstorming，對需求進行了地毯式的遍歷搜集並分類，幫助我快速地看到了全局。這一次，我感受到了正確的 Brainstorming 姿勢的重要性。

離開豌豆莢後，我在社交領域開始了第一次創業 —— 這是一個需求廣泛但產品形態亟待創新的市場。一段時間後，產品增長遭遇瓶頸，於是我在團隊內組織了一場 Design Workshop，以「如何讓兩個陌生人進行有效見面」為主題，開展了魔鏡 2.0 的設計探索，做出了全新的產品方案。儘管最終我們沒有將這一版上線，那場 Workshop 無疑對我們團隊而言是一場整齊高效的交流討論。

Design Workshop 強調創新思考、追根溯源、去偽存真、動手創造，這個方法不僅適用於互聯網產品，也適用於日常生活中碰到的一些問題。去年 11 月，我參加豌豆莢「豌豆大篷車 · 深夜酒館」聚會，跟俊煜聊到想圍繞產品設計方法論做分享社群的嘗試，他提出可以與他的新公司「光澗實驗室」一起合作，我當時就覺得非常棒 —— 能把豌豆莢內部實踐多次行之有效的設計方法論推廣給行業內更廣泛的職人，這事兒太有意義了。

為了確保 Workshop 啟動的質量，前幾期 Design Workshop 由光澗實驗室的聯合創始人王俊煜親自設計和主持，保證全程推進效果，並特別邀請了兩位嘉賓進行經驗分享。光澗實驗室和職人社共同進行參與者的招募。職人社特別推薦了幾位資深產品經理參與，全程跟進記錄，並將在之後和光澗實驗室一起共同改進 Workshop。

第一次活動，俊煜從眾多選題中選擇了大家關心度比較高的「日常場景中易用的小程序」。為了讓設計流程更加流暢高效，還預先在每個小組進行了背景、經驗的精準搭配，以期產生更多有趣的想法碰撞。

為 Design Workshop 充分準備

簡單來說 Design Workshop 可以分為提問、頭腦風暴、Idea 分類和完善、方案設計四個環節，遵循思維從發散到抽象到具體的過程。

材料上的準備：

人數：Design Workshop 人數以 8-15 人為宜，鼓勵在角色上更加多元，除了產品設計師以外，運營、工程師、BD 等角色都可以參加。

場地：場地需要有容納 5-7 組桌椅，確保成員可以在方案設計環節無障礙分組，進行寫紙條和繪製線框圖。

物料：每個成員有至少一支馬克筆，一本 N 次貼，3-5 張 A4 紙，場地內有一塊大白板，PPT、投影儀和計時器看情況選擇。根據分組情況準備 5-7 個白板。

在動手之前，需要每個參與者對今天設計的命題以及設計流程做足夠的了解。俊煜分享了他理解的設計方法論：

第一，需要對問題做一些了解；

第二，在命題中尋找機會；

第三，設計方案，對命題做一些驗證；

第四，對方案做一些迭代，完善方案。

衡量設計的好壞可以從三個角度去思考， Desirability（用戶渴求）、Feasibility（技術可行性）和 Sustainability（商業可持續）。好的 Idea 應該實現這三者的交叉。

當天的設計環節分為三個部分：

第一，學習小程序。俊煜邀請了輕芒聯合創始人、前豌豆莢技術負責人范懷宇，以及有可能學院 CEO、知名博客「可能吧」的作者阿禪（Jason Ng ）分享關於小程序的想法，參與者會基於他們的分享，加深對小程序的理解。

第二，找小程序的機會和設計解決方案。避免大家 Brainstorming 的過程太零散，花費更多的時間，俊煜會嘗試用結構化的方法帶領大家完成 Brainstorming 的過程。

第三，交付解決方案。這次我們準備了足夠的便利貼和白板，鼓勵大家把解決方法用視覺化的方法展示出來。由於時間關係不能做用戶測試，我們這次會嘗試做一次有效的設計評審。

尋找正確的問題

設計是創造性地解決問題的過程。而比解決問題更重要的是找到正確的問題。

什麼是「問題」，什麼是「解決方案」？

發現問題和解決方案是兩個不同的含義。很多時候大家都會忽略明確問題的這個過程直接跳到解決方案上。

俊煜舉出的問題是「飛機上的熊孩子很吵」，大家當下反應出的解決方案：去批評熊孩子讓熊孩子閉嘴、或是去和熊孩子的父母理論。設計的方法應該是找到問題背後的「機會」，這樣就會重新定義問題，比如：「我想在飛機上休息，HMW 讓熊孩子不吵到我？」。經過這樣 HMW 對問題重新定義之後，一副好的降噪耳機也許才是更好的解決方案。

今天大家嘗試提出正確的問題，不急著給出解決方案，而是用 HMW 提出其中的機會。

無拘無束地提出機會需要遵循幾個規則：

不對別人的 Idea 有 Judgement。大家在提問題的本質是為了找到最有價值的 Idea，要用「Yes, and」的積極心態看待別人的 Idea。

數量大於質量。整個過程中追求儘可能多的 Idea。

鼓勵狂野的 Idea。也許最後正是這些狂野地想法產生了更多的可能性。

不要害怕借鑒別人的 Idea。在 Brainstorming 環節中借用團隊 Idea 做一些改良，是被允許的。

鼓勵把 Idea 圖形化。我們只準備了粗筆，希望大家把 Idea 寫得盡量簡潔。

從小程序的分享開始 Brainstorming

小程序是一個新的技術，發展階段還比較初期。

根據「創新擴散理論」，俊煜用用戶群的概念*把用戶分為職業鑒賞家、專業發燒友、業餘愛好者、匆忙路人甲和圍觀群眾幾種類型，定義了我們要影響的人群會是專業發燒友和業餘愛好者。這類人群的特點是不抗拒使用新的東西，但並不會為了嘗鮮而嘗鮮，只有這個功能真實有用，他們才會願意繼續使用。

俊煜分享了一些過去公開的研究成果，引導大家用 HMW(How Might We) 來表達小程序的機會。比如對於大多數安卓用戶來說，裝很多的 App 意味著手機不安全、遭受推送的騷擾和手機變卡，所以他們會減少 App 的安裝；對 iOS 用戶來講，16G 大小手機佔用戶比重比較大，而這類用戶相對喜歡嘗鮮。

接著每組參與者輪流分享大家在體驗不同小程序時發現的好用的小程序場景以及用法，大家在交流中繼續尋找新的機會，做更多 HMW 的提問。

經過這一輪相互啟發之後，大家手裡的 HMW 漸漸多了起來。接下來范懷宇給大家分享了小程序的技術特點和可行性，可以從以下幾個層面開始思考小程序的機會：

交互：小程序在可行性上目前能做出什麼樣的東西

設備：小程序對手機設備有什麼樣的許可權，可以獲得哪些信息

微信服務：小程序寄附在微信當中，可以從微信得到什麼樣的功能

獲取和迴流：小程序作為比較新的產品，和其他傳統產品的區別

阿禪為大家分享了他在小程序商業機會的思考。阿禪在業界首先提出了微信小程序從線上鏈接線下場景的方向，成功的小程序應該做到即用即走，提供與線下場景特別相關的服務，更好的利用還沒有被開發的用戶流量和用戶時間。如果這個使用場景還具有可傳播性，整個環節將會更加完整。

大家與阿禪進行了長達半小時的 QA，對於一些與服務號的區別、特定的服務場景以及小程序的生態進行更深入的提問，在交流過程中大家產生了更多的場景可行性的想像。俊煜根據范老師、和阿禪的分享，把用戶體驗做了更準確梳理，做了更完整的用戶體驗地圖。

分享環節結束，白板上已經貼了近百個 HMW 的提問。接下來大家對這些 HMW 進行分組，整個過程大家只看展示不做任何交流和引導，基於自己的理解對機會進行分組。分類的過程不必要求完美，遇到不理解的 HMW 就放到一邊。大概十分鐘的功夫就完成全部的分類。

接下來大家用一開始準備好的小圓點對分類之後 HMW 進行投票和決策。所有的成員可以根據自己的理解給這些機會投票，每人有三張貼紙，如果大家認為一個問題非常值得解決，可以投多次來體現問題的價值。當主持人把票數最多的幾個 HMW 轉移到用戶地圖的對應位置時，大家就可以很直觀地看出在哪些環節，潛在的問題或機會最多。

每一個小組基於用戶體驗地圖，對每個機會的入口、分享等環境進行了一些思考和討論。從用戶需求角度出發，每個小組認領了一個問題。

每個小組又明確了一次小組想要解決的問題。這個時候只需要明確需求的場景和問題，而不需要給出具體的解決方案。這裡的句式是「如何解決什麼場景下的什麼問題」。

到現在為止，大家已經完成了「前期立項」的工作。

總有更好的解決方案

每個小組把自己認領的問題明確地寫出來，嘗試用 Brainstorming 的方法設計解決方案。這個過程需要大家的思維不斷發散再收斂，從「問題到故事板」的過程要進行至少三次發散收斂的過程，這樣做出來解決方案會更加經得起推敲。

第一次，圍繞著問題寫出 Idea。一開始可以根據直覺畫出一些 Idea，這些可能是零散的，不成體系的。

第二次，每個人整理出一個成體系方案。這個環節大家可以用粗筆來畫，迴避很多設計細節。

第三次，小組成員一起設計出一個更加完整的 Story Board。把用戶使用小程序的過程畫出來。它可以是一個界面，可以是某線下場景的整體流程。

第一步大家要在組內榨出足夠多的 Idea。我們準備了一些 A3 的紙。每個人有 16 分鐘，每隔 4 分鐘畫出來 4 個 Idea 貼在紙上，然後傳給右手邊的同學。每個同學需要先理解一下上一個同學的 Idea，然後再畫出 4 個 Idea。這樣每組可以得到 4 × 4 × 4 個 Idea。

由於時間短，鼓勵大家依靠直覺，思維儘可能得發散。強迫自己在規定時間內把 Idea 畫出來。可以是對整體系統的 Idea，也可以是某個環節上的 Idea。不用擔心 Idea 跟其他同學是重複的。

接著大家用分類和投票的方式對 Idea 進行整理。大家安靜地把每組 64 個 Idea 進行展示和分組，然後進行不限次數地投票。標記出 Idea 的設計細節或者方案中亮點。不限次數的意義在於，可以在 Idea 中畫出熱點圖。

完成了 Idea 的整理和投票後，每個人有 5 分鐘的時間按照自己的喜好把每個環節串進去，畫出更系統化的方案草圖。這裡的保真度需要做到用簡單的三屏草稿紙來描繪「用戶是怎麼進入到這個小程序的」、「用戶做了什麼動作」、「用戶得到了什麼結果」。這裡每個人應該思考更多的應該是流程的完整性，避免陷入具體細節鑽牛角尖。

每個組產出四個方案草圖，大家在組內繼續對這個四個方案草圖用小圓點貼紙進行投票和討論，不但要投出喜歡的方案，還要去貼具體喜歡哪點設計。之後大家就可以從大家最喜歡的部分里提取出產品的 Story Board。

做方案設計的過程中小組成員難免會遇到分歧。當組內的成員對於將要形成的故事板無法達成一致時，俊煜給小組分別引導，用一些方法*幫助大家走出設計的僵局：

第一個方法是再收斂。很多情況下，有爭議是因為組員的背景信息不同，導致大家心目中的場景設定、目標用戶有偏差，給出的解決方案不能互相認同。這時就需要將命題進一步收斂到一個更加具體的要解決的問題。比如說有一組認領的命題是「HMW 讓用戶更好的完成醫院的就診流程」，大家會先將這個命題的場景縮小到「去一家普通三甲醫院看病，可以掛得到號，各環節排隊人很多」這樣的背景，在此基礎上再去各自設計方案，大家的思路就不會偏差太大。

第二個方法是引入決策者。當無限次投票等方法沒能產出結果時，可以引入決策者來拍板。決策者需要從各個角度理解大家的立場，做一個綜合考量再做出決策。

對設計方案做有效的評審

「設計評審」的環節有兩種方法，一種是大家去看別人的 Idea，然後投票點出自己最喜歡的點。這樣做的目的不是選出設計最好的方案，而是找出方案中的最好的部分然後繼續細化。

這次俊煜選用了 Thinking Hat 的方式對設計方案做評審。首先每個小組展示自己的故事板，展示之後其他參與者有 15 分鐘的時間可以分別從 User Advocate（用戶），Optimist（樂觀主義者），Pessimist（悲觀主義者），Feasibility（技術可行性），Idea Generator（點子大王）這五個不同的角度提出意見，給小組團隊更多的反饋。

在這個過程中，大家給出了很多有趣的評審觀點。比如「去一家普通三甲醫院看病，可以掛得到號，各環節排隊人很多」這個場景，原本設計的結果分享給家人，現場同學以 Idea Generator 地角度評價說可以把最後一步設計成為眾籌，一方面幫助患者解決了費用負擔問題，另一方面為醫療捐助做了可信驗證。

通過 Design Workshop 的方式，我們能夠快速、準確地整理出一條正確的產品設計方向。但在實際進行產品設計的過程中，我們需要把產品實現出來，通過用戶反饋，迅速反應和調整，對產品進行一次次迭代。經過下午三段發散到收斂，大家都拿出了保證度相對比較高的解決方案。最後大家把活動的感受和疑問都整理出來貼在了白板上。

俊煜分享的設計方法論來自於以下三本書：

光澗實驗室關於 Persona 的文章 http://dwz.cn/5wgqMg
光澗實驗室關於 Design Workshop 方法論及流程的文章 http://t.cn/RiY7XTB
創新擴散理論 https://en.wikipedia.org/wiki/Diffusion_of_innovations

Hackathon本來一些一些程序猿最喜歡玩的事情，是指給程序猿們一個特定的時間，用來天馬行空的去完成一個命題or非命題作文，把工作之餘的個人激情抒發出來，寫一個牛逼的程序，創意來源於興趣，實施來源於能力，自由組隊但一般一隊人數不要太多，需要有獎勵並且獎勵要很有激勵作用。百度、360、豌豆莢都會高這種Hackathon，一般是利用周末的時間，憋在一個屋子裡24小時，產出創意+設計+程序。

百度最近一期Hackathon冠軍是夢幻二維碼團隊，他們可以讓二維碼變成五彩的，甚至特定圖案的，非常有趣已經應用到我們部分產品里。百度也有面向開發者的Hackathon，上一次在車庫咖啡，還有眾多度娘前去助陣。雖然Hackathon雖然是一種活動，但是更多的是碼農宅男的變相宅。

而Design Hackathon則不同於程序猿的變相宅，更多的是一種熱情洋溢的互相激發、碰撞想法。
在最近的一次劉亞平組織的Design Hackathon里，我們通過發散思維、頭腦風暴、卡片分類、原型設計這些基礎方法，來通過APP解決了點菜難這個問題。方法還是那些方法，但實施的手段不同，能產生的效果和歡樂程度就是不一樣的。

前一段時間上了Stanford university的Design Thinking Action Lab的在線課程，感覺是類似的方法，課程已經結束了，但有可能還能看到授課過程和方法論，推薦看看

就是讓設計師像程序員一樣加班

大學時候就做個類似的，當時是圍繞一項科技研髮結果，想使用場景，再深入某個比較好的點子進行深入設計。。。

對員工來說是公司給予的展示才能的機會
對公司來說是花最小代價最短時間收穫最多產品和創意的手段

當然第二點總是被忽略

又一個名詞，lean的一種釋放個人與團隊能量的激進方法吧。跳出傳統工作流的桎梏，高效產出成果。