英文原文：Design Mistakes We Made in Our iPhone App，編譯：Beforweb
今年，我們(英文原文作者及團隊)釋出了FreshBooks的第一款iPhone應用。從前我們的產品一直是通過Web端應用的方式提供服務的。這次，我們把iPhone應用的設計開發過程看作一張空白的花布，盡力在其中實現一些新的功能概念和設計想法。在這個過程中，我們著實學到不少東西。
不要害怕犯錯
對於移動應用這樣的產品，設計過程中必然會遇到很多使用者體驗方面的問題與挑戰，尤其是對於新手來說更是如此。
無論你的線框稿在邏輯上有多縝密，UI稿在視覺上有多漂亮，當它們落實成為原型或最終產品時，總會有問題呈現出來。這並不完全是壞事；我們在設計FreshBooks的iPhone應用時甚至將犯錯這件事也納入到了流程規劃當中，這就意味著：
● 坦承沒有完美的設計，無論稿件和原型多麼優秀。
●真正的成功或失敗都是由使用者的反饋來定義的。
●對於在設計過程中看到的問題要迅速做出反應，根據從實際使用者身上得來的驗證結果進行迭代。
接下來，我將向各位描述一下我們在專案中犯過的三個錯誤，以及我們是怎樣解決這些問題的。
應用的主介面
在專案開始的時候，我們對FreshBooks的一些現有使用者進行了訪談，瞭解他們在生活和工作中是怎樣使用移動裝置的，包括他們面對的實際問題，以及他們對移動應用版本的FreshBooks的期望。
根據這些訪談，我們歸納出了一些基本的設計原則，例如下面這條：
以任務為中心的使用者體驗
移動應用版本的產品應該圍繞著一系列互不相關的帳單任務進行優化，包括時間追蹤、為收據拍照存檔、開票等等，這些是移動應用所處的使用場景當中最常見的任務。
而其他方面的複雜任務，包括批量編輯、許可權管理、定製化等，則留給傳統的Web端應用來承擔，以此來保證移動版本在功能上的簡約與集中。
基於這條原則，我們設計了應用的主介面。它由一系列最重要的任務組成，視覺上採用圖示加文字標題的形式，點選進入相應的任務流程。例如，使用者點選了其中的“建立新發票”之後會進入發票列表介面，然後建立新發票的介面會自動滑入檢視。
這種以典型任務為中心的設計思路在意圖上是好的，但接下來我們發現了一些問題。
為什麼會出問題
經過可用性測試，我們發現被測者普遍會在主介面中產生困惑，因為這種設計方案與他們通過使用Web端的FreshBooks所建立起的心智模型不符，而且和很多其他的iPhone應用也存在模式上的差異。
同時我們還發現，之前歸納出的一些典型任務，包括建立發票、跟蹤時間、記錄開支等，對於使用者來說，本質上都屬於一種“創造”行為。從這個角度看，其實我們忽略了這個緯度上的其他一些重要任務型別，包括：
● 檢視：例如檢視發票狀態、檢視歷史記錄等。
●更新：例如更改發票狀態等。
這類任務需求其實比“創造”更加普遍，尤其是在移動裝置上，使用者更加傾向於在短時間內以最簡單高效的方式檢視和更新內容，而不是創造內容。我們之前所聚焦的重點則恰恰相反。
解決方案
很簡單，我們改變了之前方案當中的資訊結構，使內容和功能的組織結構更加符合使用者在移動應用上下文環境中的預期。在新的設計方案中，使用者點選主介面中的“發票”(之前是“建立新發票”)，進入發票列表介面進行檢視；如果他確實需要建立新發票，那麼可以點選右上角的加號按鈕。
相關閱讀：產品早期的原型設計與使用者測試
初次使用的體驗
我們特別為應用初體驗(使用者安裝應用後第一次開啟)制訂了兩條設計原則：“移動優先”與“順暢進入任務流程”。具體來看：
移動優先
如今，我們不能再假設使用者是通過桌面裝置上的Web瀏覽器找到我們的，他們很有可能是在移動裝置上與我們發生第一次接觸的，我們不能讓這類新使用者產生複雜的認知負擔。舉個例子，我們的Web端應用可以為使用者提供定製化的子域名(youraccountsubdomain.freshbooks.com)，這顯然是專屬於Web端的概念，完全不需要在移動端體現出來。
我們還可以隨著產品價值的逐漸體現而將Web端的高階功能一點點的介紹給移動端使用者。
順暢進入任務流程
要讓新使用者在開啟應用之後無需任何設定工作就可以順暢進入任務，從而在最短的時間內發現產品價值。
為了貫徹這些原則，我們在第一版當中允許使用者不執行任何註冊或登入的操作就可以立刻在主介面當中執行任務(例如前面提到的建立發票、跟蹤時間等)，只有在功能需要的時候才會引導他們進行帳戶方面的操作，例如在儲存發票或收支記錄時會要求使用者建立帳戶或登入。
另外在使用者選擇通過SnailMail傳送發票的時候也會如此。
為什麼會出問題
我們的用心是好的，但是在可用性測試中，我們發現被測者們更期望在應用載入之後首先進行註冊或登入；直接讓他們進行操作反而會引發他們的疑慮，例如資料怎樣儲存？
這種先操作後註冊/登入的方式也許相對有新意一些，而且會適合於某些型別的應用，但對於我們的產品來講還是過於激進了。
解決方案
最後我們採用了一種相對傳統但更加符合使用者預期、可以給他們帶來安全舒適感覺的方案，也就是一開始就向他們提供三個明確的選項：
● 建立新帳戶
●登入已有帳戶
●直接試用
如果使用者覺得自己已經準備好了，那麼可以進行註冊和登入操作；他們還可以在不登入的情況下先試用，以便對產品進行更全面的瞭解。
移動版與Web版的功能差別
我們在設計流程開始之前詳細規劃了移動版產品在初期的功能範圍，也就是對我們的最小化可行產品(MVP)的形態進行界定。我們相信：
● 在功能範圍上未經詳細定義的移動版產品(特別是第一版)具有很大的風險，在設計開發流程中將產生極大的不確定性。
●在初期對產品功能範圍進行合理的界定，將有助於那些基於市場及使用者研究所得出的核心需求被更加準確的落實到最終產品當中。
●早已投放市場並經過驗證的Web端產品功能無法代表移動版的需求。移動應用有其特定的使用環境和場景。
●移動版本中的某些功能會依賴於Web端。提前做好規劃工作，將有助於開發工作的順利進行。例如，移動版特有的為收據拍照的功能要求Web端必須具有相應的功能支援，包括檢視收據照片等等。
不過，正像在前文中提到的，我們曾經假設使用者最想要的是快速建立內容。因此，在界定功能的時候，我們基於這個錯誤的假設將核心功能限制在了這個範圍當中。
報表
以財務報表為例，這是FreshBooks的Web版本當中的一個核心功能，但由於其規範化的格式難以適應移動裝置的介面規格，加之我們初期一直將重心放在“創造內容”上，所以我們決定在移動版當中捨棄掉這個功能。
為什麼會出問題
財務報表其實是財務軟體當中非常重要的一部分。我們在界定功能範圍的時候將這部分功能從移動版當中移除，結果在可用性測試中發現這完全不符合被測者們對於一個功能完整的財務軟體的認知與期望。
另外我們也意識到，在現實中，如果移動版的產品當中不包含這項功能，那麼新使用者很有可能根本無法瞭解到其實我們的Web版應用是提供了這個功能的，他們為此而放棄該產品的機率會變的很大。
解決方案
我們顯然不是平白無故將報表功能從移動版本當中移除的，它在呈現方式上確實存在著難以解決的問題，但實際上這個問題並非一定要被解決——通過進一步思考，我們認為使用者的真正目標並不是一定要在移動裝置上看到報表，對他們來說最重要的是瞭解到有這樣一個功能存在，以及可以怎樣去檢視這些內容。
最終，我們決定在移動端增加報表的入口，使用者點選後會被引導進行註冊或登入。已經處於登入狀態的使用者可以選擇“將報表發到我的郵箱”或“在iPhone的Safari瀏覽器中直接檢視”，同時介面還會提示使用者，瀏覽報表的最佳方式是使用臺式裝置。
相關閱讀：優秀的使用者體驗設計師應該做好的五件事
總結
勇於挖掘並面對設計當中的錯誤與問題，並思考相應的解決方案，這是不斷提升產品價值及使用者體驗的關鍵要素。提出假設、與真實的使用者進行溝通、驗證假設並發現問題、思考解決方案、迭代——是我們在設計工作當中應該保持的良好節奏。