交互自查表

直接进入重点，交互自查表让交互设计师和视觉设计师再提交最终完整设计稿前，反复走查，确保任务流程的完整流畅，交互细节完善，特殊状态的描述没有遗漏，用户体验良好等，避免开发、测试阶段发现，带来大范围的返工。

交互自查表，会提醒你考虑各种细节，帮助查漏补缺。

下面是整合了一些网上已有的交互自查表：

一、将人、机、设备、使用情景等因素对设计带来的影响分类：

1）、软硬件特性：设备、系统、新老版本兼容等；

手机硬件以及平台的多样性，给设计带来机遇的同时也带来了挑战。除了以上所列举的一些，我们要考虑的点还有很多，比如屏幕越来越大，当在摇晃的车厢内，大屏幕遇上单手操作，需要考虑如何通过设计使用户能够用得更自然、顺畅。

2）、网络特性；

由于移动应用使用场景的特殊性，遇到数据加载慢或者无网络的情况会很多，此时漫长的数据加载等待会令用户抓狂。此时处理好界面交互中的加载，确保用户没有漫长的等待感，并且对加载后的内容有明确的预期，就能提供给用户较好的使用感受。因此在所有涉及到网络交互的模块中，都要去考虑以上列举的这些点，必要的时候，合理地利用缓存，来提升界面的响应速度。

3）、从A到B的中间状态；

即便你的产品90%的时间都运行良好。但是如果在用户需要帮助时置之不理，他们是不会忘记这一点的。——《Getting real》

用户在完成任务的过程中，其实是在讲述一个以用户为主角的故事，因此必须包括开始、中间和终点。中间部分是主要部分，显示了用户从起点到达终点所要经过的全部地方。一方面要解决的是如果一切很顺利时，如何给用户流畅、行云流水的感觉，这就是动效能够帮我们做的；另一方面，如果在一个任务过程中需要较多的时间，用户不想玩下去了，此时是否能提供一个应景的入口，使他和应用“后会有期”，而不是让他只能杀掉后台程序，愤然离去。

4）、内容展现相关：如书籍和资讯源；

对于内容这块，最多的异常的关注点在于大量的空态、极值、网络数据过期等的提示。不同的APP根据自身的类型不同，所要考虑的内容也完全不同。

5）、用户个人属性

在大多数应用中，每个用户都有自己的专属ID，根据是否登录，用户所能享受的权限也不尽相同。所以说，考虑用户的每种可能有的状态，以及状态间的切换对于设计时的影响，就显得尤为必要。

6）、特殊情景下的状态；

特殊状态是指为了满足用户某些特定的需求而存在的一种模式，这些模式往往由于平时曝光率不是特别大，因此在设计过程中有时会被遗忘。但一旦没考虑到的话，带来的结果将是各种突兀和莫名其妙。因此将此类状态单独拎出来梳理一下很有必要。

二、按界面内容细节分类（与上面的部分重叠）

1、文本内容

文本长度：是否有限制？

文案内容：是否完整、通俗易懂、有趣

超过负载时如何显示？

核心词汇是否统一（如各种用户角色名称）

重要、复杂的操作内容是否有清晰的解释说明？

浏览到内容底部的情感化表达

2、控件

按钮类型：主按钮、次按钮、幽灵按钮、虚线按钮是否按需区分使用（一般一个界面或视窗中只有一个主按钮）

按钮状态：默认、经过、点击、置灰、选中、加载中（提交按钮）；其中不同状态下按钮的置灰，是否有说明为什么不可用？以及按钮激活条件是什么？

链接：点击后颜色是否有变化

选择组件：单选、多选、tab选，是否有默认选中项

输入框：输入及时校验，有错误时定位；有特殊输入条件限制的输入框是否有明确说明

3、表格

基础表格：内容项过多时，考虑将次要身份鉴别类信息隐藏，鼠标浮动到对应字段后浮窗显示

表格排序：默认排序和切换排序，核心字段的默认宽度

表格操作：考虑在当前表格内完成（页内编辑）；批量操作时对于互斥的选项处理

对齐：一般文字左对齐，数字右对齐

折叠、展开 ：主要内容在列内显示，更多内容点击展开显示

分页：表格内容翻页展示还是无限加载？若分页每页显示多少条内容

4、弹窗

遮罩：是否有背景遮罩

操作：主行动点是否突显，有无取消操作

核心、毁灭性操作是否有二次确认提示？

足不出户：避免滥用 Modal 进行二次确认，考虑使用覆盖层直接操作，并支持撤销

无线modality：按照规范使用相应modality

三、总结：

其实，交互自查的核心目标是：工作效率和质量的一并提升。这决定了自查表应该是不冗余的，在高效迭代的产品进程中能够快速发挥作用，通过自查表可以减少技术返工，不要因为检查而拉长设计交付的时期。