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