轉載藍藍設計(   www.lzhte.cn  )是一家專注而深入的設計機構 ，為期望卓越的國內外企業提供有效的   BS界面設計 、  cs界面設計 、  ipad界面設計  、  包裝設計 、  圖標定制 、  用戶體驗 、交互設計、  網站建設 、平面設計服務

來源： http://beforweb.com/node/124

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

 

又是天氣不錯的周末，不冷不熱，一年里最舒服的一些時日了叭。感覺自從十一長假結束之后有些東西就變掉了，自己熟悉的很多事情、很多感覺，都像是在頭腦里向后退去了一層，要努力去抓才能讓它們回來的樣子誒。也許只是陽光泛濫了太久的緣故。

好叭。今次的譯文是我最喜歡的一類小菜，篇幅簡短，實戰性強。原文 作者，來自Frog的一名交互設計師，講述了她與朋友在共同設計開發拼車服務Ridejoy的iPhone客戶端 的過程中所遇到的一些挑戰以及相關的解決方案。前戲到這里，進入正文。

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應用的用戶體驗設計工作中遇到的幾個最大的挑戰。在這個過程中，我學到了一些重要的東西：

• 原型－測試－原型－測試 ：我們的團隊花了大量的時間去討論用戶需求，并提出相應的候選解決方案，然后通過線框原型及高保真交互原型與真實用戶進行交流測試，探索用戶的實際需求，驗證我們的假設，進行相應的修改，并不斷的進行這樣的迭代循環。(相關閱讀：初創型團隊容易在用戶體驗方面犯的十個錯誤 、精益創業 - 用戶體驗設計的新包裝 )
• 逐漸探索交互模式 ：我們在設計過程中嘗試了不同種類的導航模式，例如標簽欄(Tab Bar)、側邊欄(Sidebar)、儀表盤(Dashboard)等。我們為每種模式都繪制了草圖，把它們釘在墻上，完整的把各種模式的流程腳本都跑下來，討論哪種模式可以為Ridejoy帶來最佳體驗。
• 交付設計稿 ：作為一個希望在各種細節中做到完美的設計師，我在這方面著實有過不少糾結，我不知道用戶能否理解當前的設計方案，我不知道“當前沒有參加任何拼車活動”的界面是否還有優化空間...無論到什么時候，心里始終覺得還有一些東西可以調整。但項目有其自身的產出與迭代節奏，把握好交付設計稿的時間點，這是很重要的。(推薦閱讀：最小化可用性設計 )