如果你是一位经验丰富的设计师，你应该会同意这个观点：从他人的作品中获取到灵感并不算偷窃他人的作品。这是属于在对设计进行深入研究呀，这也属于一种设计模式呀，而且还遵守设计规范呢。所以，当然要以用户们所熟悉的那些模式来创造出可用性界面。

不过，有的设计师则会认为，过于遵守设计规范，而且，经常性的从他人的作品中获取灵感的话，自己本身的创造能力就会下降，这就导致了这样一个结果——一天下来，你的所有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会以某种方式来设计。

自己要多想想，多设计，多研究。

衡量，测试，验证——如果能够做得更好，就不要害怕打破设计规范。