一、信息架构与流程
1.信息架构
1.1 信息架构是否容易理解
整体的信息架构、导航、模块入口的设计，是否符合用户既定的使用习惯和理解？
1.2信息层级是否清晰
信息区域间的层级关系、元素控件间的关系是否符合亲密性、对比性和重复性等设计原则，能否正确地体现与页面信息架构相符的逻辑关系？
1.3信息分类是否合理
对庞杂信息进行组织、筛选、归类时，有没有遵循用户熟悉的分类标准？对企业应用来说，分类有没有符合企业内部习惯和行业惯例？
1.4 信息视觉流是否流畅
视觉流是否存在反复和绕行现象？同一任务内的主要操作和阅读区域应尽量确保视觉流流畅。
2. 流程设计
2.1 用户体验路径是否一致
在具有相似度的任务中，用户体验路径的设计是否清晰，并具有一致性？具有相似度的任务是指虽然在具体步骤和任务目标上有所差别，但流程上有较大部分是类似或共通的流程。
（1）共通的流程节点
（2）共通的呈现元素（页面、信息和控件）
2.2返回和出口是否符合用户预期
正常来讲，任何流程都应当允许用户返回上一步，以及快速（或至少在较少、步骤内）退出当前流程，而返回和取消操作的跳转目的应当符合用户期望，让用户返回其认为最合理的位置。
2.3 逆向流程的设计是否考虑周全
这里的逆向主要指业务逻辑上，而不是2.2中简单的返回、退出操作。正向流程比较容易理解，例如电商应用中的“查看商品→填写收货信息→下单→付款”，或者企业管理应用中的逐级审批，都是典型的正向流程。而实际上逆向流程也同样不可忽视，同样用刚才的例子，电商应用中的取消订单，企业管理应用中审核人员打回一个申请、使审批流程返回上一步甚至关闭这个流程，都是在实际使用场景中普遍存在的逆向流程。一般来说，呈现在流程图上都是正向的流程，正因为此，逆向流程才更需要自查以避免遗漏。
2.5 是否充分考虑了操作的容错性
2.5.1危险操作的二次确认
在删除、返回和取消（进行大量表单输入后）等危险操作执行时，是否为用户提供了二次确认的机会？
2.5.2 提供必要的撤销功能
执行一个操作后是否允许用户撤销？
2.5.3操作失败的解释与建议
在操作失败后是否提供了必要的解释或其他可行的建议？
第二部分界面呈现
3.控件呈现
这里自查的范围主要是与交互体验关系最紧密的控件，但实际上在自查过程中可以同时检查非操作性的普通页面元素（图片、icon、信息列表、分隔元素等），没有必要分两遍来检查。不过为了叙述方便本节还是简称为控件为主。
3.1 控件是否符合用户认知
3.2 控件样式是否具有一致性
3.3 控件交互行为是否具有一致性
3.4 控件的不可用状态如何呈现
控件常常需要一定的条件触发才变得可用，例如表单页中只有在必要信息全部填写得符合要求的情况下，”提交“按钮才可用。那么，在不可用时，是直接将控件显示为不可用，还是在点击后提供反馈提示用户需要完成哪些条件才可用？两者各有优缺点，前者让行动点的不可用状态外化，让用户直观地理解自己的状态，但假如用户不熟悉当前场景，会难以知道是缺了哪些条件导致不可用；后者在点击后可以通过toast清晰地告知用户需要哪些条件才能触发可用，但这需要增多一步点击操作。因此，两者都是可行的做法，但无论采用哪种做法，都需要在交互说明中写明，前者需要写明可用条件，后者需要写明toast的提示文案。
4. 数据呈现
4.1空态如何呈现
空态是设计中必须考虑，却又容易疏漏的点。不但数据完全空缺时会产生空态，在所有涉及筛选控件的数据列表中，都有可能因为筛选的结果为空产生空态。
4.2字数有限制时超限如何处理
表单对字数有限制时，超限时是直接自动删除超出部分，还是保留超出部分但通过合理的反馈提示用户删减，或其他更巧妙的反馈手段。无论选用哪种，都需要在交互说明中写明处理方式。
4.4数据过期如何提示用户
来自网络的数据过期时如何友好地提示用户？
4.5数据按什么规则排序
涉及数据排序的列表，无论有没有可以调整排序方式的控件，都要在交互说明中注明默认的排序方式。这点还是比较容易漏的，画原型时可能只是随意设置了一些虚拟的数据，不会太考虑它们的排序方式，而这恰恰是开发同学最关心的问题之一。
4.7数据是否存在极值
涉及数值（或日期等）输入和选择的控件，有没有设置极值以帮助用户防错？如果有，在输入值超过极值时如何提示用户？
5.文案呈现
5.1 句式是否一致
相似场景中，页面标题和页面标题之间的句式结构要保持一致，文案与文案之间的句式结构也要保持一致，总之，相应位置的文字句式要始终一致。
5.2 用词是否一致、准确
操作、称谓、反馈中的用词同样要保持一致，并且应当在准确、不引起歧义的基础上尽可能简练。
5.3 文案是否有温度感
文案需要让用户感觉到产品的温度，对C端应用而言很好理解。而即使是B端应用，在必要的场景下，文案内容也应当在不影响表达的准确性和效率的前提下，避免冰冷的机械感，应结合场景和用户角色融入恰当的情感。
6.输入与选择
6.1 是否为用户提供了默认值
是否为选择控件提供了默认项？输入框内容为空时如何显示？输入框获得焦点时，默认文字是消失（即仅作为提示文字或占位符）还是保留（即作为可编辑的默认文案）？
6.2 输入过程是否提供提示和判断
是否在输入过程中为用户提供提示？是否执行输入判断，是在输入过程中执行、失焦后执行还是提交后执行？经判断输入不符要求时如何提示？
6.3 是否存在不必要的输入
是否存在以下不必要、甚至会引起逻辑错误的输入（这里的输入包括键盘输入和选择等多种输入形式）：
（1）如果某个数据是对应整个流程全局的，那么在这个流程内部，显然这个数据不需要再重复输入，每多一次输入就多一次错误的可能。
6.4 是否指定了键盘类型和键盘引起的页面滚动
当需要通过键盘进入输入时，需要在交互稿中标注调出键盘的布局类型。否则，开发同学如果将所有未标注的键盘都写成了默认键盘，会让用户不得不手动切换键盘类型、大大影响用户的输入体验。以iOS键盘为例，常用的主要是以下11种：
默认键盘（UIKeyboardTypeDefault）：用于文本输入
密码键盘（UIKeyboardTypeASCIICapable）：用于密码输入
URL键盘（UIKeyboardTypeURL）：用于网址输入
邮箱键盘（UIKeyboardTypeEmailAddress）：用于Email输入
数字键盘（UIKeyboardTypeNumberPad）：只有数字的数字键盘
数字符号键盘（UIKeyboardTypeNumbersAndPunctuation）：数字符号键盘，用于数字符号（主键盘）和字母（次键盘）同时输入的情况
电话键盘（UIKeyboardTypePhonePad）：用于电话拨号的数字键盘（比数字键盘在左下角多了”+*#”键）
文本数字键盘（UIKeyboardTypeNamePhonePad）：用于文本（主键盘）和数字（次键盘）同时输入的情况
小数键盘（UIKeyboardTypeDecimalPad）：比数字键盘多一个“.”，用于需要输入小数的情况
推特键盘（UIKeyboardTypeTwitter）：用于发布推文，右下角是一个“#”号，便于插入标签
搜索键盘（UIKeyboardTypeWebSearch）：用于网页搜索
此外，如果键盘调出后会引起屏幕滚动（为保证部分重要控件或信息可见），也要在交互说明中注明。
第三部分过程与特殊情形
7. 交互过程与反馈
7.1 是否周全地考虑了所有操作成功的反馈
操作成功后如何跳转？如何提示用户？通过toast还是设置专门的成功提示页？
7.2 是否周全地考虑了所有操作失败的反馈
因网络环境差、无网、后台故障等原因导致操作失败时如何提示用户？跳转至专门的失败提示页，还是阻断跳转、停留在当前页面并通过toast提示？
7.3 操作过程中是否允许取消
表单提交过程中是否允许取消？文件上传、下载过程中是否允许取消操作？
7.4 是否设计了必要且合理的动效
是否有必要添加动效？载入时间是否适合添加这样的动效效果？如果长时间等待后操作失败，如何提示用户？
8. 特殊情形
8.1角色权限与状态不同造成会造成哪些差异
对允许未登录状态使用部分功能的C端应用而言，需要考虑的主要是游客状态转登录状态、登录状态转游客状态时，体验路径中的差异。对B端应用而言，需要分析的则主要是根据用户在流程中的角色不同、根据用户在公司内的部门和职务不同、根据用户在同一流程中的权限不同，会在任务流程、界面呈现（例如：部分控件和入口的显示与否）文案等方面产生哪些区别。
8.2 是否提供特殊模式
是否提供无图模式、夜间模式、编辑模式，如果有的情况下，如何呈现？
设计走查表版本2
一般我们描述一个产品时，一定是将其放在一个场景中去描述的，用户在场景中和产品产生互动，互相影响。场景可能包含了移动App使用的软件系统、硬件载体、移动环境下的网络状态以及App实现的技术框架、版本兼容、使用时间、地点等内容。这些场景中遇到的问题是我们设计走查表里的核心骨架。
从用户使用移动设备的硬件特性、软件特性、网络特性，以及具体的用户界面内页面状态、页面流程完整性及消息通知，及涉及设计细节、与时间/数字相关性问题来阐述如何建立设计走查表。
一、硬件特性
1、制定适配原则
1）数量不变进行同比放大适配
2）同行数量增多
3）避免不规则背景
4) 不同设备适配时遮挡
2、账户在设备上的切换
（1）同一设备，不同账户切换
切换的新账户若曾经在本设备上登录过，则帮助用户加载展示客户端存储的本地内容，并且标记用户未处理的新信息。在加载的过程中给出明确的加载状态、内容展示。
（2）不同设备，同一账户iOS切换同一个账户在不同设备上登录时，先确定该账户是否支持多设备同时登录（多点登录）；如只支持单点登录，则在登录B设备时，A设备的账户自动被挤下线（单点登录的安全限制），并提示用户，设备是在何时何地登录的，所以退出了当前的登录状态，图5所示为支付宝账户在其他设备上登录时出现的提示。
3、横竖屏显示效果
二、软件特性
1、操作系统特性
2、制定多平台的设计规范
3、版本兼容
（1）版本覆盖时间
（2）更新提示强弱
（3）兼容性展示
三、网络特性
1、快速启动
1）让用户感知到应用的启动速度比较快
2）作为一个产品品牌展示区
3）作为一个广告展示区
2、合理缓存
3、弱网环境
（1）弱网环境下加载失败
（2）弱网环境下内容展示不全
（3）弱网无网状态下数据传输/设置生效机制
4、终端、超时
四、页面状态
1、页面初始化
2、页面刷新
3、页面加载
（1）分布加载
（2）懒加载
（3）智能加载
4、页面内容被限流
5、页面内容为空
6、页面内容失效
五、页面流程完整性
除了用抽象的流程图来确保流程的完整性，设计师还可以通过快速回到首页/主要页面、让用户始终知道自己在哪儿、返回到原来的浏览位置、任务完成后跳转这几项设计原则来确保完整性上的体验。
1、快速回到首页/主要页面
用户不管在应用的什么地方，都可以快速返回到首页/主要页面。这要求我们在搭建整体信息架构的时候，结构足够扁平。并且所有的页面流程都必须形成一个有效的闭环。
2、让用户始终知道自己在哪儿
1）通过页面标题来让用户确认当前的位置。
2）通过页面之间跳转的转场动效让用户确认当前的位置。
3）用户可以沿原路返回。
3、返回到原来的浏览位置
明确任何一个可点击的去向，且去向是可返回的。返回问题连带定位，从哪里去返回到哪里。特殊路径需要定制，可能会出现连跳几个页面的情况，在验收过程中需要重点注意。
4、任务完成后跳转
1）任务成功后，页面跳转后可返回到来源页面。
2）任务失败后，需提示当前状态，并引导用户如何查看最新的状态。在有新结果时，通知用户。
六、消息通知
根据消息的强弱进行消息通知的设计。
1、强消息通知，可以使用客户端推送，用户可以在手机屏幕或者手机的通知栏预览到内容。用户可以通过通知的新消息直达到详情页面或通知列表。用户未读的信息可以标记出未读数字，
2、弱消息通知，可以在用户打开应用后，在内容层上统一提示，告诉共有××条新消息。点击后可查看所有消息内容，如图12中的页面消息通知。
七、细节
设计细节有非常多的点，比较通用的细节有：点击状态、发送状态、输入、反馈、音效。设计师可以根据自己的需求来制定细节的走查。
1．点击状态
按钮点击状态包括开始、结束、不可点、失效、已领完、已过期等。
2．发送状态
发送状态分两种：一是发送后需要较长时间返回结果的，此时发送后直接到结果页面，结果页面上显示当前进度和最终结果及其时间；二是发送后较短时间就返回结果的，此时发送后到过渡页面，有几秒的等待时间，然后跳转到最终结果页面。
3．输入
（1）减少输入
在移动端输入的成本比较高，设计师可以通过表单、选项卡、默认填入值来减少输入。在社交会话中则可以通过更多的语音、图片、视频来减少输入，让用户沟通得更轻松。
（2）输入限制
在内容不确定多寡的输入框内，可以采用暗文或数字的方式来帮助用户确认当前的输入内容有没有超过限制。输入的内容一定要做长度限制，因为不只是在输入过程中会遇到显示的问题，在发布后也会有显示问题。
（3）中断时保存内容
移动环境不稳定，经常会出现中断退出的情况。当遇到异常情况时，可以保存用户在中断前输入的内容，待环境稳定后用户可以继续操作。
4．反馈
（1）即时反馈
当用户操作后，若有需要反馈的信息，在操作后立刻给出，反馈的区域不能距用户的操作区域太远，否则就会被忽略。如果是非阻塞式的反馈，那反馈的方式要轻，不要因反馈而干扰用户当前的任务，对用户造成困扰。
（2）反馈效果
所有的点击都要有明确的反馈状态，点击后会出现一系列的状态变化。如有的按钮只可以被点击一次，用户点击后首先按钮状态会改变，其次会产生一个与点击相关的操作结果反馈。
5．音效
应用音效需要考虑其大小，配合操作使用时是否有延迟。特别需要考虑用户当前的使用场景出现声音是否合适。
八、与时间、数字相关性问题
1．时间
（1）制定时间规范
根据产品设计需求，在前期根据场景规划时间显示规则，如格式是“2016-3-16”还是“2016/03/16”等。用在列表页面、详情页面还是会话页面都要提前规范好。
（2）不同场景下时间格式的选择
用户对于时间的感知根据场景的不同会有很大的差异。从我们的对话中就可以感受到，平时问“什么时候开周会”，会回答“周三”。但是如果问“什么时候提交报告”，会回答“3月20日”。从对话的场景中可以看出我们对时间维度的区分。因此在对时间进行设计时，一定是根据使用场景来进行时间的设计。
（3）有效/失效时间
消息、卡券、红包等都会有时效性，有的时效对用户来说是有生效期的，与生效期相对的是失效期。内容失效后需要处理，可能由清除或者其他功能来支持。有的内容是没有生效期的，但是它会变成历史内容，历史内容与现有的内容需要进行一定的区分。
2．数量
规范数量规则时，需考虑以下问题：
是否为零，为零时应该显示还是隐藏？
刷新是否影响数字变化？
数字是否会减少，当数字减少为零时是否有反馈或界面变化？
汇总整理了人人都是产品经理社区以及《支付宝体验设计精髓》中的交互设计自查表相关内容，希望今后每次画完原型都记得自查，完善细节，尽量不要遗漏一些容易遗忘的特殊状态和关键节点。不求十全十美，但求没有缺陷。
网友评论