交互评审的内容及意义

评审形式主要有两种：设计组内评审、项目组评审

设计组内评审

设计组内评审的意义主要在于确保方案合理与完整性，主要针对设计本身方案进行评审。

一、是否满足需求

任何一项工作评估的基础即是否满足需求。需求可以是产品商业需求或体验提升需求。一个非基于实际需求的设计，做的再好看、交互形式在新颖对于产品来说都是无意义的。

二、信息架构与流程

信息架构是否容易理解；信息层级是否清晰；是否考虑了信息的优先级；信息分类是否合理；是否具有业务拓展性；信息的浏览实现是否为一条流畅的路径。

核心使用路径是否合理；跳转和返回是否符合用户预期；操作是否进一步可简化；异常操作流程是否考虑完善；是否考虑了逆向流程。

闭环是否短路、流程中断方案、进出口是否符合预期、操作流程中的容错性

三、交互内容的合理性

布局：信息主次是否清晰，整体是否平衡。

内容：文案是否清晰、简洁、有用；内容显示极限值；是否易读。

控件：控件形式、操作是否符合用户预期；控件的各种状态是否完整。

输入与选择：是否有默认值；是否有提示；

数据获取与呈现：数据的获取途径，是否需要授权等；考虑数据多时的处理方式；

四、交互体验是否一致、符合规范

这一点主要针对在已有平台内新增功能类需求。

例如：

其实两个时间组件并无功能差异，体验也说不上哪个比哪个好多少。这种情况下，相似/相同的功能功能组件可以延用就尽量不要重新遭一个新的，否则除了在统一性上减分之外，无疑也会增加用户的理解学习成本。从而导致整体的体验下降。

五、特殊情景是否考虑完全。

如：转场中间态、异常状态、不同版本问题等(具体内容参见之前写的交互自查表https://www.jianshu.com/p/40b4e4f1220b)

项目组评审

项目组评审一般在组内评审完成后。评审内容与设计组内有所不同。项目组评审主要以交互设计师讲述方案级细节。通常情况下，项目组的设计评审是确定方案，主要以讲述方案，同时从各个角色角度出发审查可能存在的问题。

同时UE评审也需要一定的技巧，否则可能出现现项目难以推动、方案为后续迭代埋下隐患、或者临需求变动等情况...所以评审过程中需要注意以下几点：

一、需求边界清晰（交互评审会新增需求不再评审范围内）

会议一开始就要明确好设计目标和设计范畴，圈定好此次评审会讨论的边界。

评审内容一定要清晰本次需求边界，以避免会上延伸出其它需求二导致原本内容难以推进的现象。

二、交互形式的可行性

项目组评审会再次对交互内容形式等进行一次走查并提出问题。但一并不是完全核心。因为此时的交互方案一定是经过设计组内与产品确认过的方案。

三、找出问题，规避风险

无论是对业务还是对开发还是对设计本身该环节都是非常重要的。可以有效避免给后续埋雷。

四、评估项目周期，进行资源协调

交互文档出来后，需求可以说是非常明确和具体了，对后链路周期也很好评估了。

最后要生成一份会议纪要，整理确认内容以及需要修改部分。调整后邮件予参会人员，跟进后续工作即可。

评审意义

交互评审是项目流程里非常重要的一个环节，需要召集整个产品项目团队，包括产品、技术研发、视觉、测试人员等对交互进行讨论，明确需求实现的具体目标，从而达到对整个交互设计的统一认知，最后形成产品开发和视觉设计标准。同时为评估项目中可能存在的问题以及开发测试时间提供依据。