3年5000萬安裝量：我們是怎麼設計豌豆莢的

　　一

　　今年 2 月份的時候，我們發布了豌豆莢 Windows 版 2.0。這個項目的設計和開發時間有 10 個月之久，這對很多公司來說可能並不算長。但考慮到這 10 個月占據豌豆實驗室當時兩年歷史的接近一半，豌豆莢 2.0 對於我們來說就顯得很重要了。

　　2009 年年底，我們開始豌豆實驗室的時候，就希望做不一樣的公司、開發不一樣的產品。用我們的產品和技術，來幫用戶解決問題。而不是像很多同行一樣，用其它的更捷徑的方式。兩年的時間裡我們做了很多嘗試。有些嘗試失敗了，也有些嘗試成功了。

　　「成功」有一個簡單的標准，即被「借鑒」。2010 年，我們剛剛推出第一代產品的時候，用了和過去的類似軟件很不一樣的產品設計，特別是功能大為減少。有些朋友憂心我們的產品過於簡潔，也有人警告我們說，這種「陽春白雪」的產品在中國是走不通的。但時至今日，我們已經擁有了超過 5000 萬的安裝量，而今天市面上所有有點影響力的桌面手機管理軟件，基本上也並沒有脫離開豌豆莢定義下來的框架。可以說，我們在過去兩年的時間裡重新定義了桌面手機管理軟件。

　　我們不介意別人對我們的跟隨，因為當別人還在跟隨我們的時候，我們其實已經給明天做好了准備。

　　這就是豌豆莢 2.0 的設計背景。

　　二

　　為什麼要動手做豌豆莢 2.0?要回答這個問題，就得知道豌豆莢 1.0 是在什麼樣的環境下出爐的。

　　豌豆莢 1.0 開始開發於 2009 年 12 月，當時市面上最為流行的 Android 手機是 HTC Hero，Motorola Milestone 剛剛推出，Nexus One 還不見蹤影，Android 手機在國內的數量，應該僅在百萬級別。這種情況下我們將豌豆莢專注在 Android 上，其實上是一種冒險。實話實說，我們自己也並不清楚用戶需求到底是什麼樣的。

　　因此，對於豌豆實驗室來說，最重要的任務就是盡快推出最小可用的原型產品(Minimum viable product, MVP)，驗證用戶需求。

　　說到這裡稍微繞遠一點——為什麼這些年來很少創業公司會選擇 Windows 客戶端這個領域?原因很簡單：開發成本太高。要做一個非常好的 Windows 客戶端實在太難了，要比做 Web 服務、iOS、Android 應用都要難得多。這也是為什麼我們現在想把我們創造的這種 Web 客戶端的框架開放出來的原因，因為實在太難了。

　　因此，可以理解為什麼豌豆莢最早選擇了用 .NET framework 來開發——在開發效率還是用戶體驗這個問題上，我們選擇了開發效率。盡管這個決定後來被屢屢诟病，但即使再來一次，我們也一定會做同樣的選擇——因為這可以確保我們能用最快的速度將產品推向市場，迅速摸清用戶需求。快速迭代。

　　所以你可以想像，那時候我們的心態是：盡快用積木搭個能走的小車，別的再說。即使很小車不牢靠，但至少能走。而能走了以後，我們應該有時間重新做個好點的車。

　　一晃一年過去了。2011 年 2 月份，我們迎來了第 100 萬個用戶。如我們所料，用戶需求變化很快，一年的時間裡面產品進行了多次大幅改動，但基礎仍然是那個用積木搭成的小車。

　　積木小車已經不堪重負了，已經有太多的新功能、太多的缺陷，不推倒重來無法解決。

　　三

　　我們最終下定決定要推倒重來，重新設計和開發豌豆莢。這是在 2011 年的 2 月份。扔掉 .NET framework 的架構，重新用 C++ 開發——我們知道這是一件很難的事情。但，實際情況比我們想象的還難。

　　無知者無畏。

　　我們最初的計劃是 在2011 年 6 月發布豌豆莢 2.0。不過，到 5 月份的時候，我們估計新產品在 7 月份發布的話，可以比較安全。到 6 月份的時候，我們再次估計在 9 月應該能發布，這樣我們能過個美好的國慶長假。可是到了 9 月份的時候，估計的時間點變成了新年前後。董事會上馮鋒承諾，如果新年前還無法發布，就要服毒自盡(幸好後來沒有人提起過這件事情)。最後，我們是在 2012 年 2 月 22 日發布的。

　　這個日子其實也不是刻意挑的，而是因為豌豆莢 2.0 各項指標終於在一周前都基本達標了。

　　回頭一看，我們當時隨意用積木搭成的小車，居然在這整整 10 個月的時間裡一路高歌猛進，安裝量從 100 萬變成了 2500 萬。這真是一件讓人吃驚的事情。

　　不管怎麼樣，總算是發布了。

　　四

　　2011 年 3 月，我們開始進行豌豆莢 2.0 的設計工作。豌豆莢 2.0 要解決什麼問題?

　　傳統的理解需求的過程，有許多不同的方式。例如，直接進行用戶訪談，發放調查問卷，購買市場研究報告，或者聽聽意見領袖們怎麼說。

　　我們的方式，就是依賴直覺和經驗。

　　這有兩個前提條件，一是豌豆莢已經運營了一年，我們自信對用戶需求的理解已經有了一定的積累;二是實際上在當時來看，已經不是不清楚用戶需求的問題，而是用戶的大量需求我們原有的產品和技術架構無法滿足的問題。因此我們做的第一件事情，就是把我們腦海裡面堆積如山的想做的事情整理出來。

　　第二件事情，豌豆莢的願景在一年多的時間裡也慢慢變得清晰。將這個願景整理成思維導圖，我們就擁有了一個幾年內的路線圖。豌豆莢 2.0 如何和這一願景相匹配，也就是一件自然而然的事情了。

　　和各種各樣的頭腦風暴的過程一樣，需求的收集是一個開放的過程。這裡面會有各種各樣的聲音，但需要產品設計師來歸納和整理。

　　與此同時，工程師們也在做早期技術方案的探索。早期的探索過程就像上圖所示意的一樣。你需要不斷地發散，又需要不斷地拒絕掉不那麼靠譜的想法，留下那些靠譜的，並且進行下一個階段的發散。如此反復，你就在這發散與收斂的過程中取得了進展。

　　五

　　豌豆實驗室使用 Google Docs 辦公。在初步的想法確定下來以後，我們就開始使用 Google Docs 協作，不斷把我們對產品的想法積累下來。在紙面上推演的時間花了一兩個月的時間，我們維護了一個文檔，一直在更新。這種時候，是不需要關心能不能做出來，也不需要趕時間的。

　　不是所有的溝通工作都適合用開會這種形式來解決。尤其是對產品的想法，很多時候可能就是躺在床上睡著之前的靈光一現，如何更有效地捕捉到這種靈光，比何高效地溝通更重要。

　　所以那段時間我們在 Google Docs 上維護了兩個文檔，一個是基礎框架的需求，只要想到什麼東西，我們就會添加進去。可能其它的同學過了幾天甚至是幾周的時間突然在這個基礎上想到了什麼新的想法，才會上去回復進去。Google Docs 的評論功能非常適合於進行這種異步的討論。

　　另外一個是所有功能的列表。這個文檔叫 One-Pager，本意是在一頁內將所有的功能寫進去，結果最後發現打印出來有 10 頁長。

　　靈感一發不可收拾，我們寫了很多文檔，放在同一個目錄裡面。和一部分設計項目的過程不同，到這裡為止，我們還沒有動手畫任何東西。不是不想畫，而是強忍住了畫出來的沖動。我們覺得，應該先從比較抽象和邏輯的層次，把產品的思路整理清楚。

　　這張圖是我用來做規劃的工作，在這裡面列出了豌豆莢所有的頁面和功能，確保不會出現大的遺漏。這同時也做為工作規模和進度的估計，看這張圖，我們就能知道有多少工作已經完成，有多少工作還沒有做。

　　設計工作往往是發散的，但經過之前的鋪墊，我們已經整理出“再設計工作”的幾條主線。其中之一，就是對信息架構的改善。類似這樣的主題，我們在 Basecamp 中創建了不同的 To-Do 列表，方便頭腦風暴要解決的問題，同時也一個個劃掉，確保項目始終圍繞著重設計要解決的問題來進行，不過分發散。

　　我們有時候引入大量的討論，但又注意不和所有的人討論。在豌豆實驗室這種開放透明的工作環境中，如何「管理」好其他人的腦力是一個挑戰。你希望其他人的觀點、知識、經驗是能對你的項目帶來幫助，又不希望會對你的決策帶來干擾，避免「集體決策」的結果。

　　六

　　Jesse James Garrett 在《用戶