当交互设计师完成一份自以为详尽的交互输出物，前端的开发结果总是不那么另人满意。交互会抱怨：为什么会做成这样呢，很多常识性的东西也会做错。显然因为领域不同，对“常识”的理解不尽相同，我们不能把希望寄托在前端工程师的可用性觉悟上。所以交互设计师必须站在对方的角度，在提交输出物前补充交互细节，以免日后不必要的迭代。
1.列表项目为空时的显示效果。比如“购物车”里没有东西时，该如何显示。否则开发会让屏幕空白。
2.当页面或应用会向后台下载数据较慢时，载入过程的提示。如果我们不说，技术不会考虑载入时的信息反馈，会让页面呈现假死的状态。
3.当按钮、图标、链接等不可用时，怎样呈现给用户（a.消失 b.disable+文案改变c.disable+tip d.非模态或嵌入式提示 e.点击后出现模态对话框）。如果我们不说，技术会采用最简单且一般来说体验最差的方式—模态对话框，甚至什么提示都没有。
4.应用或者一些偏操作的网络产品，对话框内的按钮，如“确定”“取消”。需要有一个默认选中，支持键盘enter操作。
5.每个图标都要加上tip，尤其是用户可能不明白的拖动操作。
6.在文档中规定系统出错的提示该如何呈现，提示的文案中不能带有技术性描述（如错误类型：XXX）。如果我们不规定，技术会自己添加一些出错的模态浮层，使用技术性的语言。
7.文本长度超过标准被截断时，该如何显示。
8.鼠标的响应范围，如列表项目，radioBtn ，checkbox等。一般来说，响应范围大点好。如果我们不说，技术只会使用默认设置，如radioBtn的响应范围就只是前面那个点。
9.修改文本框内容，在获取焦点时，是全选还是将插入点放在文本末尾。
如果用户很可能会重新输入整个值，则应在获取输入焦点时选择全部文本。如果用户更有可能进行编辑，则应将插入点放在文本末尾。
10.下拉框，列表框的默认定位，比如生日。如果我们不说，技术会默认在“1900”年。
11.如果是客户端，或是流式网页布局，要提供多种分辨率下的展示。
12.在移动客户端，多点触摸，手势的操作和动画过程，显得尤其重要。
13.用户操作成功或失败的反馈，超时的反馈，系统崩溃的反馈等等。
14.移动客客户端横竖屏的不同显示方式，网络状况差时的交互反馈。
—— The End ——
