上篇文章我们介绍了《漫谈“微交互”（一）： 关于微交互》，接下里几篇文章我们将从以下几部分来谈微交互。
主要分为五大模块三篇章，第一篇先让我们聊聊微交互的来源，第二篇我们将会了解触发器和规则，最后一篇我们将聊关于反馈、循环与模式。
2.触发器
触发器类别分为两种：手动触发器、系统触发器，触发器就是任何能够启动微交互的东西；手动触发器是由用户发起的，系统触发器是由系统收到数据等，会在某个或某些条件具备时触发。
手动触发器
微交互从哪里开始呢？通常都是从用户打开设备或启动应用时最先碰到的东西开始。最早的触发器是有开和关两个状态的开关（以及功能等价的数字化界面控件）。
虽然有一部分手机已经使用人脸进行屏幕解锁，但大部分手机屏幕解锁还需要使用手动。
触发器的第一条规则：触发器必须让用户在使用情境下认出来其是触发器。 触发器可以是物理的控件，或者是任务栏、菜单栏中的一个图标。要把它设计得让人一看就知道 能通过它做什么，而且要吸引人，同时使用越频繁的触发器越需要突出，比如iPhone专门在手机左边上加上静音开关，因为我们随时都会使用上该开关，在开会的时候、上班的时候、上课的等时候随时需要开静音。
从总体来看，理解用户想要（ 或 需要）做什么、什么时候想做，以及在什么情境下想做是非常重要的。这些问题决定了手动触发器在什么时候、什么地方出现。或许任何情况下都必须可用，比如开关按钮；或许跟使用情境紧密相关，只有各种条件具备的时候，比如进入特定的模式 或者进入应用的特殊功能区域时才出现。
比如上图的QQ，左图：当我们选中文字时长按的时候则会弹出一个小工具栏，右图：当点击空白处时，则会弹出切换好友聊天列表的操作。
理解用户需求的方式有很多，借助设计研究（观察、访问演习）或凭借对相关领域的直觉和理解去体察是常见的方式，而等到产品测试、产品发布 或上市时再认识到用户需求就为时已晚。所以，让触发器的位置跟用户需求（何时、 何地）相吻合是非常关键的。
触发器的第二条规则：保证触发器每次都触发相同的动作。这还用得着说吗？有些设计师可能会感到不可思议。事实上，唯有如此才能保证用户对微交互形成准确的心智模型。而且，现实当中违反这一条的现象不胜枚举….
手动触发器的第三个规则是：提前展示数据。触发器本身可以反映微交互中包含的数据。问问自己，在微交互开始之前或者启动过程中，有什么内部状态可以展示？什么 信息最有价值，可以在这时候展示出来？
要回答这个问题，必须知道大多数用户使用微交互干什么，而且必须在微交互开始之前就要掌握那个关键的信息。比如股市应用，它可以通过颜色或箭头表示当前市场或股票的状态，提醒用户是否有必要启动微交互。
触发器的第四条规则就是不要破坏视觉使用情境。换句话说，如果触发器看起来像按钮，那它就应该像按钮一样能被按下去；
同时该规则也会被用在相反的效果上，比如下图弹窗，如果不想用户点击该按钮，就需要把按钮设计的不那么明显，甚至看不来不可点击的状态。
触发器的第五条规则是用得越多的触发器越要引人注目。多数人经常要用的微交互，应该最引人注目。少数人有时会用的微交互，应该容易注意到。极少数人不常用的微交互，应该通过搜索找。
最引人注目的触发器依次是：
- 移动的物体，比如脉动图标；
- 带使用情境和标签的物体，比如带标签的按钮；
- 带标签的物体，比如带标签的图标；
- 只有一个物体，比如图标；
- 只有一个标签，比如菜单项；
- 什么也没有——不可见的触发器。
系统触发器
并非所有触发器都是手动的。事实上，当前我们身边的触发器大都不是用户而是系统发起的。系统触发器无需用户介入，只要满足条件（一个或多个）就会自动触发，系统触发器何时触发，以及多长时间触发一次，都要遵循规则。
比如当我们打开刚下载一款APP时（以iOS为例），一般就会连续收到连续的弹窗提醒用户做一些列的操作，又或者我们打开一款使用过的App时就会接到令人厌恶的广告弹窗。
系统触发器启动的常见条件如下：
错误
系统出错时，经常会通过微交互来解决问题，比如询问用户想怎么办，或者只是显示一条消息说明出了什么毛病。可以看下图:
目前仍然很多产品存在一个很严重的问题，就是当程序出错的时候，没有任何的提示，也没有给用户一个下一步操作的引导，导致用户不知所措。如下图：
位置
位置可能是各种尺度：国家、城市、街道，甚至特定的房间。满足其中任何尺度的用户 都可能触发微交互,比如我们打开一款需要定位的一款APP，就会自动定位我们的地理位置，前提是我们在第一次打开App时授权自动定位了。
收到数据
电子邮件、状态消息、软件更新、天气预报、亮度变化等进入联网设备和应用的数据，都可能触发微交互。内部数据时间或系统资源等。如下图的消息推送：
内部数据
也可能是触发器启动的条件。比如，过一定时间屏幕自动降低亮度。
其他
在诸多社交关系中，其他人的行为（例如，回应聊天、发表照片或消息、申请成为朋友等等就不再多的列举了），也可以成为触发器。
3.规则
就像每款游戏的核心是一组规则一样，每个微交互的核心同样是一组规则。游戏规则 决定了游戏该怎么玩，微交互规则决定了微交互能怎么用。而创建规则的核心，就是创建一个围绕微交互如何运作的简单的非技术性心智模型。
设计规则前，需要确定一个最简单、最明确的说法，即微交互到底是什么。最好的目标 应该是容易理解（我知道为什么要做这件事），而且能够完成的（我知道我可以做到这件事）。
注意，不要把目标确定为整个交互过程中的某一个步骤，目标是最终状态。比如说，登录微交互的目标不是让用户输入密码，而是让他们完成登录并进入应用程序，如果要可视化呈现规则，那流程图很有用，如下图：
规则必须反映约束
输入内容的类型和范围：比如，手机号码输入11才可以进行下一步的操作，如输入的是超过11位，或者不够11位，获取验证码按钮则显示不可点击状态，同时显示格式不正确，如下图：
要付出哪些代价：不仅仅从金钱角度，还要从资源消耗或占用角度考虑要付出什么代价。每10秒向服务器发送一次请求可能会给服务器带来极大负担，同时也会导致设备电池消耗过快。
可用的数据有哪些：可以通过传感器收集到哪些数据？有哪些服务或API可以用来取得 位置、新闻、天气、时间等信息？
可以收集哪些数据：可以收集和使用用户个人的哪些（ 行为）数据？这些需要我们在设计产品初期的时候做相关的数据埋点。
选项越多，规则越多
减少选项并给出聪明的默认项，别让用户做太多选择，如这些选项每个都需要放上去，就需要把不常用的设计的不那么显眼，甚至隐藏到下拉框等，比如我们产品有很多分类的时候，我们就不得不从大到细给他们进行层级分类，如下图：
预防错误
设计规则时的一个任务就是预防错误,设计微交互时也应该不允许用户犯错,或许这意味着减少用户的控制和输入，但减少微交互中用户的选择通常都是正确的。比如你发twitter的时候，twitter不会允许你发一摸一样的推文，除非稍微做修改，比如我在后后面加上文字“啊”，它才允许我发出去，如下图：
让文案尽量简短
标签够用时，不要使用说明性文本,比如“加入购物车”就可以了，而不要怕用户不懂而写成“把商品添加至购物车”，又或者“登录”就可以了，而不要写成“请登录”；、可能的情况下，要给出说明关系的文本，而不要只给出日期和时间。比如“8个小时以前” 比单纯一个时间戳更容易理解，如下图：
当然有时候用具体日期也很贴切，比如超过24小时后就需要以具体日期来展示，如下图：
看完有没有觉得对微交互有进一步的了解呢？
不要走开，下篇文章我们讲讲“反馈、循环与模式”！！
