微交互的核心理念在于通过打造产品细节提升用户体验。
在上一章《微交互设计案例与思考(1)-为“懒”而做的设计：减少用户负担》中，介绍了为懒做设计，减少用户负担的5个案例，在本章中，我们将聚焦为等待而做的设计。
第二部分
为等待而做的设计-等待不可避免，但可以优化
研究表明，用户能够最多忍受的等待时间是6～8秒：在0.1秒内反馈用户是可以接受的；超过1秒的等待用户会注意到延迟；而超出8秒，绝大部分用户会愤然离场。
虽然交互设计并不能改变网速和设备性能，但可以通过优化等待策略，减少等待次数，设计等待效果，甚至使用虚假的反馈为用户疏导焦虑，最终获得用户的认同。
案例一：人行道红绿灯的两种显示-优化的前提是正确理解模式
细心的同学会发现，北京大街上人行道的红绿灯使用了两种显示模式。红灯采用进度条形式，而绿灯是读秒倒计时。为什么同一个红绿灯采取两种截然不同的形式呢？这里其实有巧妙的地方。
红绿灯两种显示分别处在用户的两种模式下：红灯是等待模式，而绿灯则是催促用户。红灯模式下，进度条是一个沙漏，行人是无法获得明确时间的，也就麻痹了等待焦虑，避免闯红灯的发生。在绿灯模式下，精确的时间让用户计算是否还能过得去马路，避免行动不便者滞留在道路中央发生危险。
正是设计者正确的理解了两种模式的不同，设计出优化的红绿灯，减少了行人闯红灯和道路滞留发生。
案例二：IOS的airdrop发送和接收-如非必要应尽量避免使用模态
iPhone的airdrop是一个非常方便的文件传输功能，在实际使用中，OX设备间的文件传输几乎没有其他更好的替代者。但iPhone的用户可能没有意识到，airdrop发送和接收，是两种截然不同的界面。
具体说，发送的等待界面是非模态的，用户在向外界传输数据时，可以通过返回按钮或者home键进入其他任务；而接收却是模态的等待界面，用户必须等待传输完毕（或者取消传输），此时home键是无效的。
我曾经因接收同事的会议视频，等了足足20分钟，在这期间，我惊讶于我的手机竟然什么也不能做。难道是因为设备读写的限制不同？可我们平时在appstore上下载几百兆的应用，手机也不是这样啊。不管怎么说，如非必需，等待的模态界面是应该尽量避免的，它让等待者不知所措，不管它是不是高大上的苹果公司。
案例三：DOTA2的匹配等待-等待的时候其实可以找点事做
生活中我们会发现，人们在等待的时候，并不喜欢完全闲着。比如超市收银台前的长队，等待的人们很多在玩手机刷微信。我们应当避免让用户干等着，应尝试为他们找点喜欢的事做，现实中确实有一些这样的软件设计：
前边提到，由于DOTA2线上玩家很少，匹配一局的等待时间很长（一般要3分钟上下）。DOTA2没有使用模态等待界面，而在右下角非模态显示，玩家这时可以看英雄技能、看攻略、或者逛商店。
不止于此，在自选英雄的1分钟内，如果玩家提前选好，剩下的时间可以屏幕右边的在沙盘上放置自己走哪一路，还可以购买出门装。
在等待这件事上，暴雪确实想了很多办法，在不可避免的等待中让用户做有意义的事。
案例四：闲鱼和饿了么的加载-使用动画消除用户的焦虑
多图列表刷新或者订单生成等待通常是一个大于1秒小于8秒的时间，它让用户能明显感受延迟和不稳定感。优秀的移动产品会专门为这个等待设计加载动画，比如闲鱼和饿了么，使用接近物理运动的可爱弹动动画，提供反馈，麻痹和消除用户的等待焦虑，理解系统正在运转，内容或订单马上就好。
这样的例子在产品中非常多，也是微交互设计的热门应用之一，在此不再展开。
案例五：微信浏览器的加载进度条-提供反馈，即便是虚假的
当我们在桌面传输下载过程中经常发现，虽然网速会有波动，但数据的变化范围并不大。然而在移动端的微信浏览器里，当我们打开一篇公众号文章，经常会发现进度条的起始速率和结束部分差别非常大。
出于好奇我做了个实验：将家里的网络关闭，但WI-FI打开，此时手机连着WI-FI，所以并不能判断是否有网络，我打开了公众号的一篇文章，结果出乎我的意料，浏览器的绿色进度条快速的走到了一半，然后在后半段缓慢前进，最终显示无法打开，请求刷新页面。
可是因为断网并没有数据传输啊，微信提供的是虚假的进度条。可是再想一想，正是微信虚假的反馈，让我在白屏中等待了很长时间，还误以为网速很快。
这是微信的策略，目的是消除用户等待焦虑。
好吧，为等待做设计，五个优化等待的案例，今天先写到这里。
