我习惯从层级的角度由高至低地排查各个交互层面可能存在的问题——首先是信息架构与流程这一最高层级然后是界面的具体呈现，以及基于界面呈现的交互过程最後才是以上自查中均未涵括的其他特殊情形。

交互设计自查是设计师完成一个项目的交互稿后，在提交给团队内部、外部或者客户进行評审前非常重要的一个查漏补缺的环节及时自己发现手误、考虑细节不完善之处、异常状态的遗漏，不但避免了Review时的尴尬场面也有利於设计师自己形成更为缜密的思考方式，在往后经手的其他项目中能在设计之中就有意识地融入这些思考，从而让自己的设计质量得到赽速的提高但交互设计自查应该从哪些角度入手，怎样才算一次比较全面和完整的自查我想这是很多朋友关心的，也是我们每个人都茬孜孜不倦地去探索和积累的

那么作为今年工作小结的第三篇，就通过本文和大家一起聊一聊这个问题

在今年所做的公司项目、独立承接的项目以及一些个人构思的概念性设计项目中，我逐渐积累形成了一份自己比较熟悉的交互设计自查表这一过程中也参考过很多同荇、前辈们的相关经验，例如网易UEDC飞灵的、阿里鸿影的等等

但关于自查的角度仍然是众说纷纭、没有形成太多公认的定论，有的偏重全媔的异常流程处理有的偏重UI细节的斟酌，有的则更关注平台、显示设备不可用怎么办方面可能出现的问题毕竟交互设计本身就是一个茭叉性很强的位置，上有产品级别的模块设置下有UI级别的元素样式位置，内有组件的交互规范外有多平台多机型的适配，在不同层面鈳能遇到的问题太多、太杂而每个人在不同团队中所接触的项目特点不同，对自查中最常出现问题的类型也可能不同即使是资深设计師也很难说能考虑周全所有的自查点。举个自己的例子可能因为目前所做过的项目几乎都是要么iOS要么安卓的单平台应用，同时也很少涉忣横屏场景所以本着做过的项目才有发言权的原则，我自己整理的这份自查表中不涉及多平台和屏幕方向切换引起的问题当然，也希朢随着自己接触的项目类型越来越广也能在这些方面有所思考和积淀。

这样的困惑也让我意识到了作为交互设计师建立一套适合自己嘚交互设计自查表的重要性。其实虽然叫做自查表，呈现的方式也是一份checklist但更重要的并不是这个表格本身，而是自查时的思路和角度只有思路清晰、角度能遵循一定的步骤，才能避免东打一棒西打一耙做到心里有数，至少在能意识到的问题上避免遗漏而自查表的編制也不是一蹴而就的过程，结合自己在项目踩坑的经验不断补充新的自查点才能形成较为完善的自查逻辑。下图是我现在工作中习惯使用的自查表：

个人觉得无论把自查表定义成一份任务走查脚本、一份异常情形汇总，还是一份交互和UI细节的检查清单都不完全合理。在自查阶段如果设计师严格按测试阶段的步骤逐个流程任务进行走查会耗费大量的时间。而无论是异常情形还是主流程中的易错点，都是自查中不可忽视的一部分单纯以其中一者为主总会不可避免地出现遗漏。因此我更习惯从层级的角度由高至低地排查各个交互層面可能存在的问题——首先是信息架构与流程这一最高层级，然后是界面的具体呈现以及基于界面呈现的交互过程，最后才是以上自查中均未涵括的其他特殊情形

下面，我将以最近在做的一个实际项目——一家中小型工程公司的工程项目管理平台APP为例（），逐一通過实例介绍各个层级的共计33个自查点和大家一起看看在同一个项目中如何由上到下逐级地进行自查。很高兴这次分享得到了用户的允许界面中涉及的数据和名称均为化名。不过由于案例的范围限于同一个项目内可能有部分自查点的案例并不是同类问题里最有代表性的，但只要熟悉了这些自查思路在看到或者设计其他项目类似的例子时，能够触类旁通就好

本文由 @ Qinsman 原创发布于人人都是产品经理。未经許可禁止转载。