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

 

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

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

今年，我們(英文原文作者及團隊)發(fā)布了FreshBooks 的第一款iPhone應用。從前我們的產品一直是通過Web端應用的方式提供服務的。這次，我們把iPhone應用的設計開發(fā)過程看作一張空白的花布，盡力在其中實現一些新的功能概念和設計想法。在這個過程中，我們著實學到不少東西。

不要害怕犯錯

對于移動應用這樣的產品，設計過程中必然會遇到很多用戶體驗方面的問題與挑戰(zhàn)，尤其是對于新手來說更是如此。

無論你的線框稿在邏輯上有多縝密，UI稿在視覺上有多漂亮，當它們落實成為原型或最終產品時，總會有問題呈現出來。這并不完全是壞事；我們在設計FreshBooks的iPhone應用時甚至將犯錯這件事也納入到了流程規(guī)劃當中，這就意味著：

• 坦承沒有完美的設計，無論稿件和原型多么優(yōu)秀。
• 真正的成功或失敗都是由用戶的反饋來定義的。
• 對于在設計過程中看到的問題要迅速做出反應，根據從實際用戶身上得來的驗證結果進行迭代。

接下來，我將向各位描述一下我們在項目中犯過的三個錯誤，以及我們是怎樣解決這些問題的。

應用的主界面

在項目開始的時候，我們對FreshBooks的一些現有用戶進行了訪談，了解他們在生活和工作中是怎樣使用移動設備的，包括他們面對的實際問題，以及他們對移動應用版本的FreshBooks的期望。

根據這些訪談，我們歸納出了一些基本的設計原則，例如下面這條：

以任務為中心的用戶體驗

移動應用版本的產品應該圍繞著一系列互不相關的帳單任務進行優(yōu)化，包括時間追蹤、為收據拍照存檔、開票等等，這些是移動應用所處的使用場景當中最常見的任務。

而其他方面的復雜任務，包括批量編輯、權限管理、定制化等，則留給傳統(tǒng)的Web端應用來承擔，以此來保證移動版本在功能上的簡約與集中。

基于這條原則，我們設計了應用的主界面。它由一系列最重要的任務組成，視覺上采用圖標加文字標題的形式，點擊進入相應的任務流程。例如，用戶點擊了其中的“創(chuàng)建新發(fā)票”之后會進入發(fā)票列表界面，然后創(chuàng)建新發(fā)票的界面會自動滑入視圖。

這種以典型任務為中心的設計思路在意圖上是好的，但接下來我們發(fā)現了一些問題。

為什么會出問題

經過可用性測試，我們發(fā)現被測者普遍會在主界面中產生困惑，因為這種設計方案與他們通過使用Web端的FreshBooks所建立起的心智模型不符，而且和很多其他的iPhone應用也存在模式上的差異。

同時我們還發(fā)現，之前歸納出的一些典型任務，包括創(chuàng)建發(fā)票、跟蹤時間、記錄開支等，對于用戶來說，本質上都屬于一種“創(chuàng)造”行為。從這個角度看，其實我們忽略了這個緯度上的其他一些重要任務類型，包括：

• 查看：例如查看發(fā)票狀態(tài)、查看歷史記錄等。
• 更新：例如更改發(fā)票狀態(tài)等。

這類任務需求其實比“創(chuàng)造”更加普遍，尤其是在移動設備上，用戶更加傾向于在短時間內以最簡單的方式查看和更新內容，而不是創(chuàng)造內容。我們之前所聚焦的重點則恰恰相反。

解決方案

很簡單，我們改變了之前方案當中的信息結構，使內容和功能的組織結構更加符合用戶在移動應用上下文環(huán)境中的預期。在新的設計方案中，用戶點擊主界面中的“發(fā)票”(之前是“創(chuàng)建新發(fā)票”)，進入發(fā)票列表界面進行查看；如果他確實需要創(chuàng)建新發(fā)票，那么可以點擊右上角的加號按鈕。

相關閱讀：產品早期的原型設計與用戶測試

初次使用的體驗

我們特別為應用初體驗(用戶安裝應用后第一次打開)制訂了兩條設計原則：“移動優(yōu)先”與“順暢進入任務流程”。具體來看：

移動優(yōu)先

如今，我們不能再假設用戶是通過桌面設備上的Web瀏覽器找到我們的，他們很有可能是在移動設備上與我們發(fā)生第一次接觸的，我們不能讓這類新用戶產生復雜的認知負擔。舉個例子，我們的Web端應用可以為用戶提供定制化的子域名(youraccountsubdomain.freshbooks.com)，這顯然是專屬于Web端的概念，完全不需要在移動端體現出來。

我們還可以隨著產品價值的逐漸體現而將Web端的高級功能一點點的介紹給移動端用戶。

順暢進入任務流程

要讓新用戶在打開應用之后無需任何設置工作就可以順暢進入任務，從而在最短的時間內發(fā)現產品價值。

為了貫徹這些原則，我們在第一版當中允許用戶不執(zhí)行任何注冊或登錄的操作就可以立刻在主界面當中執(zhí)行任務(例如前面提到的創(chuàng)建發(fā)票、跟蹤時間等)，只有在功能需要的時候才會引導他們進行帳戶方面的操作，例如在保存發(fā)票或收支記錄時會要求用戶創(chuàng)建帳戶或登錄。

另外在用戶選擇通過SnailMail發(fā)送發(fā)票的時候也會如此。

為什么會出問題

我們的用心是好的，但是在可用性測試中，我們發(fā)現被測者們更期望在應用加載之后首先進行注冊或登錄；直接讓他們進行操作反而會引發(fā)他們的疑慮，例如數據怎樣保存？

這種先操作后注冊/登錄的方式也許相對有新意一些，而且會適合于某些類型的應用，但對于我們的產品來講還是過于激進了。

解決方案

最后我們采用了一種相對傳統(tǒng)但更加符合用戶預期、可以給他們帶來安全舒適感覺的方案，也就是一開始就向他們提供三個明確的選項：

• 創(chuàng)建新帳戶
• 登錄已有帳戶
• 直接試用

如果用戶覺得自己已經準備好了，那么可以進行注冊和登錄操作；他們還可以在不登錄的情況下先試用，以便對產品進行更全面的了解。

相關閱讀：初創(chuàng)型團隊容易在用戶體驗方面犯的十個錯誤

移動版與Web版的功能差別

我們在設計流程開始之前詳細規(guī)劃了移動版產品在初期的功能范圍，也就是對我們的最小化可行產品(MVP)的形態(tài)進行界定。我們相信：

• 在功能范圍上未經詳細定義的移動版產品(特別是第一版)具有很大的風險，在設計開發(fā)流程中將產生極大的不確定性。
• 在初期對產品功能范圍進行合理的界定，將有助于那些基于市場及用戶研究所得出的核心需求被更加準確的落實到最終產品當中。
• 早已投放市場并經過驗證的Web端產品功能無法代表移動版的需求。移動應用有其特定的使用環(huán)境和場景。
• 移動版本中的某些功能會依賴于Web端。提前做好規(guī)劃工作，將有助于開發(fā)工作的順利進行。例如，移動版特有的為收據拍照的功能要求Web端必須具有相應的功能支持，包括查看收據照片等等。

不過，正像在前文中提到的，我們曾經假設用戶最想要的是快速創(chuàng)建內容。因此，在界定功能的時候，我們基于這個錯誤的假設將核心功能限制在了這個范圍當中。

報表

以財務報表為例，這是FreshBooks的Web版本當中的一個核心功能，但由于其規(guī)范化的格式難以適應移動設備的界面規(guī)格，加之我們初期一直將重心放在“創(chuàng)造內容”上，所以我們決定在移動版當中舍棄掉這個功能。

為什么會出問題

財務報表其實是財務軟件當中非常重要的一部分。我們在界定功能范圍的時候將這部分功能從移動版當中移除，結果在可用性測試中發(fā)現這完全不符合被測者們對于一個功能完整的財務軟件的認知與期望。

另外我們也意識到，在現實中，如果移動版的產品當中不包含這項功能，那么新用戶很有可能根本無法了解到其實我們的Web版應用是提供了這個功能的，他們?yōu)榇硕艞壴摦a品的幾率會變的很大。

解決方案

我們顯然不是平白無故將報表功能從移動版本當中移除的，它在呈現方式上確實存在著難以解決的問題，但實際上這個問題并非一定要被解決——通過進一步思考，我們認為用戶的真正目標并不是一定要在移動設備上看到報表，對他們來說最重要的是了解到有這樣一個功能存在，以及可以怎樣去查看這些內容。

最終，我們決定在移動端增加報表的入口，用戶點擊后會被引導進行注冊或登錄。已經處于登錄狀態(tài)的用戶可以選擇“將報表發(fā)到我的郵箱”或“在iPhone的Safari瀏覽器中直接查看”，同時界面還會提示用戶，瀏覽報表的最佳方式是使用臺式設備。

相關閱讀：

• 優(yōu)秀的用戶體驗設計師應該做好的五件事
• 精益創(chuàng)業(yè) - 用戶體驗設計的新包裝

總結

勇于挖掘并面對設計當中的錯誤與問題，并思考相應的解決方案，這是不斷提升產品價值及用戶體驗的關鍵要素。提出假設、與真實的用戶進行溝通、驗證假設并發(fā)現問題、思考解決方案、迭代——是我們在設計工作當中應該保持的良好節(jié)奏。