就像每款游戏的核心是一组规则一样，每个微交互的核心同样是一组规则。游戏规则决定了游戏该怎么玩，微交互规则决定了微交互能怎么用。而创建规则的核心，就是创建一个围绕微交互如何运作的简单的非技术性心智模型。
设计规则时最重要的是确定目标。设计规则前，确定微交互到底是什么。最好的目标应该是容易理解，而且能够完成的，不要把目标确定为整个交互过程中的某一个步骤，目标是最终状态。比如说，登录微交互的目标不是让用户输入密码，而是让她们完成登陆并进入应用程序。微交互越接近目标，成功的概率就越高。
目标是规则的引擎，一切围绕着它展开。
如果你自己都不能轻易写出或画出一个微交互的规则，用户就更难简历它的思维模型了，除非你能够给出反馈，营造一些“虚拟”的模型，让用户知道都发生了什么。其次，除非你的规则确确实实很新颖，否则用户总会带着某种预期去使用它。
苹果其实经常能带给人们惊喜，举个小例子：填写电子邮件地址时，ios设备的键盘上就会出现“@”符号。
规则应该潜移默化地引导用户完成微交互的“交互”过程
规则决定了以下事项：
a.微交互如何响应被激活的触发器。用户单击图标时会发生什么？
b.交互期间用户可以进行什么操作。用户可以取消下载、调节音量，或者手动触发的操作（比如检查新邮件）吗？
c.动作发生的顺序及时间。比如，在“搜索”按钮变成活动状态前，用户必须在搜索框中输入文本。
d.使用什么数据以及数据的来源。微交互是否依赖地图定位、天气状态、当前时间、股票价格？如果是，这些数据从哪里得来？
e.简洁的相关配置及参数。规则从整体上来看是可以用算数表达的，而微交互的某部分又是由算数驱动的。
f.什么时候提供什么反馈。规则可以表达哪个“步骤”应该有反馈，以及后台都在进行什么操作。
h.微交互处于什么模式。这里所谓的“模式”是指规则中应该尽可能避免的“分叉”。但有时候这种“分叉”又是必要的。比如在很多天气应用中，输入城市就是一个输入模式，他独立于默认的查看天气模式。
J.微交互是否重复以及多次重复一次，微交互是一次性的活动，还是个循环往复的过程？
K.微交互结束时会发生什么。微交互结束时是切换到另一个微交互，还是自动消失？亦或永远不会结束？
用户可能知道也可能不知道规则的存在，而规则让自己可见的方式有两种：允许做什么和不允许做什么。这两种方式都反馈的时机。当然，有时候用户的心智模型与规则生成的概念模型不一定匹配。
一.生成规则
设计规则最简单的方式，就是一开始先把你能想到的规则大体上记录下来。能够记录下来的都是微交互期间的主要动作，只要把它们一步一步地按照顺序记录下来即可。比如把一件商品放在购物车里，一开始规则可能如下所示：
1.在商品页面上，用户单击“添加到购物车”按钮
2.商品被添加到“购物车”中
上述规则很简单。但随着设计的细化，以上规则会变得复杂起来。
1.在商品页面上，检查用户以前是否购买过这个商品。如果购买过，把按钮的标签由“添加到购物车”改为“再次添加到购物车”。
2.检查用户的购物车中是否已经有了这个商品。如果有了，把“添加到购物车“改为”再添加一个到购物车”
3.用户单击按钮。
4.把商品添加到购物车。
进行真正设计时，规则可能还会更多。
简单的按钮的规则，如果有人在站酷上已经关注了你，“关注”按钮会变成“互相关注”
可视化地呈现规则， 逻辑关系图非常有用：
规则关系图能够让人对规则之间的逻辑关系一目了然，知道哪些动作变的（过度）复杂了。另外，关系图也能帮人发现一些在纯文本形式下发现不了的错误。
二.动词与名词
可以把微交互想象成一句话。这句话的动词代表用户要采取的动作，名词代表辅助实现该动作的对象。比如通过滑动条可以调节音量大小。
微交互中的每个名词都应该独一无二。如果有两个相同的名次，要想办法把它们合二为一。两个（或多个）看起来相同的名词，他们的行为也应该相同。两个看起来类似的按钮，它们的行为不能差的太远。相同的名词在不同的地方也不能行为迥异。如：Android系统中的“后退”按钮就是一个著名的例子，它能把用户带到什么地方？在不同的应用中答案也不同：有时候是前一个面板，有时候则是完全不同的应用。
微交互的最高境界通常都是给用户提供多种多样的动词，但只提供最少名词。
三.屏幕与状态
实现规则时很有诱惑力的一种做法，就是为规则中的每一步都设计出一个屏幕：换句话说，就是为了整个微交互设计一连串安装向导式的UI。
事实上，采用独立屏幕往往不如利用状态变化。因为状态变化可以在不加载新屏幕的情况下，渐进的揭示每时每刻必须做出的决定或操作的控件。
用户可以与之交互的任何对象都（至少）有三种状态：
1.邀请／默认状态
第一次乘现在用户眼前的状态。这个状态也适合呈现一些预先加载的数据
2.活动状态
用户与之交互时，对象有什么反应？
3.更新后的状态
用户停止与之交互后，对象有什么变化？
微交互设计师应该关注每一个状态，因为每一个状态都需要向用户传达信息，告送用户当时发生了什么，即使什么也没发生。
四.约束条件
小米运动不允许填写将来的日期，因此只提供下拉列表让用户从中选择，从而完全避免错误。
1.可用的输入和输出方法
2.输入内容的类型和范围。密码框允许输入几个字符，或者用户可以把音量调到多大
3.要付出哪些代价。不仅从金钱角度，例如：每10秒向服务器发送一次请求可能会给服务器带来极大负担，同时也会导致设备电池消耗过快。
4.可用的数据有哪些，可以通过传感器收集到哪些数据？有哪些服务或API可以用来取得位置、新闻、天气、时间等新消息？
5.可以收集哪些数据。可以收集和使用用户个人的哪些（行为）数据？
最后两个约束条件可以让你不必从零开始
五.不要从零开始
对于微交互啊而言，触发器被启动后的第一个问题都是：我对用户以及用户所处的情境了解多少？你肯定了解一些情况，而有些情况可以用于改进微交互。
以下是一些常见的例子
1.用户使用的平台／设备
2.当天的时间
3.房间的噪音
4.微交互的持续使用时间
5.用户是不是在开会
6.用户是不是一个人
7.电池还剩多少电量
8.设备的位置和方向
9.用户刚才做过什么
有些并非直接来源于用户的数据可能会更有用。Google+会根据你朋友的职业来猜测你在哪里上班。
最后一项、可能也是最重要的一方面数据有赖于收集用户的行为信息。当然设计师应该明白：必须尊重隐私。用户宁要没有个性的体验，也不想暴露隐私。
通过收集用户行为数据，你会发现应该让高级用户利用不可见的触发器跳过规则的某些步骤。导航应用Waze让高级用户滑动（而不是按下）按钮就可以直接打开导航，省了两次点击操作。
六.理解复杂性
如何对待复杂性。要么让系统来处理，不让用户介入；要么让用户来处理，把更多的决定权（包括控制权）交给用户。
首先，要找出最核心的复杂性在什么地方，确定用户掌握着哪一部分以及何时需要介入。如果用户介入绝对必要，则适时将控制权交给用户。
从处理复杂性的角度来说，计算机肯定要比人更能胜任。如果你的微交互中涉及下列复杂性，那就让系统处理：
1.快速计算
2.同时执行多个任务
3.记忆很多东西
4.检测复杂模式
5.从大数据集中搜索特定的物品
除了让系统处理复杂的任务外，你还必须足够聪明，知道给用户提供哪些选择以及它们的默认值。
提供给用户的选项越多，微交互的规则也就越多。一般来说，规则越少则微交互就越容易理解。因此，要尽量少给用户选择，同时提供聪明的默认项。
这正是谷歌的搜索框成为21世纪早期最有效率（至少在互联网被使用最多）的微交互原因。每个人都遵守相同的规则：
输入文本按下（大大的）搜索按钮
看到搜索结果
提示的方式可以是去掉其他所有选项，或者视觉上给出变化。正如游戏设计师JesseSchell在他的书The Art of Game Design中所说的：“控制了用户的眼睛，就控制了用户的脚步。”
最明显的是默认项应该是大多数人情况下会用到的。即使你觉得这个选项不应该替用户选择，也应该让它看起来非常明显。最常见的例子就是“确定／取消”按钮。“取消”被按下的机会一般比“确定”少得多，因此“确定”应该更容易看到（要么大一些，要么颜色上加以区分）
这里是在京东付款页面，点击后退按钮弹出的提示框，去意已决（确定）比我在想想（取消）做的明显些
选项是否有意义，有什么判断标准吗？只要问一个问题：提供这个选项能让用户感觉有意义、有价值，或者心情舒畅吗？如果答案不能，那就算了。
去掉选项有一个好处，即避免很多极端情况出现。极端情况指的是那些非常难解决的问题，而且只是偶尔才能碰上，只适合小众（高端）用户。极端情况可能会导致微交互跑偏，让你的设计偏向不常见的场景。
一.控件和用户输入
以调节音量这个最简单的微交互为例，音量调节可以分为三个状态：调大，调小，静音。
控件的选择需要权衡易操作和易辨识这两个方面。易操作意味着每个指令对应一个控件。对音量调节来说，就是有三个按钮：一个用于调大音量，一个用于调小音量，还有一个用于关闭音量。易辨识意味着让一个控件承担多个操作。对音量调节来说，就是要选择滑动条或滚轮。
对于需要不断重复的微交互，一般应该让它易辨识，除非是那种可以迅速完成且不可能出错的动作（不如按下电话上的静音按钮马上可以静音，而如果给按钮加入调小音量功能，那后果恐怕是灾难性的）对于只要做一次或者偶尔才需要做的微交互，应该让他易操作，把所有选项都显示出来，让人一目了然，不要求用户有什么先行的经验。
文本字段应该接受填入其中的任何内容，并假设这些内容可能来自任何地方，特别是用户内存中的剪贴板。文本字段特别需要系统设计师所说的“必要的多样性”，即适用各种条件的能力。这意味着通常要通过代码“修正”输入，使其达到代码或数据库的要求。
Adobe Photoshop的拾色器微交互提供了一个输入十六进制颜色值的文本框。不过，这个文本框不够聪明，不会去掉用户黏贴到里面的#符号
二.预防错误
设计规则时的一个任务就是预防错误。微交互应该遵循20世纪60年代丰田汽车传奇工程师新乡重夫发明的防呆原理。防呆原理是说，在设计产品和流程时，就要考虑根本不让用户出错。不如苹果的Lighening插头，正反都可以插入iphone。
Gmail在你发送邮件之前会提示你是否忘记添加附件，而我们的办公邮件却没有提示，几次我都发出没附件的邮件。
再例如：ios版本更新必须又50%的电量才让更新版本。
这个原理也可以防止用户以不适当的方式使用微交互，比如：你可以禁止在评论中发表污言秽语。
弹出错误警告是懒人的做法。如果确实发生了错误，那微交互应该首先想办法确定怎样解决问题。
微文案，即标签、说明及其他文本片段，一个微文案本身就可能是一个完整的微交互，比如Facebook的“Like”按钮，就完全构建于蓝色的Like文本之上。
传统的做法是把标签放在图标下面。
把标签放到文本字段内部时要多加小心。因为一旦消失（必须的，因为用户的输入内容），用户有可能就会忘记这个字段时干什么用的，而且除了单击文本字段外部，没有别的办法再看到标签内容。更好的做法是把标签放在字段上方（玩具搜索）或放在按钮上（搜索玩具）同时再在字段中放一个示例文本（如”棋类游戏、乐高游戏或玩具娃娃）
确保每个说明性文案与控件严格匹配。比如，不要文案中说“把商品添加到购物车”，而按钮上写的却是“购买而不添加商品”。
不要使用双重（或多重）否定！这样的话让人摸不到头脑："如果你不想退订我们的邮件简报，就不要取消选中这个框。"
布尔发明了逻辑代数，他包括三个基本的逻辑运算：与、或、非。这几个运算构成了生成算法的基础。而算法，用Christopher Steiner在他的《自动化：算法如何统治我们的世界》中的话说，就是：大型决策树由一个接一个的二元决策构成。开车、买卖股票、找对象，以及我们所做的一切，几乎都可以分解成一连串的基于二元输入的二元决策。。。。。。本质上，算法就是表面上能够执行并得到理想结果的一组指令。算法的一端是输入，一端是输出。
从根本上来说，规则其实就是算法。而有些微交互确实依赖算法运行，例如：搜索。搜索框自动填入内容就是算法生成的，更不用说搜索结果的排序了。商品推荐、驾车路线、依旧大多数邮件和读物都是通过算法生成的。某些品牌的元素，比如耐克FuelBand的NikeFuel点，也是基于算数的，就像FiftyThree著名的ipad应用Paper中的定义颜色一样。
任何算法都由以下四部分构成：
1.顺序
耐克FuelBand这样的设备，顺序的体现大概是：每两步（根据硬件加速计的计量结果）就加个1个NikeFuel。
2.决定
通常都是“如果。。。就。。。”形式的句子。比如，如果时间是00:00，就重置。
3.重复
算法怎么循环？例如，当用户在搜索字段输入时，每输入一个新字符就更新一次搜索结果。
4.变量
变量是数据的容器，是算法巨大威力的来源。有了变量，就可以不用重写算法而调整计算过程。搜索结果数可以是变量，经过的步骤数也可以是变量。变量可以数值、字符或逻辑值（真／假）
让用户知道算法的操作的是什么数据或变量有时候也很有用，这样他们就可以在可能的情况下手动调整这些数据或变量。比如，知道了耐克FuelBand的加分规则，用户就可以适当增加活动量。但现在呢，这个加分方法还是显得有点神秘。
从设计微交互的角度来说，最重要的一点在于知道用户想干什么，哪些数据或内容会最有用，然后把这些对人有益的价值融入到算法设计中。
最后，规则的问题还是在于它们不可见。用户要理解它们只能等到出现某种恶劣状况时，比如苹果修改“另存为”，或看到了系统的出错反馈。而反馈正是第4章将要介绍的主题。
