產品設計不是命題做文：Design Hackathon 方法介紹

在產品的定義階段，產品發展形態的可能性是最多的。對於當前國內絕大多數移動互聯網創業公司來講，在產品定義初期，每每都是由個別產品負責人或者創始人「決定」產品方向的。這種「命題式」的傳統方法，會致使產品的大部分可能性被早早扼殺，很容易讓產品設計陷入程式化的思惟或是已有的產品模式。在這種方式下，不能說誕生不了好的產品，但突破和創新的難度將會大大提升。傳統的「頭腦風暴」，在發散思惟時每每失於天馬行空，忽略了落地的可行性。

在歐美等設計業成熟的國家，不少設計機構都採用了 Design Hackathon 的產品設計方法論，這種方法融合了來自 Google、IDEO 等業內頂尖公司的設計方法和工具。這種方法論目前還沒有被公開引入國內。豌豆莢做爲一家產品和技術驅動的公司，早在 2011 年就引入 Design Hackathon 的方法論作產品設計。現在已經使用這種方法設計出了豌豆莢 2.0 的 Windows 端和 Android 端，2013 年 8 月發佈的 Windows 端新版歡迎頁，以及 9 月剛剛發佈的視頻搜索產品。

在這些產品的設計過程當中，豌豆莢也積累了一些經驗和心得。2013年10月19 日上午，在 IxDC 主辦的 2013 中國互聯網產品大會上，豌豆莢產品設計總監劉亞平主持了主題爲「產品設計不是命題做文」的產品設計工做坊，第一次將 Design Hackathon 引入國內業界，並組織全部參會者親身實踐了這個方法論的全過程。咱們將現場整個 Design Hackathon 的過程整理出來，但願經過這種方式，將 Design Hackathon 的產品設計方法介紹給全部致力於打造優質產品的同行和朋友們。

什麼是 Design Hackathon ？

Hackathon，即「黑客馬拉松」，是一個流傳於程序員和技術愛好者中的活動。在該活動當中，你們相聚在一塊兒，以合做的形式去編程，整個編程的過程幾乎沒有任何限制或方向。Design Hackathon 相似用「黑客馬拉松」的思惟作產品設計，它將全部的產品設計師、視覺設計師甚至工程師聚在一塊兒，在必定的時間內，以頭腦風暴的方式，最大範圍地蒐集產品的各類可能性，而後抽象地整理出這些想法背後所隱藏的核心概念和產品需求，快速梳理出正確的產品設計方向，以後將想法轉化成可視的手稿和線框圖，最終變成產品雛形。

快速發現海量可能性

Design Hackathon 很是適合產品定義階段。在產品定義階段，設計方向和目標尚模糊，產品形態發展的可能性很是多。若是僅僅採用傳統的設計手段（好比單人決策），很是容易走向片面和狹隘的方向，既可能出錯，也會喪失許多機會。 Design Hackathon 將全部與產品相關的人員聚在一塊兒，利用頭腦風暴法，快速產生海量想法和點子，讓產品設計從我的經驗和競品預設的桎梏中脫離出來，蒐集最大範圍的產品可能性。

肯定方向並擁有可落地的細節

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

激發不一樣角色團隊成員的創意

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

如何操做 Design Hackathon？

準備階段

在 Design Hackathon 開始以前，咱們須要先作一些準備工做，包括場地、人數和紙筆的準備。

1. 人數：Design Hackathon 的參與人數以 8-15 人爲宜，產品設計師、視覺設計師甚至工程師等全部與產品相關的人員均可以參加；
2. 場地：場地須要容納 5-7 組桌椅（由於在「方案設計」環節，全部人須要被分爲 5-7 組），能保證每組成員都無障礙地寫紙條和繪製線框圖；
3. 物料：每位參加者須要配備 1 支馬克筆，至少 1 支繪圖鉛筆，至少 1 本記事貼或 N 次貼，3–5 張 A3 白紙。場地內還須要有一塊大的白板 or 白牆（須要能容納 100-200 張記事貼）。PPT 和幻燈設備根據狀況選擇；
4. Design Hackathon 整場須要 1 位主持人，主持人只負責引導和組織，原則上不提供任何關於產品的主觀導向。

1. 發散：解決問題的方式

在開始一切以前，咱們首先須要明確本身要解決的問題是什麼。咱們多是須要設計一個全新的產品，但咱們對這個產品只有模模糊糊的想法。咱們已經瞭解到一些用戶遇到的困難和問題，可是這個產品具體會以什麼樣的方式解決這些問題，呈現成什麼樣，應該有哪些功能和特色，咱們並不清楚。

解決任何一個問題的方式都是多種多樣的，咱們可使用「How might we……」的句式，從各個不一樣的角度分解問題，找出全部可能解決問題的方式。在這個階段，咱們須要的是開闊思路，追求的是全面的、打破常規的思惟和方向，不須要評價它是否是嚴謹，是否是可實現，更不須要提出具體的解決方案，解決方案將會在後續階段補充。

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

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

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

• 如何讓你們進入餐廳就天然知道點什麼菜？

  等等……

2. 頭腦風暴

經過前一步的預熱，咱們已經整理出產品開發中可能遇到的問題了。咱們接下來要作的，是基於這些問題，自由地、無拘無束地闡述解決方案。

咱們須要最大範圍地盡力去想各類可能的解決方案或 idea，不要限制本身的思惟。任何人想到一個 idea，就寫在紙條或卡片上。

能夠採用相似 N×5×5 的方式。N 表示全部參與頭腦風暴的人總數，這個式子表示須要每人在 5min 的時間內寫下 5 個想法，而後將這 5 個想法傳給下一我的，同時接收上一我的傳來的 5 個想法，再寫一輪，如此類推，N 輪事後，每一個人手中都會有 5N 個想法，全部人共有 5×N×N 個。全部人都要寫，可是相互之間不要交流。這樣，每一個人既會受到他人的激發，又不會受他人想法的限制。

圖1：每一個童鞋須要在 5 分鐘內，寫下 5 個想法貼在 1 張 A3 紙上，時間到就傳給下一我的，同時接收上一我的傳來的 5 個想法。

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

• 能夠在餐廳門口放上菜單，任顧客翻閱瀏覽；
• 能夠作招牌菜的海報或易拉寶展現；
• 能夠作食客最多點選的菜餚 list；

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

頭腦風暴中，須要全部人遵照幾項原則：

1. 不要關心老闆或者領導的意見；
2. 不要限制本身的想法，由於每每到了下一階段的執行，現實條件會給你限制的；\
3. 不要放棄捷徑，要站在巨人的肩膀上；
4. 不要講太過於抽象的東西，譬如「作一個更好的產品」；
5. 事先設定一個時間限制，不可草草結束或無限拉長時間。

3. 卡片分類和完善

經過上一步的頭腦風暴，咱們會蒐集到 100-200 個想法，甚至更多。這些 idea 都是感性的、靈光一閃的、零散的。這一步，咱們須要將這些 idea 組織起來，抽象出其中暗含的核心功能或需求。咱們須要對蒐集到的全部想法進行分類，大概分紅 5-7 類，每一個類別都須要有一個歸納性的標題。

分類沒有必定的規則，由於通常狀況下，這個分類不須要很是嚴謹，由主持人組織你們討論進行。每類下包含 idea 的數量應該差很少，若是有某個類別所包含的 idea 數量明顯少於其餘組，則須要你們一塊兒思考，爲這個分類再作補充，直到全部類別下 idea 的數量大體相等。

圖2：分類的維度不少，沒有嚴格的規則。

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

4. 方案設計

通過分類，這些頭腦風暴產生的零散想法之間就有了關聯，每個類別下的想法，對應的就是一類功能或需求。截至此階段，設計師們也會開始產生一些具象化的內容。這一步，咱們須要發動全部的設計師參與和貢獻：將全部的設計師分組，每一組設計師領走一個類別的卡片；根據這些卡片上的信息，設計師能夠開始繪製草圖和線框圖，也能夠出一個故事板。

對於每一個組，繪圖的過程和方式比較靈活，能夠是每位組員分工作，根據所拿到的 idea 作不一樣方面的草圖，也能夠組員一塊兒討論出一個草圖。對 idea 的取捨由設計師本身肯定。

圖3：設計師們出的線框圖

當全部的組都完成了草圖或故事板後, 主持人能夠進行簡單的點評。以後, 這些成果就能夠交給具體負責產品的設計師作正式的產品設計了。

總結

Design Hackathon 遵循了「從發散到抽象再到具體」的思惟過程。「發散」保證了咱們不會錯失有關產品設計的各類可能性和細節，「抽象」幫助咱們整理出想法中的產品邏輯和需求層次，而「再具體」的過程則保證了咱們全部的想法和需求都能落地成爲可見的設計。經過 Design Hackathon 的方式，咱們可以快速、準確地整理出一條正確的產品設計方向。

《Design Hackathon 方法手冊》PDF 下載：http://dl.wandoujia.com/files/public/Design-Hackathon-Tool-Handbook.pdf

---

via 豌豆家