是什么讓我們第一時間安裝 App？為了使生活便捷。當一個 App 無法滿足這一要求，距離被拋棄也就不遠了。一款 App 的成功有來自多方面的因素，但總體來看用戶體驗是最重要的。優秀的用戶體驗設計是讓 App脫穎而出的關鍵所在。
移動用戶體驗設計，依然必須遵循這一原則。本文力圖解決的重點是，如何避免用戶在應用中被打斷或強制引導。
多平臺上的用戶界面設計
移動用戶體驗設計中一個重要因素便是 UI（用戶界面）。大多數開發者希望在多個平臺上發布自己的 App，但需要注意的是，不同平臺有各自不同的體系和特性。一種設計策略在某個平臺上帶來完美體驗的同時，在另一個平臺上的效果往往完全不同。
不同平臺間，不要照搬 UI 元素或字體
當你在 Android / iOS平臺上開發 App 時，不要照搬對面的 UI 元素，也不要直接模仿對面的特有動效。在不同平臺間復制元素會對用戶體驗構成風險。
輸入框，復選框，開關以及其他功能性的控件需要帶有原生感。這時候應當盡可能多地使用原生控件，以使用戶在操作時能更熟悉，并有助于在用戶的敏感數據與 App 間建立信任。下面就是一個例子：
相較于質感化的設計，iOS 應用通常在外觀上更加平面化，不使用深度和陰影。iOS 中也有純文本樣式的按鈕，但并不使用 Android 風格的大寫字母造型，且在字體上更加輕盈。
字體也需要遵守各個平臺的標準：Android 的字體是?Roboto?, 而 iOS 使用?San Francisco?系列。
如果你想在自己的 App 中使用自定義 UI 元素，請把靈感來源定位在你的品牌風格，而非另外的平臺。
不同平臺間，不要搬運特有圖標
每個平臺通常會提供一系列常用功能的圖標，諸如分享，創建和刪除等。當你把 App 遷移到另一個平臺時，應該將圖標轉換為目標平臺特有的對應樣式。
各個平臺間不同的原生風格也需要注意：Android 圖標線條較濃厚，而 iOS 則更加纖薄。下面是幾個簡單圖標的比較：
不要將網站體驗照搬到 App?
用戶在移動端期望體驗到特有的交互模式和界面元素。我們在網站端的設計，放到移動端則常常顯得笨拙和臃腫，并非由于這些設計本身是錯的，而是因為用戶在移動端有不同的體驗期望。舉一個例子：帶下劃線的鏈接。帶下劃線文本的鏈接在瀏覽器網頁模型中大量出現，但在移動應用的視圖模型中則應避免被使用（移動應用使用的是按鈕，而非鏈接）。
下面是來自 iOS 版 TD Bank 登陸界面的例子，顯然，這樣的效果使人感到更像一個移動端網頁，而非移動應用。最終結果是它成為了一個把網頁代碼裝備在移動端的 App：帶下劃線的鏈接，甚至還有 UI 中的版權聲明...
使用流程
不要在 App 中出現“死胡同”（dead-end）
用戶體驗設計是對流程的設計，流程大多數時候是為趨向某一目標而進行的不斷操作。在 App 中應該避免出現那種類似“死胡同”的終結界面。這種“困境終結”會造成用戶的困惑和失落，并導致某些額外和不必要的操作。有的設計中會出現一些錯誤信息和空白狀態（如黑屏）的界面，但事實上這時候卻是嘗試做其他事情的好機會。以下是 Spotify 中某個錯誤狀態的界面：
它根本沒有幫助用戶了解情形并告訴用戶“到底該做什么？”
空白狀態和錯誤狀態不應該以“困境終結”的形式出現，此時應該做的是告訴用戶需要采取的行動，使預期內容能夠正常出現，這樣 App 才能發揮功能。
不要將用戶帶進瀏覽器
永遠把用戶保留在應用內。例如你的 App 缺少相應功能和內容，可以嘗試使用應用內置瀏覽器，而不要調用手機內的瀏覽器應用，這樣可能會使用戶失去與 App的連接甚至無法返回，進一步導致用戶對 App 的棄用和用戶轉化率的降低。
不要在用戶下載后過快地請求評價
沒有人愿意被打斷，更不用說在進行某件重要的活動中間被毫無價值的瑣事打斷。在用戶剛剛下載完你的 App 或僅僅使用了幾次時，要避免打斷用戶并請求評價。評價請求應該出現在用戶已經表現出一定穩定性后，這時用戶更愿意主動評價 App ，提供的反饋信息也更豐富。
評價請求提出的時機，可以選擇在用戶打開應用的次數或完成某一操作的次數達到特定標準后。Dan Counsell 對請求反饋的正確時機有一些很好的見解，關于 Clear，一款待辦事項 App，他曾說：“iOS 版 Clear? 的評價請求，會在滿足幾個條件后才觸發。第一，用戶已經使用 App 達到數周。第二，評價請求會出現于用戶清理完一張待辦事項列表的剩余任務時。這是一個非常好的時機，此時的用戶因為剛剛完成了所有待辦事項而感覺良好，并很可能正準備退出應用。”
請求反饋并沒有錯，但請記住，你應當帶給用戶一番良好的體驗。
結論
如今用戶對 App 交互體驗的內容期望越來越多，要求也越來越高。你需要盡力滿足這些期望，同時使 App 保持友善，減少排斥。對用戶體驗的改善不是一次性任務，而應當持續跟進。
譯自：https://uxplanet.org/mobile-ux-design-what-not-to-do-65f65b13a0b9#.h7crjhhx8
