引导应该这样做，UI设计师的设计才会得到认可

我们今天所熟知的手势交互，包括点击、滑动、缩放都是iPhone 诞生之后，经由不同设计团队、在不同公司的不同产品之下催生成熟的一套交互模式。对于新一代的数码设备用户而言，触摸和手势交互，就是属于他们的鼠标。手势，就是新一代的“点击”交互。

今天，我们来聊一聊移动端UI设计中，如何借助手势交互提升易用性和有效性。
选择对的手势

当你想在你的UI中引入手势交互的时候，应该先了解一下你的目标受众可能会用的APP中所用的手势，以及你的目标市场。在你的APP 中引入类似的手势交互，能够至少降低用户转移APP的时候的学习成本，这样针对目标市场的手势设计，让用户一开始就能以一种舒适的方式开始使用。

手势学习

虽然手势几乎无处不在了，但是面对新的APP的时候，用户还是不清楚哪些手势可用，学习新APP的手势交互几乎是绕不过去的问题。绝大多数的界面交互沿用了最常用的点按、滑动和捏合手势，通过这些手势可以执行绝大多数的操作，其中点按是无疑是最常用也是最直觉的。但是，与显性的图形化的界面不同，手势交互本身是隐形的，除非用户实现知道某个界面某个位置可以用手势交互，否则，用户需要通过自行摸索和尝试来发掘。

所以，从这个角度而言，只有设计师在界面中提供正确的视觉指引，用户才会“正确地发现”手势交互的存在。
避免在新用户引导的时候加入手势教程

许多手势交互驱动的APP当中，设计师都习惯于将手势交互的教程放在首次打开APP的时候。这样带有新用户引导教程的APP非常之多，用户需要在刚刚进入的时候，了解APP的功能、特点，学习操作等等等等。但是，这样的教程展现方式本身并不够优雅，也不够有效。这种新用户引导阶段的前期教程所存在的主要问题，是用户必须在一打开应用的时候，就记住一大堆的信息。如果信息和教程不多还好，稍多一些，用户会很快陷入混乱。举个例子，著名的效率应用 Clear，新用户引导教程长达7页，用户需要非常耐心地看完它们才知道如何正确有效的使用这款应用。这样的设计无疑是糟糕的。

在使用过程中提供教程

在用户使用APP的过程中，结合用户所处的界面、执行的操作、正在完成的任务和上下文信息来提供相应的手势交互的教程。如果想要交给用户一个新的手势，那么你必须慢慢开始，不要指望一次搞定，不要急于求成。

所以，你需要给用户的是一个迭代式的渐进的指引教程，恰到好处的提醒，并且你的引导应该是专注于单个交互的，而非一次给用户灌输尽可能多的信息。结合语境来提供教程和指引，才是最有效的。

下图是 Android 版的Youtube 的APP中的手势交互的引导界面，这款源自谷歌官方的应用采用的是标准的Material Design的手势交互方式，用户会在初次进入应用之后，适时地提供相应的手势交互引导，一次一项，不会进行填鸭式的信息灌输。简练的文本引导，让用户能够快速明白交互方式和结果。

使用动效来呈现手势

手势本身是动态的，它和动效本身有着高度的相似性。作为设计师，使用动效来呈现手势的交互和效果是非常自然的逻辑。为了让用户能够更为清晰的明白手势的正确用法，你可以在相应的元素上加上文本说明，并且搭配相应的交互动效，展示操作方式和执行结果。就像下面的案例所示：

使用动效进行手势交互引导的时候，有三种比较流行的方式。

第一种是提示动效。提示动效主要以预览的形式展现了如何运用手势来与特定的元素进行交互。它是作为手势和触发交互之间的桥梁而存在的。比如下面这个布丁怪物的游戏就是以手势操作为主的，动效结合游戏场景，呈现给用户交互的基本方式。

第二种方式也很有效，内容展示。相比于第一种方式，内容展示更加微妙，它向用户呈现了交互所能呈现出来的内容和结果。就像下面这个案例，它简单的展示了卡片之后还隐藏着其他的卡片，隐晦而微妙地暗示用户，使用滑动手势就能看到后面的卡片了。

第三种方式是着重推荐的，也是我认为最有效的一种，借助可供性设计的原理来呈现手势交互。为了呈现手势交互的可供性，设计师应该通过设计呈现出“用户能怎么操作”，iOS 的锁屏相机就是一个典型案例，当用户在锁屏状态下点击右下角的相机按钮的时候，屏幕会向上弹跳，展示它是可向上滑动打开的（这一功能的“能指”）。

结语

手势交互的实用性和泛用性是有目共睹的，它依赖于界面，并且高度依赖基础的几个单指和双指手势，但是它的隐藏性使得设计师的引导显得无比重要。还好在最近几年的经验累积之下，手势交互的引导模式有了如今这套相对成熟的经验，动效、文本和提示可以有效的帮助用户，逐步学会新界面的手势交互。

1. 弹窗的定义

弹窗分为模态弹窗和非模态弹窗两种。

△ 弹窗分类

模态弹窗：很容易打断用户的操作行为，用户必须回应，否则不能进行其他操作。

非模态弹窗：不会影响用户的操作，用户可以不对其进行回应，非模态弹窗通常都有时间限制，出现一段时间后就会自动消失。

弹窗作用：非模态弹窗一般被设计成用来告诉用户信息内容，而模态弹窗除了告诉用户信息内容外还需要用户进行功能操作。
2. 弹窗的介绍

2.1 Dialog(Alerts)

△ 得到、日历

Dialog需要用户对此弹框进行操作后才能继续执行其他任务。

警告框在iOS中称之为Alerts。iOS的Alerts（警告框）主要用来传达重要信息，并且常常需要用户来进行操作。

使用Dialog的时候还是谨慎一点比较好，尽量不要给用户带来糟糕的体验感。

2.2 Popover

△ 朝夕日历、微信、微博

浮出层（Popover）：是当用户轻点某个控件或页面中的某一区域时浮出的，半透明的临时视图。

常用Popover的形式来呈现页面中折叠的一些额外信息，或在首页位置呈现一些常用操作的快速入口。

2.3 Actionbar（Action Sheets、Acitivity Views）

△ 相册、陌陌、知乎、微信

如果选择按钮太多，可以参考微信弹窗的形式组织按钮和滚动显示，但要留有足够的视觉线索。

△ 饿了么、知乎、iOS

Actoinbar一般都会提供给用户更多的功能选择，一般可以采用官方控件，如果有特殊功能的话可以自己设计；一般都设计有一个默认的“取消”功能按钮，点击该按钮后或者点击弹窗外的界面都可以关闭弹窗。Action Sheets（操作列表）和Acitivity Views（活动视图）是iOS上的特有的交互形式。

2.4 Toast/HUD

△ 字里行间、Enjoy、即刻、微博

△ Pocket、Walkup、iOS

Toast是安卓系统的一个控件名词，现在也应用于iOS系统中。Toast属于一种轻量级的反馈，常常以小弹框的形式出现，一般出现1到2秒会自动消失，可以出现在屏幕上中下任意位置，但同个产品会模块尽量使用同一位置，让用户产生统一认知。Toast信息给予用户及时反馈，确保用户知晓自己所处的状态，并做出相应的措施。

考虑到Toast提示框显示的时间较短（几秒种）、占用区域不大，它容易被用户忽略，所以Toast不适合承载过多的文字和重要信息。

透明指示层（HUD）：iOS平台没有Toasts这种说法，只有HUD。（iOS音量截图）

iOS中建议，设计一种引人注目但又和你的 app 的样式相协调的方式去展示信息。（微博的刷新）

Toasts和HUD不同之处：

1.Toasts一般出现在屏幕下方，HUD出现在屏幕中间。

2.Toasts一般是灰黑或黑色半透明，HUD一般是毛玻璃半透明。

3.每次产生的Toasts内容不可改变，HUD内容可以改变（比如调节音量时出现的HUD）

2.5 Snackbar

Snackbar是Android平台特有的交互形式，很多时候也会应用在iOS系统中。它也用于向用户反馈信息，但其打扰程度介于对话框和Toast之间；一般出现1到2秒会自动消失，但和toast不同的是它是可交互的，并且一定是在底部出现。

Snackbar使用场景：当你删除收集箱某件任务时，可以在屏幕底部出现Snackbar，提示“任务成功删除”，并附带撤销操作，当用户点击撤销时，任务可恢复。用户不进行操作Snackbar则消失，任务删除成功。

△ 滴答清单、Spark
Snackbar与toast的对比

1.都为小弹窗的形式，会自动消失；

2.Snackbar一般都会有操作按钮，如撤销。toast则不可交互；

3.Snackbar一般出现在底部；

4.Snackbar带有一定的交互性，用户触摸屏幕其他地方后自动消失，也可以在屏幕上滑动关闭。

5.Toast和Snackbar显示时间都可以修改（建议遵循系统）；

6.Snackbar打扰程度介于对话框和Toast之间；

7.Snackbar仅是安卓规范样式且运用还未普及，可能造成用户理解负担；
总结

Alert：当提示信息是至关重要的，并且必须要由用户做出决定才能继续的时候，请使用Alert。非用户发起的（即系统自动发起）一般都用Alert。

Action Sheet：重要程度弱于Alert时，当需要给用户更多的功能选择时使用Action Sheet。一般用户主动发起任务时用 Action Sheet。

Toast：当提示信息只是告知用户某个事情发生了，用户不需要对这个事情做出响应的时候，使用Toast。

Snackbar：以上两者之外的任何其他场景，Snackbar可能会是你最好的选择。