一

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

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

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

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

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

二

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

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

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

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

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

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

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

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

三

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

無知者無畏。

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

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

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

不管怎么樣，總算是發(fā)布了。

四

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

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

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

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

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

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

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

五

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

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

所以那段時間我們在 Google Docs 上維護了兩個文檔，一個是基礎框架的需求，只要想到什么東西，我們就會添加進去?？赡芷渌耐瑢W過了幾天甚至是幾周的時間突然在這個基礎上想到了什么新的想法，才會上去回復進去。Google Docs 的評論功能非常適合于進行這種異步的討論。

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

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

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

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

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

六

Jesse James Garrett 在《用戶體驗的要素》 [PDF] 這張著名的圖表中，將用戶體驗劃分為幾個不同的層次。隨著設計的過程從抽象到具象，產品也一步步走向完整。

接下來的設計過程就是一個從抽象到具象的過程。

我們開始有手繪的線框圖。

為了探索更好的信息架構，嘗試了各種各樣的方案。基本上是按照排列組合的方式，把各種可能的情況都試了一遍。

就和之前那張示意圖一樣，設計的過程就是不斷發(fā)散嘗試，同時也不斷拋棄自己的嘗試，挑選勝出者，再進行下一輪的發(fā)散和拋棄。

這種不斷發(fā)散地嘗試在什么時候可以停止呢?一直到出現(xiàn)一些自己滿意的方案為止。什么叫一些?什么叫做自己滿意呢?就是覺得沒有什么可以改了。高質量的設計一定是有滿墻的迭代草稿做為基礎。第一稿就非常完美，有可能性，但非常罕見。

同時我們也開始了視覺設計的工作。這是不符合一般設計項目的流程的，但我們的時間不允許做完所有的交互設計，再進入視覺設計這一流程。

七

前文再續(xù)，說到我們一邊畫線框圖，一邊就請我們遠在紐約的視覺設計師開始開展了視覺設計的工作。一方面是因為這樣比較節(jié)省時間，另外一方面也和項目參與者的技能比較有關。我和劉亞平(豌豆莢的產品設計師)都不擅長視覺設計，但自認還是有能力將一個比較完善的視覺設計語言應用到已有的產品上的。

因此，在視覺設計的基本樣式出現(xiàn)后，我們整個設計的過程基本上就是直接輸出高保真的設計稿的過程。從沒有草圖到線框圖到視覺設計稿的過程后，效率提高了很多，依賴已經確定的視覺風格，也可以保證不出現(xiàn)沖突，還有高度的一致性。

借助這個風格的工作模式，我們往往在一張圖上會同時標注產品邏輯和呈現(xiàn)大量細節(jié)的視覺實現(xiàn)指南。通過這種方式，我們可以一步到位地和開發(fā)人員講清楚我們需要的是什么。這是非常重要的，很多復雜的交互中，有一點點不清楚，要返工的成本可能就會非常高。這張圖展示的是對通用搜索功能的設計，設計師需要考慮到拼音首字母、標點符號全角還是半角等等的細節(jié)。然而，即使做到這個程度，仍然出現(xiàn)了很多因溝通不清而出現(xiàn)返工的情況。

這是豌豆莢 2.0 左側導航的部分設計稿，我們遍歷了所有的狀態(tài)，力圖在產品定義中將所有情況都考慮到。

我們的經驗是，不要拘泥于教科書上的流程——當然，你需要了解。在這個階段，也要和所有人討論，讓他們告訴你各種各樣的邊緣情況。

八

整個設計過程我們進行了數百次嘗試。實際數字應該要比這個多，因為我們都沒有每做一次，就保存一次版本的習慣。

在確定了歡迎頁面的主要任務是加強用戶和自己手機之間的情感聯(lián)系后，我們首先是收集了一些圖片，來溝通我們希望這個頁面?zhèn)鬟_什么情感。

然后在這個基礎上進行了各種概念的探索。

比如，是不是在歡迎頁面上顯示通知、手機里面的圖片、推薦應用等等：

只顯示圖片：

顯示應用：

將手機的墻紙取出來，和歡迎頁面結合到一起去?我們收集了一些常見的壁紙，進行了效果模擬：

在確定了幾個比較明確的方向后——使用我們向用戶推薦的應用，要結合用戶在手機上設置的墻紙——我們進行了更多的探索：

這是最后的樣子：

這期間，為了探索交互的效果，我們還開發(fā)了幾個可交互的動畫原型，供設計師們實際評估。豌豆莢 2.0 的 Web 框架也會這些效果的實現(xiàn)帶來了便利。

前面說到，如果沒有數量眾多的迭代，不大可能有一個好的設計。豌豆莢 2.0 就是其中一個案例。

　　九

然后就是漫長的設計、開發(fā)、返工、再設計、再開發(fā)的過程。我們一直看著那張大圖。

2011 年 8 月，我們發(fā)了第一個公測的版本，發(fā)電郵邀請了幾萬位熱心用戶參與測試。從這時候開始，我們用盡了各種定量和定性的辦法來不斷邀請用戶參與，不斷評估效果。從傳統(tǒng)的可用性測試、到性能數據評估、到定量的問卷調查等等。到 2012 年 2 月我們的各項指標終于都滿足條件，準備正式發(fā)布時，豌豆莢 2.0 已經積累了超過 100 萬的測試用戶。

回頭來看，豌豆莢的愿景仍然有大部分沒有實現(xiàn)。上面的這些設計，在發(fā)布后的半年多時間里也在不斷進行調整，有不少設計已經又被我們認為更好的設計取代了。而且，我們的路線圖里面還有更多我們認為可以再次改變整個產品體驗的想法。我們現(xiàn)在有一個五位產品設計師組成的產品設計團隊，但我們要做的事情還有很多。現(xiàn)在豌豆莢總安裝量超過 6000 萬，豌豆莢 2.0 的安裝量超過 5000 萬，但遠遠不是我們理想的全部。

來源：王俊煜