[轉載]什麼是 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……」的句式，從各個不一樣的角度分解問題，找出全部可能解決問題的方式。在這個階段，咱們須要的注意的是：

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

 

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

那麼，咱們須要使用「How might we……」的句式，從全部可能的角度來分解這個問題：

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

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

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

頭腦風暴

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

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

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

能夠作招牌菜的海報或易拉寶展現；

能夠作食客最多點選的菜餚 list；

甚至能夠像風波莊那樣，根本無需點菜，只須要食客告訴服務員用餐人數和忌口，服務員立刻就能爲你上菜……

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

常見的頭腦風暴都是你們在一塊兒，你一言我一語的討論。可是發散思惟和羣體討論都是兩件很容易失控的事情，因此通常的頭腦風暴容易存在如下問題：

1. 辯論會：對別人的想法進行判斷，以爲「不靠譜」，甚至變成了辯論會
2. 一言堂：強勢的參與者，一般是老闆，說「這個好」，而後你們都順着這個思路往下作
3. 假大空：提了一些相似「必定要作好產品」這樣的想法
4. 各說各的：你們都有本身的思路，不從別人的想法上展開，失去了羣體討論的意義
5. 自我限制：「這樣實現成本過高」「這樣可能別的部門不支持」

因此在豌豆莢作頭腦風暴的時候，咱們有個規則是：不！要！討！論！

 

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

1. 沒有討論，辯論會的狀況就不會發生。
2. 沒有討論，老闆想要徹底控制方向是不太可能的。
3. 傳遞 post 貼，全部人都會看到以前其餘人的想法而且一次爲基礎發散，站在巨人的肩膀上了。
4. 五分鐘內五個想法，是個高強度的腦力訓練，強迫參與者打破一切限制，尋找任何可能的思路，參與者每每會比較積極的參考別人的想法。

卡片分類和完善

經過上一步的頭腦風暴，咱們會蒐集到 100 - 200 個 post 貼，甚至更多，這些 idea 都是感性的、靈光一閃的、零散的。這一步，咱們須要將這些 idea 組織起來，抽象出其中暗含的邏輯關係，這個會對應以後產品的方向。咱們須要對蒐集到的全部 post 貼貼在牆上，經過移動 post 貼來作卡片分類，大概分紅 5 - 7 類，每一個類別都須要有一個歸納性的標題。分類沒有必定的規則，你們會根據這些 idea 之間的關聯或者天然屬性來分類。每類下包含 idea 的數量應該差很少。若是有某個類別所包含的 idea 數量明顯多於其餘組，則須要把大的分類打散，直到全部類別下 idea 的數量大體相等。

 

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

方案設計

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

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

總結

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