评审形式主要有两种：设计组内评审、项目组评审
设计组内评审
设计组内评审的意义主要在于确保方案合理与完整性，主要针对设计本身方案进行评审。
一、是否满足需求
任何一项工作评估的基础即是否满足需求。需求可以是产品商业需求或体验提升需求。一个非基于实际需求的设计，做的再好看、交互形式在新颖对于产品来说都是无意义的。
二、信息架构与流程
信息架构是否容易理解；信息层级是否清晰；是否考虑了信息的优先级；信息分类是否合理；是否具有业务拓展性；信息的浏览实现是否为一条流畅的路径。
核心使用路径是否合理；跳转和返回是否符合用户预期；操作是否进一步可简化；异常操作流程是否考虑完善；是否考虑了逆向流程。
闭环是否短路、流程中断方案、进出口是否符合预期、操作流程中的容错性
三、交互内容的合理性
布局：信息主次是否清晰，整体是否平衡。
内容：文案是否清晰、简洁、有用；内容显示极限值；是否易读。
控件：控件形式、操作是否符合用户预期；控件的各种状态是否完整。
输入与选择：是否有默认值；是否有提示；
数据获取与呈现：数据的获取途径，是否需要授权等；考虑数据多时的处理方式；
四、交互体验是否一致、符合规范
这一点主要针对在已有平台内新增功能类需求。
例如：
其实两个时间组件并无功能差异，体验也说不上哪个比哪个好多少。这种情况下，相似/相同的功能功能组件可以延用就尽量不要重新遭一个新的，否则除了在统一性上减分之外，无疑也会增加用户的理解学习成本。从而导致整体的体验下降。
五、特殊情景是否考虑完全。
如：转场中间态、异常状态、不同版本问题等(具体内容参见之前写的交互自查表https://www.jianshu.com/p/40b4e4f1220b)
项目组评审
项目组评审一般在组内评审完成后。评审内容与设计组内有所不同。项目组评审主要以交互设计师讲述方案级细节。通常情况下，项目组的设计评审是确定方案，主要以讲述方案，同时从各个角色角度出发审查可能存在的问题。
同时UE评审也需要一定的技巧，否则可能出现现项目难以推动、方案为后续迭代埋下隐患、或者临需求变动等情况...所以评审过程中需要注意以下几点：
一、需求边界清晰（交互评审会新增需求不再评审范围内）
会议一开始就要明确好设计目标和设计范畴，圈定好此次评审会讨论的边界。
评审内容一定要清晰本次需求边界，以避免会上延伸出其它需求二导致原本内容难以推进的现象。
二、交互形式的可行性
项目组评审会再次对交互内容形式等进行一次走查并提出问题。但一并不是完全核心。因为此时的交互方案一定是经过设计组内与产品确认过的方案。
三、找出问题，规避风险
无论是对业务还是对开发还是对设计本身该环节都是非常重要的。可以有效避免给后续埋雷。
四、评估项目周期，进行资源协调
交互文档出来后，需求可以说是非常明确和具体了，对后链路周期也很好评估了。
最后要生成一份会议纪要，整理确认内容以及需要修改部分。调整后邮件予参会人员，跟进后续工作即可。
评审意义
交互评审是项目流程里非常重要的一个环节，需要召集整个产品项目团队，包括产品、技术研发、视觉、测试人员等对交互进行讨论，明确需求实现的具体目标，从而达到对整个交互设计的统一认知，最后形成产品开发和视觉设计标准。同时为评估项目中可能存在的问题以及开发测试时间提供依据。
网友评论