毀掉行動裝置 App設計的6個想當然

 　　過去幾年來，使用者互動進化如此迅速，設計師們都快跟不上了——導致在建立行動裝置 App時，從其他媒介(甚至陳舊的應用設計)中照搬互動設計技巧。

　　其實重要的是要記住：互動模式和設計要隨著媒介的改變而變化。

　　這種思想的第一階段，可見於滑鼠鍵盤的台式電腦過渡到觸控螢幕的過程中(Apple新推出的3D Touch就是個更加精細的例子)。從全新的互動模式，到微小的互動細節和趨勢，每種新的裝置、環境、模式和手勢，都帶來了機遇和陷阱。

　　光是瞭解它們就要費一番功夫——更別說為它們設計了——下面是一些設計行動裝置 App時應當避免的想當然。

　　1. 使用者總是需要建立帳號

　　他們不需要，許多時候他們不想、也沒有必要。

　　作為開發人員，除非將使用者固化到資料庫中，否則很容易把他們拒之門外。但從使用者的角度看，這不是光彩之舉。

　　憑什麼要先註冊，才能知道裡面有什麼?這個過程勞神費力，必須得物有所值。

　　相反，使用者資料可以離線儲存，當使用者最終決定建立帳號時轉移到賬戶中。或者，可以考慮使用“訪客”或“試用”模式，開放核心功能(比如下面的Wunderlist)，展現應用的功能，但是功能有限，或者帶有浮水印。

　　一旦證明了你的應用有價值，使用者毫無疑問會決定註冊。在那之前，就有點過分要求了。

　　2. 使用者需要一套教程，告訴他們你的應用有多棒

　　讓使用者使用，藉此展現你的應用有多棒。解釋它有多好是非常無力的。而且，使用者通常都會跳過並忘記引導頁。

　　瀏覽了所有說明的使用者，並不太理解整個引導頁設計。

　　如果你一定需要使用者使用全部注意力，一步一步瀏覽引導(有些應用確實如此)，那就要儘可能短，並且憑藉協助菜單來呈現。這就有意義多了，即使在使用者用了一段時間以後。

　　▲ Flipboard 的引導介面

　　3. 不要假設某種方式能適應所有應用

　　即使是常見的互動模式，也應該根據你應用的特定環境來評估。

　　有個常見的例子，地址輸入框裡的“省份”下拉選項。由於省份名可以寫作幾種不同形式，標準的預定義內容下拉式功能表有它的合理意義。在這案頭端或許是可接受的(儘管這尚存爭議)，但對於移動端可用性而言，下拉式功能表是最糟糕的選擇。

　　應用的互動也是強調品牌的絕好機會。如今的應用中，有些非常難忘的品牌“瞬間”，例如從啟動圖進入資訊流時的Twitter小鳥，Snapchat的個人資料圖片動畫，還有Hopper的載入圖片(詳見第5條)。

　　關鍵是我們不該迷信久經考驗的方法，那不是使我們應用出彩的唯一方式。

　　Hopper應用的載入介面。

　　4. 應用設計和響應式網頁設計是一回事

　　雖然響應式設計近似於行動裝置 App設計，但為任何裝置設計，與為獨立應用設計，有天壤之別。

　　使用者在行動裝置 App中期望特定的互動模式和介面元素。

　　例如，在iOS應用左上方通常有個“返回”按鈕，用來返回前一個介面。在網頁瀏覽器中，網站本身就不需要返回按鈕了;它通常都被省略掉，因為那和瀏覽器本身太像了。

　　雖然這是很基本且顯而易見的例子，從菜單和表單，到“彈窗”和字型大小，一切都有細微差別。我們在網頁中的設計，在行動裝置 App中往往顯得有點尷尬或粗糙——並非必定是哪裡錯了，而是它本就不同。

　　▲ TD Bank iOS應用的登入和LinkedIn iOS應用的登入

　　比較一下TD Bank iOS版和LinkedIn iOS版的登入介面。

　　在TD Bank iOS應用中，你會發現他們主要的UI元素做成了應用的樣子，左上方有返回按鈕，底部還能看到一欄菜單(與iOS的模式一致)。卻沒有像應用那樣，為登入框本身(和其他頁面內容)設計樣式。輸入框上有預設的iOS圓角和陰影，勾選框非常小，連結帶有底線，UI中甚至還帶有著作權公告。缺乏應用專屬的感覺。

　　相反，LinkedIn iOS應用感覺像是個應用，不是因為哪個特定的設計或介面元素，而是因為他們沒有把網頁打包成應用。他們為應用而設計，而非移動端網頁——我們能看出區別。

　　5. “載入小轉盤”是表達載入中和思考中的正確方式

　　預設的載入表徵圖(例如iOS的小轉盤，從中心點發散出的灰色線條)似乎有負面的暗示。

　　它們不僅出現的不是時候，也作為移動作業系統的一種功能，指示一切事物的狀態。從裝置開機，到串連wifi出現問題，或是應用載入緩慢。

　　正因如此，人們討厭看到孤零零的一個轉盤，沒有任何指示資訊或時間進度。

　　相反，應該嘗試讓載入感覺更自然——甚至將它隱藏。一種方式是通過佔位元素來暗示內容，Facebook就這樣呈現時間軸的載入狀態。你還可以利用這個機會，在載入指標和資訊上發揮創意，例如在介面上加入一些奇思妙想，或者強調品牌。

　　6. 使用者首次使用時，會盲目地允許通知

　　絕不能依賴作業系統預設的“允許通知”對話方塊。這個無腦設計會絆倒無數移動端設計師。首先，它並沒有說得足夠清楚為什麼應用需要擷取許可權，讓它能隨時隨地侵犯使用者隱私。

　　相反，應該在應用中設計一個自訂的“允許通知”介面。

　　永遠都要告訴使用者你的通知有多麼重要(儘可能給他們展樣本子)，並且向他們保證不會有不必要的垃圾資訊轟炸。

　　一旦使用者理解了應用通知的價值，謹慎提供原生的、基於系統的彈窗——他們會立刻看見，不會把事情搞得一團糟。

　　一款廣泛宣傳的新近應用Peach就做得很完美。

　　它第一個“允許通知”對話方塊看起來很像真正iOS系統對話方塊(但並不是)，他們解釋了“為什麼”需要通知，消除了疑慮。使用者點擊“允許”之後，就會看到真正的iOS系統對話方塊(相比之下，這個沒用多了)。

　　7（還有更多）

　　人們對應用介面的期望更多了，標準正在水漲船高。

　　對於基於應用的公司，不當地忽視細節會損害應用的接受度——甚至會破壞你與使用者的關係。

　　以上6個想當然還只是開始。如果想要繼續深入，要學著留心和避免日常的假定。小心不要想當然以為自己知道什麼介面最適合——始終都要努力尋找最佳方案。