交互设计自查表
1. 信息框架与流程
-
- 信息架构
-
信息架构是否容易理解
- 整体的信息架构、导航、模块入口的设计，是否符合用户既定的使用习惯和理解？
- 项目案例：虽然在信息架构设计阶段，我们已经通过卡片分类法初步选取并验证了符合用户心智模型的名称，但在交互设计的初步方案完成后，自查中首先应当注意的仍然是这些最上层的信息架构设计，是否符合用户既定的使用习惯和理解，必要时可以拿输出的页面找朋友或同事帮忙进行一些非常简短的测试，看看是否存在这方面的问题。
- APP的一级页面使用了iOS用户最为熟悉的底Bar标签导航结构，4个标签页的名称和对应功能都符合用户使用其他产品时培养出的既定习惯：“开始”提供最重要的信息提醒和模块的快捷入口，“消息”收纳了各类的通知和待办提醒，“项目”作为核心模块提供项目管理的入口，“我”则是在各类应用中都已为用户所熟知的个人页面，提供用户个人的资料、统计和设置等辅助功能。在自查和测试中这些方面都表现很好，没有出现问题，但在“开始”页8个模块入口和“我”页面的4个快捷入口上，在自查中还是发现了一些问题。下面举两个例子，因为涉及一些很难一言两语讲清楚的需求背景，如果觉得理解起来有困难的朋友可以略过。
- 例如，”发送通知“原先名为”发送消息“，这可能会导致部分用户据此认为这是一个双向的、类似聊天的功能（如微信、QQ），而实际上，根据客户的需求，这只是一个单向信息传递的功能（更类似于邮件），因此自查后将其改为”发送通知“，更符合用户对这两个词的认知。
- 再比如，”我“页面中的一个便捷入口”我的请购“原先名为”我的采购“，该便捷入口的功能定义是直达该用户发起的采购申请，而“我的采购”会让用户误认为这是采购人员查看自己经手的采购申请的入口，改为“我的请购”后则有效解决了这一理解问题。
-
信息层级是否清晰
- 信息区域间的层级关系、元素控件间的关系是否符合亲密性、对比性和重复性等设计原则，能否正确地体现与页面信息架构相符的逻辑关系？
- 项目案例：在项目管理模块的项目人员架构调整页面中，项目头图（包括项目号、项目名称、所在地、地图背景）是在项目页面中贯穿始终的全局性元素，层级较高，与下方的人员列表之间通过间距这一简单的方式体现了层级的不同。而人员列表中，有逻辑联系的元素（同专业的人员）和无逻辑联系的元素（项目经理、工艺、电气等不同专业之间）的设计也符合了亲密性、对比性、重复性等原则的要求，头像列表方式避免了大量人员信息的过载和混乱。但也不是没有问题——原先”专业负责人“和”设计人“字样使用了同样的灰色，没有体现出两类角色之间的差别，将”专业负责人“字段改为红色后每个专业负责人和普通设计人的配备更加清晰和一目了然。
-
信息分类是否合理
- 对庞杂信息进行组织、筛选、归类时，有没有遵循用户熟悉的分类标准？对企业应用来说，分类有没有符合企业内部习惯和行业惯例？
- 项目案例：本项目作为一个面向化工设备制造企业的管理应用，信息的分类和用语自然要贴合行业人员熟悉的习惯。例如，人员的分类上，工程部内部的人员按照行业习惯，根据项目经理和工艺、电气、仪表、设备等不同专业进行分类（见1.2附图，此处不再赘述），而公司层面的通讯录模块中，二级导航则按照客户的部门架构进行划分。任务进度页面的筛选控件也需要注意这点，例如”专业“分为工艺/电气/仪表/设备共4种，”阶段“则按客户企业的项目运营流程分为投标（方案）/设计/采购/安装/调试/验收共6种，”状态“则同样根据客户熟悉的标准分为进行中/延期中/已完成共3种。自查中注意再根据与客户确认过的需求仔细筛查一遍，避免想当然地采用了不符合用户实际使用习惯的分类。
-
信息视觉流是否流畅
- 视觉流是否存在反复和绕行现象？同一任务内的主要操作和阅读区域应尽量确保视觉流流畅。
- 项目案例：各个管理模块的进度页面中，如果当前用户是当前流程的执行人，则页面上需要有一个”执行“控件，让当前用户去执行下一步操作。例如在采购流程的发票确认阶段，如果当前用户是采购人，则采购人需要通过”执行“控件去进行验收成果的确认（或拒绝）。而在设计这个控件的位置时，原本为了遵循充分利用导航栏空间的原则，自然会想到把它放在导航栏右端作为文字按钮，这在普通的页面中并无不妥，但在这个页面中，采购人员的阅读顺序是：
- (1)确定当前阶段 → (2)阅读设备、数量、所属项目、请购人员、发起时间等基本信息 → (3)确定自己在本流程中的身份（因为部分场景下，当前用户的身份可能有多种可能性，需要用户再做确认）→ (4)在列表区阅读此前的流程历史，必要时可上下滑动或点击查看附件 → (5)确定当前步骤等待自己完成的是什么任务 → (6)执行该任务。
- 而在1~5步中，阅读顺序几乎是严格由上而下的，并且用户会在阅读过程中认真地确认各项信息，也就是阅读的专注程度比较高。那么第6步的”执行“控件如果放在右上角，虽然简化了页面的元素、节省了空间，但会造成视觉流的大折返。
- 所以，在最终交付的版本中，我将”执行“按钮设置在了页面底部，并且始终处于流程历史列表的上方，从而确保了不打断用户在专注阅读过程中的视觉流。
2. 流程设计
-
用户体验路径是否一致
- 在具有相似度的任务中，用户体验路径的设计是否清晰，并具有一致性？具有相似度的任务是指虽然在具体步骤和任务目标上有所差别，但流程上有较大部分是类似或共通的流程。
- 项目案例：本项目中共有3个涉及逐级审批的流程——采购流程、报账流程和工资核算流程，具体的需求背景和设计细节就不在这里展开讲了。简而言之，3个流程的具体步骤和执行角色等细节自然是迥然相异的，但当这些步骤分解到最小元素时，可以发现有很多：
-
- 共通的流程节点：都由发起、审核（确认或拒绝）、信息提交（含上传附件）、关闭、完成这些节点构成，只是节点的顺序、数目、对应角色和需要执行的具体操作不同。
-
- 共通的呈现元素（页面、信息和控件）：都包括流程历史记录列表、详情页、确认表单、拒绝表单、流程关闭表单、附件上传控件、执行按钮等元素。
- 这些具有相似度的共通部分在设计时，要尽量采用完全相同的节点和呈现元素去实现，确保体验路径一致。不要让用户在采购流程中看到的是一个样子，在报账流程对应的页面又看到的是另一个样子。
-
返回和出口是否符合用户预期
- 任何流程都应当允许用户返回上一步，以及快速（或至少在较少、步骤内）退出当前流程，而返回和取消操作的跳转目的应当符合用户期望，让用户返回其认为最合理的位置。
- 项目案例：现场图库模块的上传现场照片流程中，用户可能希望直接退出照片流程，也可能只是希望返回上一步重新选择要上传的照片。
-
逆向流程的设计是否考虑周全
- 这里的逆向主要指业务逻辑上，而不是2.2中简单的返回、退出操作。正向流程比较容易理解，例如电商应用中的“查看商品→填写收货信息→下单→付款”，或者企业管理应用中的逐级审批，都是典型的正向流程。而实际上逆向流程也同样不可忽视，同样用刚才的例子，电商应用中的取消订单，企业管理应用中审核人员打回一个申请、使审批流程返回上一步甚至关闭这个流程，都是在实际使用场景中普遍存在的逆向流程。一般来说，呈现在流程图上都是正向的流程，正因为此，逆向流程才更需要自查以避免遗漏。
- 项目案例：采购管理模块中，采购流程中各阶段的执行人可以拒绝确认上一阶段的结果，将流程打回上一步。对这类逆向流程的反馈形式，我在交互说明中指定了被“打回”的流程记录的显示形式。
-
跳转名称与目的是否一致
- 检查每个跳转入口的链接名称与目的页面名称之间的一致性。
- 项目案例：确认一遍每个可能因为画稿子时想当然导致不一致的链接名称，例如不要出现链接是”个人资料“、而跳转到的页面标题是”修改资料“的情况。
-
是否充分考虑了操作的容错性
-
危险操作的二次确认
- 在删除、返回和取消（进行大量表单输入后）等危险操作执行时，是否为用户提供了二次确认的机会？
- 项目案例：添加供应商时，当用户有填写信息的情况下（视为可能进行了大量的输入），”返回“操作就是一个危险操作，因此在进行返回时需要弹出Alert窗口（标题”放弃添加？“、副标题：”将放弃已填写的供应商信息“、以及”确认“、”取消“两个按钮）让用户进行二次确认。二次确认框的标题和副标题文案、按钮文字，以及确认后的返回去向，都在交互说明中进行了阐述。
-
提供必要的撤销功能
- 执行一个操作后是否允许用户撤销？
- 项目案例：采购流程、报账流程、工资核算流程中，在任意一步，流程的发起人如果发现自己提请的信息有误，都可以通过全局性存在的”关闭“按钮撤销其发起的流程。
-
操作失败的解释与建议
- 在操作失败后是否提供了必要的解释或其他可行的建议？
- 项目案例：新建项目流程中的第2步是在地图中对项目所在地进行定位，而当定位位置读取结果出现异常时，可以通过toast对定位失败进行解释，并建议用户检查网络及GPS设置。交互文档中可以在交互说明中写明toast的文案。
- 需要强调的是，这里只是建议大家在自查中确认这几个问题。而不是说一定要在全部流程中强行加入容错性的考量，无论是二次确认、撤销还是操作失败提示，都要视情况而定是否有必要：
- 过多不必要的二次确认会大大降低体验的流畅性
- 所有操作都可撤销会让后台数据交互和消息推送的负荷都极大地增加，即使是必要的撤销也可以放在后台、并不一定要作为移动端的功能
- 在用户熟知如何处理的、显而易见的操作失败后，给予过于详细的提示会让用户产生被当成傻子的感觉
-
2、界面呈现
3.过程与特殊情形