咱們在設計iPhone應用時犯過的錯誤

本文是由FreshBooks的產品經理和創意總監所寫的開發實例。FreshBook是一款在線的發票服務軟件，其服務的用戶羣體，決定了他們提供的功能必須在操做上簡單、快速、高效。所以，他們的產品界面和功能體驗上有着很高的要求。本文就是他們在具體實踐方面的經驗之談。

如下正文，以做者爲第一人稱編譯：

今年，咱們(英文原文做者及團隊)發佈了FreshBooks的第一款iPhone應用。從前咱們的產品一直是經過Web端應用的方式爲客戶們服務 的。此次，咱們把iPhone應用的設計開發過程看做一張空白的花布，盡力在其中實現一些新的功能概念和設計想法。在這個過程當中，咱們着實學到很多東西。

不要懼怕犯錯

對於移動應用這樣的產品，在設計開發過程當中必然會面對很多較爲複雜的用戶體驗設計方面的挑戰與問題，尤爲是對於新手來講更是如此。

不管你的線框稿在邏輯上有多縝密，UI稿在視覺上有多漂亮，當它們落實成爲原型或最終產品時，總會有問題呈現出來。這並不徹底是壞事；咱們在設計FreshBooks的iPhone應用時甚至將犯錯這件事也歸入到了流程規劃當中，這就意味着：

坦承沒有完美的設計，不管稿件和原型多麼優秀。

真正的成功或失敗都是由用戶的反饋來定義的。

對於在設計過程當中看到的問題要迅速作出反應，根據從實際用戶身上得來的驗證結果進行迭代。

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

應用的主界面

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

根據這些訪談，咱們概括出了一些基本的設計原則，例以下面這條：

以任務爲中心的用戶體驗：

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

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

基於這條原則，咱們設計了應用的主界面。它由一系列最重要的任務組成，視覺上採用圖標加文字標題的形式，點擊進入相應的任務流程。例如，用戶點擊了其中的「New Invoice」以後會進入發票列表界面，而後建立新發票的界面會自動滑入視圖。

這種以典型任務爲中心的設計思路在乎圖上是好的，但接下來咱們發現了一些問題。

爲何會出問題

通過可用性測試，咱們發現被測者廣泛會在主界面中產生困惑，由於這種設計方案與他們經過使用Web端的FreshBooks所創建起的心智模型不符，並且和不少其餘的iPhone應用也存在模式上的差別。

同時咱們還發現，以前概括出的一些典型任務，包括建立發票、跟蹤時間、記錄開支等，對於用戶來講，本質上都屬於一種「創造」行爲。從這個角度看，其實咱們忽略了這個緯度上的其餘一些重要任務類型，包括：

查看：例如查看發票狀態、查看歷史記錄等。

更新：例如更改發票狀態等。

這類任務需求其實比「創造」更加廣泛，尤爲是在移動設備上，用戶更加傾向於在短期內以最簡單高效的方式查看和更新內容，而不是創造內容。咱們以前所聚焦的重點則偏偏相反。

解決方案

很簡單，咱們改變了以前方案當中的信息結構，使內容和功能的組織結構更加符合用戶在移動應用上下文環境中的預期。在新的設計方案中，用戶點擊主界面 中的「發票」(以前是「建立新發票」)，進入發票列表界面進行查看；若是他確實須要建立新發票，那麼能夠點擊右上角的加號按鈕。

初次使用體驗

咱們特別爲應用初體驗(用戶安裝應用後第一次打開)制訂了兩條設計原則：「移動優先」與「順暢進入任務流程」。具體來看：

移動優先：

現在，咱們不能再假設用戶是經過桌面設備上的Web瀏覽器找到咱們的，他們頗有多是在移動設備上與咱們發生第一次接觸的，咱們不能讓這類新用戶產 生複雜的認知負擔。舉個例子，咱們的Web端應用能夠爲用戶提供定製化的子域名 (youraccountsubdomain.freshbooks.com)，這顯然是專屬於Web端的概念，徹底不須要在移動端體現出來。

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

順暢進入任務流程

要讓新用戶在打開應用以後無需任何設置工做就能夠順暢進入任務，從而在最短的時間內發現產品價值。

爲了貫徹這些原則，咱們在初版當中容許用戶不執行任何註冊或登陸的操做就能夠馬上在主界面當中執行任務(例如前面提到的建立發票、跟蹤時間等)，只有在功能須要的時候纔會引導他們進行賬戶方面的操做，例如在保存發票或收支記錄時會要求用戶建立賬戶或登陸。

另外在用戶選擇經過SnailMail發送發票的時候也會如此。

爲何會出問題

咱們的用心是好的，可是在可用性測試中，咱們發現被測者們更指望在應用加載以後首先進行註冊或登陸；直接讓他們進行操做反而會引起他們的疑慮，例如數據怎樣保存？

這種先操做後註冊/登陸的方式也許相對有新意一些，並且會適合於某些類型的應用，但對於咱們的產品來說仍是過於激進了。

解決方案

最後咱們採用了一種相對傳統但更加符合用戶預期、能夠給他們帶來安全溫馨感受的方案，也就是一開始就向他們提供三個明確的選項：

建立新賬戶

登陸已有賬戶

直接試用

若是用戶以爲本身已經準備好了，那麼能夠進行註冊和登陸操做；他們還能夠在不登陸的狀況下先試用，以便對產品進行更全面的瞭解。

移動版與Web版的功能差異

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

在功能範圍上未經詳細定義的移動版產品(特別是初版)具備很大的風險，在設計開發流程中將產生極大的不肯定性。

在初期對產品功能範圍進行合理的界定，將有助於那些基於市場及用戶研究所得出的核心需求被更加準確的落實到最終產品當中。

早已投放市場並通過驗證的Web端產品功能沒法表明移動版的需求。移動應用有其特定的使用環境和場景。

移動版本中的某些功能會依賴於Web端。提早作好規劃工做，將有助於開發工做的順利進行。例如，移動版特有的爲收據拍照的功能要求Web端必須具備相應的功能支持，包括查看收據照片等等。

不過，正像在前文中提到的，咱們曾經假設用戶最想要的是快速建立內容。所以，在界定功能的時候，咱們基於這個錯誤的假設將核心功能限制在了這個範圍當中。

報表

以財務報表爲例，這是FreshBooks的Web版本當中的一個核心功能，但因爲其規範化的格式難以適應移動設備的界面規格，加之咱們初期一直將重心放在「創造內容」上，因此咱們決定在移動版當中捨棄掉這個功能。

爲何會出問題

財務報表實際上是財務軟件當中很是重要的一部分。咱們在界定功能範圍的時候將這部分功能從移動版當中移除，結果在可用性測試中發現這徹底不符合被測者們對於一個功能完整的財務軟件的認知與指望。

另外咱們也意識到，在現實中，若是移動版的產品當中不包含這項功能，那麼新用戶頗有可能根本沒法瞭解到其實咱們的Web版應用是提供了這個功能的，他們爲此而放棄該產品的概率會變的很大。

解決方案

咱們顯然不是無緣無故將報表功能從移動版本當中移除的，它在呈現方式上確實存在着難以解決的問題，但實際上這個問題並不是必定要被解決——經過進一步 思考，咱們認爲用戶的真正目標並非必定要在移動設備上看到報表，對他們來講最重要的是瞭解到有這樣一個功能存在，以及能夠怎樣去查看這些內容。

最終，咱們決定在移動端增長報表的入口，用戶點擊後會被引導進行註冊或登陸。已經處於登陸狀態的用戶能夠選擇「將報表發到個人郵箱」或「在iPhone的Safari瀏覽器中直接查看」，同時界面還會提示用戶，瀏覽報表的最佳方式是使用臺式設備。

總結

敢於挖掘並面對設計當中的錯誤與問題，並思考相應的解決方案，這是不斷提高產品價值及用戶體驗的關鍵要素。提出假設、與真實的用戶進行溝通、驗證假設並發現問題、思考解決方案、迭代——是咱們在設計工做當中應該保持的良好節奏。