如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

來源：莫貝網

Ridejoy拼車服務在Web端上線運營了幾個月之后，大家對當前的用戶基礎有了比較清晰的認知。而對于Ridejoy的iPhone應用來說，我們希望它不僅僅是網站的移植版本，它所能帶來的應該是更符合移動上下文環境的全新用戶體驗。

基于這樣的產品思路，我們識別出了三個關鍵性的挑戰：

• 怎樣鼓勵駕車者及搭乘者發布更多的信息？
• 怎樣快速有效的幫助駕車者及搭乘者進行匹配？
• 怎樣促進那些已被匹配的駕車者及搭乘者更有效的完成約定？

挑戰1：鼓勵用戶發布信息

大量的運載與搭乘信息是成功的拼車服務所必須具備的基礎。根據我們的了解，當前獨自駕車的人以及尋求低成本搭車的人都不在少數，但如果他們根本沒有興趣通過Ridejoy應用發布自己的需求信息，那么所謂的匹配及整個的拼車服務便無從談起。

要調動用戶的積極性，我們必須讓用戶充分了解“拼車”活動能夠帶給他們的價值與收益。

首先，我們分析了駕車者通常會出于怎樣的目的來發起拼車活動，并將這些原因列成一份清單。接下來，我(英文原文作者)對應著這份清單繪制了一些簡單 的草圖，將有可能符合駕車者需求的功能和內容初步的勾勒出來。然后，大家對這些草圖進行討論評估，將其中我們認為最可行的5個概念進一步落實到線框原型當 中，并向一些目標用戶(獨自駕車者)進行了展示，通過他們的反饋來驗證我們的假設。

最終我們發現，以下3個方面因素對駕車者是否會發起拼車活動起到重要的影響作用：

1. 搭乘者的形象(照片)
2. 潛在搭乘者的數量
3. 金錢收益

這輪研究和驗證最終幫助我們設計出了目前產品當中的“熱門目的地(Popular Destinations)”流程。用戶可以在其中瀏覽到拼車需求最旺盛的地區，還有以這些地區為目的地的駕車者及搭乘者的個人資料。在用戶尚未確定旅程 或確定是否發起拼車活動的情況下，這些方面的資訊可以最有效的幫助和“促使”用戶作出判斷。

挑戰2：加快匹配速度

人們不喜歡等待，我們必須幫助駕車者及搭乘者更快速有效的找到與自己的需求相匹配的信息。在Ridejoy網站版本的服務中，我們意識到，用戶在發起拼車活動時填寫的信息越完整，匹配的效率越高。問題在于，使用移動客戶端的用戶根本不愿或沒有時間去填寫詳細完整的信息。

為了解決這個問題，我們首先列出了駕車者及搭乘者有可能愿意填寫的信息。經過幾番討論，我們最終確定下來4個必填信息，同時還提供了一些比較靈活的 設置方式。例如，啟程日期是用戶在發起活動時必須填寫的信息；用戶可以在這里指定一個具體日期，也可以選擇一個時間段；第二種方式特別適用于行程計劃尚未 最終確定的用戶。

另外，拼車與其他交通方式有所不同，用戶在瀏覽活動資訊列表時，不僅會關注時間和目的地方面的信息，同時還會非常在意和自己搭乘同一輛車的其他乘客 的情況。為此，我們還允許用戶在發起活動時填寫這方面的補充信息。你喜歡安靜些的還是熱鬧些的旅程？你是持有AAA卡的會員嗎，是否需要Wifi？完善這 些方面的信息將進一步加快活動發起者及參與者的匹配速度。

挑戰3：促進約定的完成

拼車是一種非正式的、基于參與者自發執行的活動，整個過程中時常會出現各種各樣的問題。搭乘者找到一條合適的線路以及相關的拼車活動后，需要和駕車 者通過電話或短信頻繁的溝通確認。作為值得信賴的第三方服務提供者，我們有責任將這方面的功能整合到應用當中，使用戶之間的后續交流更加集約化規范化。

活動參與者之間的互相問答是避免不了的，我們要做的是提供一些方式，使這方面的交流過程盡量簡化。誰也不愿意看到在一番冗長的溝通和準備工作之后，其中某一方退出了拼車計劃。

為此，我參考了其他一些協同消費 (Collaborative Consumption) 類型的應用產品，例如Airbnb和Yardsale等等。在嘗試了多種流程及界面布局方式之后，我們決定采用一種輕量級的確認序列機制，它的操作界面類 似于大家所熟悉的短消息界面。無論駕車者還是搭乘者都可以發起確認；例如，旅程結束后，一旦搭乘者完成了支付，駕車者收到款項，此次拼車活動就會被確認完 成。

確認流程可以發生在多人甚至是多次行程之間，例如，你可以搭載一名乘客到洛杉磯，然后又搭載另外兩名不同的乘客返程，整個活動可以通過一套確認流程進行控制。

這個機制引導出了最終產品當中的儀表盤 (dashboard) 的設計方案，在這里，用戶可以查看自己所有的行程、提醒、確認信息等方面的資訊。

我們學到了什么

以上就是我們在Ridejoy應用的用戶體驗設計工作中遇到的幾個最大的挑戰。在這個過程中，我學到了一些重要的東西：

1、原型－測試－原型－測試：

我們的團隊花了大量的時間去討論用戶需求，并提出相應的候選解決方案，然后通過線框原型及高保真交互原型與真實用戶進行交流測試，探索用戶的實際需求，驗證我們的假設，進行相應的修改，并不斷的進行這樣的迭代循環。

2、逐漸探索交互模式：

我們在設計過程中嘗試了不同種類的導航模式，例如標簽欄 (Tab Bar)、側邊欄 (Sidebar)、儀表盤 (Dashboard) 等。我們為每種模式都繪制了草圖，把它們釘在墻上，完整的把各種模式的流程腳本都跑下來，討論哪種模式可以為Ridejoy帶來最佳體驗。

3、交付設計稿：

作為一個希望在各種細節中做到完美的設計師，我在這方面著實有過不少糾結，我不知道用戶能否理解當前的設計方案，我不知道“當前沒有參加任何拼車活 動”的界面是否還有優化空間…無論到什么時候，心里始終覺得還有一些東西可以調整。但項目有其自身的產出與迭代節奏，把握好交付設計稿的時間點，這是很重 要的。

 

原文地址：jasonshen
譯文地址：beforweb
譯者：@C7210

藍藍設計( m.0391cbd.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供有效的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務