如果你是一位經驗豐富的設計師，你應該會同意這個觀點：從他人的作品中獲取到靈感并不算偷竊他人的作品。這是屬于在對設計進行深入研究呀，這也屬于一種設計模式呀，而且還遵守設計規范呢。所以，當然要以用戶們所熟悉的那些模式來創造出可用性界面。

不過，有的設計師則會認為，過于遵守設計規范，而且，經常性的從他人的作品中獲取靈感的話，自己本身的創造能力就會下降，這就導致了這樣一個結果——一天下來，你的所有APP都長一個樣。

從交互設計的角度看，我們會發現一個問題。什么問題呢？

習慣性的去應用一些所謂的最好的設計模式，可能會讓你覺得Google，Facebook，Instagram或者說其他的一些你最喜歡的APP總是做的非常棒，你會覺得，他們的設計目標和你自己的設計目標并沒啥差別，但是，人家成功了，而你的作品卻失敗了。所以，這里推薦一些被公認為是(至少曾經被公認為)最好的設計模式，可能在你第一次看來，這些設計模式也就那樣。

1、隱藏導航

關于漢堡圖標，已經有不下于50萬的文章來爭論它了。如果你一篇都未曾讀過，試著去讀一兩篇吧。其實，簡單說來，這些文章討論的主題更主要的是這個圖標里所隱含的那些導航，而不是這個圖標自身。

上面圖片這樣的設計對于設計師來說其實是很有吸引力的，而且簡直太方便了。根本不用擔心屏幕大小的限制，只需要這樣一個圖標，然后，把所有的導航全部塞進這個可以上下滾動的東西里，然后，讓他默認隱藏。就這樣，就這么簡單。

但是，實驗證明，與完全隱藏導航相比，適當的展示出一些導航能夠更多的增加用戶的依賴度和滿意程度，甚至為你帶來更多的收入。所以說，現在的好多大公司的播放器都拋棄了以前的漢堡圖標，將最常用的一些導航一直顯示給了用戶。

如果說你的導航比較復雜，那么，請在考慮優先級的基礎上適當地隱藏導航。

2、圖標，隨處可見的圖標

由于移動端的屏幕大小限制，許多無腦的設計師為了節省空間，在任何只要能夠使用圖標替換的文本域，都使用了圖標。大家都這樣想，象形文字或者圖標占的空間又少，不需要額外的轉換，而且，人們都很熟悉這些圖標，難道不是這樣嗎？所以，每一個APP都這樣做了。

設計師們將上面的那種假設放在腦海里，于是，有的時候，他們將實用性的功能蘊含在了圖標里面，但事實上，那個圖標是難以識別的。比如，你能猜到在下圖的Instagram里的這個圖標點擊之后能夠發送什么信息嗎？

或者說，假如你從來沒用過谷歌翻譯，那么，你會期待下圖的這個圖標實現什么樣的功能呢？

你總是假設你的用戶們非常熟悉那些抽象的圖標，或者說，你總以為用戶們會花大量的時間去研究和學習你的這個圖標的含義。這是一個很普遍性的錯誤，很多設計師都會犯這個錯誤。

Bloom.fm上讓人覺得迷糊的標簽欄

如果說你曾經設計過一個需要一個彈出框來解釋從而提高可用性的圖標，那么，即使你的用戶們會不管怎么樣都能了解它，你的這個做法也是錯誤的。

當然，并不是說你在設計中就一點都不使用圖標。你的用戶們熟悉大量的圖標，這些圖標中，有很大一部分都是能夠代表普通的功能的，比如搜索，播放視頻，郵件，設置等等。(但是，用戶們可能不會很確定當他們點擊一個心形圖標的時候，會發生什么。)

一些能夠被大多數用戶所識別的圖標并且被認為是通用的

對于復雜的和抽象的圖標，在顯示的時候，應該總是在旁邊加上一個文本來進行說明。這樣，你的圖標才是真正有用的。同時，還能夠提高菜單的可發現性，也能夠為你的APP添加漂亮的觸感和個性。

Pixelmator的導航

對于基本的功能，可以使用圖標來展現；但是，對于復雜的功能，就需要使用文本來說明了。(如果你要使用圖標的話，要時常性的做可用性測試)

3、基于手勢的導航操作

當蘋果公司在2007年發布了iPhone的時候，多指觸控技術就成為了人們關注的主流技術，用戶們發現他們不僅可以在屏幕上進行點擊，還可以進行放大，縮小和左右輕掃。

手勢在設計們的圈子中流行了起來，許多的APP都圍繞著手勢操作來進行設計。

Clear里的手勢操作

就像隱藏的導航欄和使用圖標代替文本一樣，手勢看起來似乎能夠為設計師節約一些屏幕空間。("屏幕上不應該有刪除按鈕的存在，人們只需要向左或者向右輕掃就可以進行刪除了。我們會決定怎么操作的。")

關于手勢，你首先需要知道的是，手勢是不可見的。人們需要記住它們，就像漢堡菜單的例子一樣。如果你隱藏了一個選項，那么，用到那個選項的人就會越少。

另外，手勢存在著與圖標相同的問題：眾所周知的手勢有點擊，放大，上下滾動，同時，每個APP也有那些需要慢慢發現和學習的手勢。

不幸的是，觸屏界面的設計仍然是一個新的領域，在各個APP中，大多數手勢還不標準和統一。一個很簡單的手勢，比如左右輕掃，在各種各樣的郵件APP中可能都會大相徑庭。

在Apple的Mail APP中，向右輕掃，顯示出了"標記為未讀"的選項

同樣的手勢，在Mail Box中，就表示將郵件存檔

或者說，想一想，搖晃你的手機，在兩個APP中，也會有兩種不同的含義。在iOS中表示撤銷，在Google Maps中表示發送反饋信息。

永遠都要記住，手勢是隱藏的操作，人們不得不去記住它們。對于你的用戶，這需要大量的努力。如果你是一個發起人，也許你可以讓全世界的向右輕掃的含義都一樣——但是，只有當它是你APP的概念設計里必不可少的一個部分的時候。

4、新手引導

新手引導，最近很火的一個話題，適用于用戶第一次與APP打交道的時候。在很多情況下，這個簡單的方式能夠在一個透明的覆蓋層上為用戶展示一些標記來解釋界面元素。

dcovery APP里的新手引導

為什么說這是一個很爛的解決方案呢？因為許多用戶都會跳過你的介紹，他們想做的就是趕緊使用這個APP。即使他們注意到了你的這些標記，當他們把這個關掉的時候，這些所謂的教程也被他們忘得一干二凈了(尤其是當屏幕上擠滿了信息的時候)。最后說一句重要的，在你的屏幕上添加這些引導的標記，并不會提高APP的易用性，記住下面這句話：

原圖翻譯：用戶界面就和講笑話一樣，如果這個笑話還需要解釋才能明白的話，那么，這也不是一個好笑話。

對于你的用戶來說，新手引導也許可以使用其他的方式來設計的更加有用。比如Slack這個APP，使用第一屏來創建一個用戶場景。簡單的介紹一下他們自己，著重于利益而不是屏幕上的功能。

留住你的第一批用戶的一個更有效的方法就是逐步的引導。比如Duolingo，他沒有向用戶們解釋這個APP是如何工作的，而是促使人們做一個指定語言的快速測試(甚至不需要登錄)，因為用戶們可以在做測試的過程中了解到這個APP是如何使用的。同時，這也是展示這個APP的價值的一個更有影響力的方法。

記得住左右輕掃的手勢在Apple的Mail APP里和在MailBox里的不同嗎？看看他們的逐步引導是如何做的：用戶們在開始使用APP之前，必須在APP所提供的一個練習場景里嘗試使用這個APP里的每一個手勢。

在你準備在一個半透明的覆蓋層上設計你的引導標記的時候，停下來好好想想第一次使用你的APP的用戶會有寫什么樣的經歷。關注一下使用環境，通常情況下，有更好的方法來歡迎你的用戶們。

5、充滿了創造力，但是并不直觀的空白狀態

很多沒有經驗的設計師很容易忽略APP的空白狀態。但是，從一個APP的整體用戶體驗上來說，這是一個很重要的方面。

有的時候，設計師們把錯誤信息和空白狀態的界面當作一塊展示他們創造力的畫布。

第一眼看去，簡直太棒了不是嗎？一個漂亮的矢量圖加上完全符合設計規范的布局。

但是，再看一下，就會覺得有寫奇怪的東西了：

・這塊屏幕里什么收藏也沒有，但為什么這里會有一個那么顯眼的搜索按鈕呢？難道是想讓用戶在什么都沒有的界面里搜索什么？

・第二個很顯眼的元素就是這個矢量圖，很明顯不可以點擊(雖說會有很多人去嘗試點擊)。

・屏幕上的提示說，我應該找到在頂部的那個超級不起眼的" _fcksavedurl="">

第一眼看去，簡直太棒了不是嗎？一個漂亮的矢量圖加上完全符合設計規范的布局。

但是，再看一下，就會覺得有寫奇怪的東西了：

・這塊屏幕里什么收藏也沒有，但為什么這里會有一個那么顯眼的搜索按鈕呢？難道是想讓用戶在什么都沒有的界面里搜索什么？

・第二個很顯眼的元素就是這個矢量圖，很明顯不可以點擊(雖說會有很多人去嘗試點擊)。

・屏幕上的提示說，我應該找到在頂部的那個超級不起眼的"＋"標志。為什么這個提示自己不包含一個添加按鈕呢？就像是在說"點擊繼續按鈕來繼續"

總而言之，上面這個空白屏幕沒有能夠幫助用戶理解用戶所在的這個環境：

・什么是收藏？他們為什么有用呢？

・為什么我什么都沒有呢？

・我可以做些什么嗎？(我應該做什么？)

當需要創造力時，越少有時會越有用。下面這個空白狀態屏在可用性上就做的十分完美。(先讓我們忽略那個"現在就點擊下面這歌按鈕吧"的引導提示)

在Lootsy里的空白狀態屏

記住，空白狀態(類似于網頁里的404頁面)并不只是美感和品牌特色。在可用性上，他們更為重要。要讓空白狀態更為直觀。

多問多想

不要說我是錯的：設計模式和最佳的實踐仍然是你的好伙伴。但是要知道，APP和用戶是不一樣的：在一個APP里能夠適用的方案，在你自己的APP里，也許就一點不適用。這不是一個通用方案就能解決的事情。另外，你永遠不可能知道為什么一個APP會以某種方式來設計。

自己要多想想，多設計，多研究。

衡量，測試，驗證——如果能夠做得更好，就不要害怕打破設計規范。

在Lootsy里的空白狀態屏

記住，空白狀態(類似于網頁里的404頁面)并不只是美感和品牌特色。在可用性上，他們更為重要。要讓空白狀態更為直觀。

多問多想

不要說我是錯的：設計模式和最佳的實踐仍然是你的好伙伴。但是要知道，APP和用戶是不一樣的：在一個APP里能夠適用的方案，在你自己的APP里，也許就一點不適用。這不是一個通用方案就能解決的事情。另外，你永遠不可能知道為什么一個APP會以某種方式來設計。

自己要多想想，多設計，多研究。

衡量，測試，驗證——如果能夠做得更好，就不要害怕打破設計規范。