我們始終覺得，在項目當中犯錯是在所難免的；只要能夠從中學到一些東西，這些錯誤就能引導我們向正確的方向前進。從某種程度上講，將我們的產品一點點推向成功的也許正是一路上所犯下的那些錯誤。
重要的設計原則
在開始討論我們從錯誤當中學習到的那些經驗之前，我想先來聊聊我們的一個重要設計原則：
先驗證，再開發。
接下來具體說說是怎么回事。
我們打造Buffer的初衷是創建一種“聰明”的方式，讓用戶可以更高效地在Twitter等社交網絡平臺當中同步發布內容。這個想法剛剛冒出來的時候，我們的創始人Joel Gascoigne立刻開始著手寫代碼，而不是首先去驗證想法。在寫了幾分鐘之后，他才意識到這可能不是正確的方式。
接下來，Joel為這個目前還不存在的產品創建了一個介紹頁面，并把鏈接放在Twitter上進行傳播。對這個想法真正有興趣的潛在用戶會通過鏈接來到介紹頁面；在他們點擊了“服務方案及價格”按鈕之后，接下來的一個頁面會告訴他們，產品目前還沒有完工，請留下郵箱以便在產品上線后的第一時間獲得通知。
從這件事情出發，我們在接下來的歷程當中逐漸歸納出了三點最重要的設計原則及經驗：
o 整個產品或某個新功能的第一版要盡量保持最小化。
o 做好心理準備：項目很可能是長期的，而且會涉及到多次轉型。
o 任何新的主意和想法都需要首先進行驗證。
聊過了總體上的經驗心得，接下來，我將通過一些實際的例子向大家更加具體地介紹一下我們在項目當中所學到的那些東西。
[Page: ]
第一課：流程應該聚焦在“用戶保留”而不是收益上
關于用戶體驗，我們在項目早期學到的重要一課，就是要將流程聚焦在“用戶保留(user-retention)”而不是產生收益上。
我們是怎樣了解到這一點的呢？不妨先來看看Buffer上線之后最初版本的注冊申請流程：
o 用戶在介紹頁面點擊了“服務方案及價格”按鈕之后，會被引領到一個介紹具體服務類型的頁面。
o 在這個頁面里，用戶需要在免費或付費方案中做出選擇。
o 選擇了服務類型之后，用戶需要填寫用戶名、郵箱地址等信息，完成注冊。
當時，確實有不少用戶會選擇付費方案，這看上去完全不是壞事。不過我們很快發現，這類會在實際使用產品之前就選擇付費方案的用戶的流失率是非常大的。其中一部分人在付費之后幾乎不怎么使用產品，有些甚至還退訂了付費服務。
于是我們試著修改了這一流程，不在這里要求用戶進行方案選擇；我們對自己說：“還是首先讓用戶自己去體驗產品并判斷Buffer帶給他們的價值吧，在正式使用之后再鼓勵他們根據需求升級到相應的付費版本好了?！?/P>
修改后的流程就是大家現在可以在Buffer的網站當中看到的：用戶可以通過他們的第三方賬號直接登錄并體驗免費方案中的所有功能，完全無縫地即刻開始使用產品。
相關流程的重新設計產生了以下兩方面的結果：
o 有更多的人開始使用我們的產品，因為我們去掉了服務方案選擇頁面及相關的注冊流程，減少了不必要的障礙。
o 有更多的人升級到了付費方案，因為他們可以很直接很容易地進入使用狀態，發現其中的價值，決定與我們并肩同行。
后來，我們對產品做了很多改進，包括增加了更多的免費功能，另外產品的核心功能始終是免費的。只有確信用戶已經體驗到足夠多的價值，我們才會向他們推薦付費的升級方案。
聚焦于用戶保留，這是我們學到的重要一課。
[Page: ]
第二課：社會化登錄比傳統Email登錄更有效
為了提升主頁當中的轉化率，我們做了很多嘗試，并進行了一系列的A/B測試，結果都不是很理想。最終，我們決定嘗試社會化登錄的方式，即允許用戶通過他們的Twitter、Facebook或LinkedIn的賬戶來直接登錄。
畢竟，Buffer這款產品就是為了方便用戶同步在Twitter、Facebook和LinkedIn當中發布內容用的，所以這樣做也非常符合邏輯，用戶可以通過他們的相關賬號直接使用Buffer，減少了不必要的麻煩。
出于對比的目的，我們來看看Buffer在使用社會化登錄之前所采用的傳統注冊方法：
這一改變極大地推動了用戶量的增長，轉化率提升了將近50%，實際上在切換登錄方式的當天，日增長數就由500變成了800的樣子。
[Page: ]
第三課：盡早驗證每一個假設
我們曾經有一個重新設計瀏覽器插件的主意，它最終失敗得很慘。
瀏覽器插件是整個Buffer產品的一個重要組成部分，它可以幫助用戶直接將Web頁面上的內容添加到自己的“buffer”當中并分享到社交平臺，整體體驗非常棒。
所以很自然的，我們會將注意力放在瀏覽器插件上，希望盡可能地對其進行改進，實現一些更酷的點子。不過在改進的過程中，我們似乎又撿起了過去的一些壞習慣，犯了一些本該避免的錯誤。當時的步驟是這樣的：
o 我們識別出Buffer的瀏覽器插件中存在的一些問題，頭腦風暴了想要改進的地方。
o 接下來，我們花費了大量的時間與資源，重新設計并開發了全功能的新版本插件。
o 完工之后的測試當中，我們發現新版本插件給用戶帶來了極大的困惑。
o 最終我們決定放棄這個版本的插件。
各位在下圖當中看到的就是這個永遠沒有上線的失敗作品：
可以說，正是這次失利讓我們將“盡早驗證每一個假設”的原則深深地印在了腦海里，成為了今后的一種習慣。
如今，我們要改進產品或是要實現一些新功能時，會通過以下步驟進行：
o 識別已有問題，確定需要改進或新增的點。
o 與現有用戶進行溝通，了解他們是否在使用過程中也遇到了這些問題。
o 想法得到初步驗證后，快速制作線框稿或低保真可交互原型。
o 再次與用戶進行溝通，向他們展示原型，觀察他們的交互行為。
o 重復這樣的過程，直到最終確定設計方案。
o 持續追蹤各種指標，保持與用戶的溝通，驗證新版產品的表現。
[Page: ]
第四課：清晰易懂的UI文案
這一點我考慮了很久：對于標題、按鈕、提示信息等UI元素，要在條件允許的情況下盡可能使用清晰易懂的文案，而不是其他看似聰明卻會給用戶帶來認知負擔的形式。
Intercom的Des Traynor在一篇文章中對這個問題進行了定義：
你針對用戶的實際需求打造了很棒的功能，卻發現他們根本沒在用它。很多時候，這是因為用戶沒有看到這個功能，或是雖然注意到，卻不了解它是做什么的。
這樣的問題是我們在項目中時常會遇到的。舉一個很具有代表性的例子：在Buffer中，你可以將自己在若干社交平臺當中的賬戶整合起來，集中發布內容。譬如，你使用Twitter的賬戶登錄后，有可能需要將Facebook以及LinkedIn的賬戶也添加進來，如下圖所示：
我們曾經認為，使用一個加號引導用戶添加賬戶是一種非常聰明的做法。
不過事實并非如此，我們不斷收到用戶的郵件，詢問究竟怎樣才能將他們的其他賬戶添加到Buffer當中。
于是我們做了一些改進，例如使用了更大的加號圖標，以及類似的一些小調整。不過最后也是最有效的解決方案卻是非常簡單的：直接使用“連接更多賬戶”的文案代替加號按鈕，讓信息的傳達更清晰更有效。
從這件事情當中，我們認識到，即使需要在外觀形式上做出犧牲，也要選擇對用戶來說更清晰易懂而不是看上去更酷的解決方案。
小結
我們相信自己的公司以及Buffer這款產品仍然處于初期階段，所以即使到現在，很多設計流程和方法也許仍然是具有試驗性且有待驗證的。
對于我們來講，之前的歷程帶給我們的最大啟迪仍然是：不依賴于某個想法，而是要將每個新功能新設計方案都看做需要驗證的假設。
我們有計劃去落實更多的想法，實現更多有意思的功能，但同時也做好了將其中大部分扔掉的準備。我們相信，從長期的角度來看，這樣的思維方式可以幫助我們打造出用戶真正需要的產品。
