UX黑名單！有哪些常見的移動端UX設計誤區需要規避？

標籤：

我們手機裡面裝滿了各種各樣的APP。安裝這些應用，我們的初衷是讓我們的生活更加便捷。但是當這些應用無法滿足使用者的需求的時候，使用者自然而然會離開，並尋求更好的解決方案。一個成功的應用程式套件含有諸多元素，而其中的使用者體驗設計則起到了決定性的作用。在殘酷的競爭中，使用者體驗往往是決定成敗的核心。

面對移動端裝置，只有實踐才能夠檢驗一個應用的使用者體驗好壞。今天的文章，我們將專註於移動端使用者體驗設計中，應當規避的誤區，這些資訊並不高深，這些常見的錯誤是經過無數實踐得出的經驗

 

不要為多平台設計一套介面

一個APP能夠讓人記住，很大程度上是因為它的UI在某些方面有著突出的設計。絕大多數的開發人員希望他們的應用能夠在多個不同的平台上發布，但是不同平台有著不一樣的規範，貼合 iOS 的設計決策和方案放在Android 平台上可能導致完全不一樣的結果。

 

不要模仿其他平台的UI元素和字型

當你為 Android/iOS 平台設計應用的時候，不要沿用其他平台的主題和UI元素，更不要模仿特定平台的操作方式。許多元素在A平台適用，在B平台上則可能會毀掉整個使用者體驗。

輸入欄位、複選框、開關按鈕以及其他功能性組件尤其是如此，應當盡量貼合本平台的特徵。使用原有平台的元素可以讓使用者更清楚如何使用，並且讓使用者對於你的應用中的內容與資訊更加信任。在下面的案例中，你可以看到Android 和iOS平台中相同功能控制項的差異：

雖然同樣是扁平化的設計，但是Material Design 和iOS 的介面元素的設計有著明顯的差異，iOS中擁有純文字樣式的按鈕，字型風格有著明顯的差別，Android 平台中按鈕內容更多的使用的是大寫字母，並且Android平台中的字型相對更纖細。

字型的使用同樣要遵循兩個平台的特徵：Android 平台用的是Roboto 字型，而iOS平台目前使用的是新的 San Francisco 字型（中文字型為蘋方）。

不同的字型能讓你很快分辨出兩大平台

如果你想為你的APP定製UI元素，那麼你應當根據你的品牌仔細定製，而不是基於平台的規範來設計。

不要忘了匹配平台的表徵圖

通常特定的平台會提供成套的表徵圖，其中會包含常用的功能表徵圖，比如建立、分享、儲存和刪除等，當你的移動端應用前一到另外一個平台的時候，不要複用上一個平台的表徵圖，而應當替換為當前平台的表徵圖。

與此同時，你也應當注意不同平台標的特徵：Android 平台的表徵圖中使用的線條筆觸比較厚重，而iOS線條則更接近流行的線性表徵圖的設計，線條纖細。下面是一些表徵圖設計上的對比：

不要從APP跳轉到網頁

使用者對於移動端的APP的互動模式和介面元素是有一個基本的概念和預期的，同時他們對於網頁端的介面也是同樣熟悉的。當網頁上的瀏覽體驗出現在APP當中的時候，情況就相當尷尬了——使用者會感受到這種差異，實際的體驗和他們的預期有著明顯的區別。舉個簡單的例子，帶有底線的連結就是個典型，它明顯是“瀏覽器介面”中常見的一種元素，在APP中，通常使用的是按鈕而非文本連結。

下面的案例是來自TB Bank的iOS APP的介面，這個介面怎麼看都是一個網頁端的登入介面。實際上他們真的是將網頁端的登入介面的代碼整個嵌入到APP當中來。顯眼無比的底線文本連結也就算了，連同著作權資訊也一起複製過來了，簡直不能忍。

APP應當始終給使用者留個出口

使用者體驗設計很大程度上是與流程相關的，而流程在絕大多少情況下是幫使用者推進進度、完成目標的。所以，你應當避免讓你的流程陷入死胡同，這樣會讓使用者感到混亂和迷惑，並且產生額外的、不必要的操作。

有時候設計師會將錯誤資訊和空狀態設計成為空白，但實際上這是個很好的機會為使用者做一些更有用的事情，以Spotify 的報錯介面為例：

這無疑就是一個沒啥用處的空狀態，它並沒有告訴使用者能幹什麼，也沒有告訴使用者到底發生了什麼。

空狀態，尤其是報錯狀態，不應該是“死胡同”，作為UX設計師的你應該通過介面告知使用者他們應該採取怎樣的行動，才能讓應用按照他們的預期一樣運作。

Azendoo 就在報錯介面中告知使用者如何解決問題

不要將使用者導向瀏覽器

讓使用者一直在APP中操作吧。如果你的應用真的缺少某個特定的功能，不妨使用應用內瀏覽器來載入頁面，而非跳轉開啟瀏覽器。在絕大多數的情況下，這樣的設計會出乎使用者的意料，失去控制，甚至難以回到APP，增加了意外也減少了可控度。

不要讓使用者一下載APP就評分

當你正在使用應用的時候，整個體驗被打斷的感覺真的非常令人難受。使用者下載了應用之後，可能在一段時間之內僅僅只使用了幾次，好用不好用還沒體會出來，這個時候突然讓他給APP評分，這種被打斷的體驗可能會帶來不好的評分。相反，當使用者使用APP足夠久了之後，這些重度使用者可能會給予應用更為可靠的評分和反饋。

你可以在使用者進行了特定數量的操作，或者完成了特定的目標之後，觸發請求使用者評分的操作。對於請求使用者反饋這件事情，Dan Counsell 的看法非常值得借鑒。談及 iOS 平台的 Todo 類應用 Clear，他是這麼說的：“iOS 版 Clear 的評分介面是在使用者碰到過一系列狀況之後才會出現的。首先，使用者需要使用應用幾周時間，然後，使用者需要將待辦事項清單中的所有條目完成之後才行，這對於一個待辦事項類的應用和使用者而言，都是一個重要的時刻，使用者會因為清空列表而獲得成就感，絕大多數情況下，他們正因為完成任務而準備離開APP，這個時機非常好。”

 

向使用者申請獲得反饋和評分本身並不是一件壞事，但是請務必確保整體體驗良好。

 

UX黑名單！有哪些常見的移動端UX設計誤區需要規避？