review的英文含义: 再检查,重新探讨;复审
review 的概念源自Code Review，我们先了解一下Code Review：
Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低的多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性得被引入到软件开发过程中。
为什么进行Code Review
1、提高质量
2、及早发现潜在缺陷与BUG，降低事故成本。
3、促进团队内部知识共享，提高团队整体水平
4、评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统
几种常见的轻量级代码评审方式：
1、Over-the-shoulder – One developer looks over the author’s shoulder as the latter walks through the code.（它由作者启动和主持评审，作者向评审者展示文档。优点是启动快，成本低，缺点是容易被作者误导过程）
2、Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.（优点自动化，可以及时提供最新代码进行评审，缺点是无法达到人工筛选的功效）
3、Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.（源于XP，作者与评审者平级，可以帮助同伴间的学习和共享）
4、Review Meeting – (定期组织review会议，轮流有团队成员选出自己的评审作品，需要系统化得预备、总结和追踪。优点可以提高团队整体技能和对产品的理解，缺点是评审范围有限，成本较高 )Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review.
Options of Code Review(代码评审的选择)
1、最近一次迭代开发的代码
2、系统关键模块
3、业务较复杂的模块
4、缺陷率较高的模块
那么作为互联网产品或软件产品中的重要角色-UE设计人员如何进行Design review呢？
UE设计的核心是用户（客户）为中心，所以反馈对于设计过程至关重要。在我们工作中，常见的设计评审会发展成人们以设计为靶向开始指指点点，而设计师会变成为了说服同行而展开非常细节的讨论并发展成吐槽会。
然而，设计团队中比这个更坏的是：没有讨论。一个设计师负责一个产品，自己做方案自己评审，没有标准。
还有更坏的：根本就没有讨论会。
在UE团队中，要想Design review发挥最大作用必须要有一个可以遵守的规范，确保整个团队参与并高效的进行。
1、基础规则
每个项目一个月至少做一次Design review
每次会议不要超过六个人参与
每次会议要有新人参与，可以获得更多看法
项目的首席设计师应该出席并组织review，获取一手反馈
会议必须强制执行
与会人员围坐在一坐听主讲设计师讲解方案
如果有任何问题都可以提问，主讲人必须回答问题
如果每月没有Design review，将被记录并惩罚
如果部门有新人做Design review，要求有一位老员工陪伴，新人主讲。遇到难题时老员工代答。
2、review的准备阶段
首席设计师需要保持会议的高效，快节奏，在一小时内完成。所以有条理和设置范围是关键。
一旦我们选择了参与者，我们要发一个邀请告知他们要准备什么东西。一般包括：
时间地点
方案目标
一些重要的约束条件比如：“内容不能改变”
方案的时间线
当前产品的保真度
如果需要的话，带上设备
review的目标（例如我们想尝试了解什么）
方案引导应该确保所有材料都已展示出来。在做review的时候，我们试着去创建一个原型说明完整的用户行为或用户流。包括用户在进入网站或者app之前做的任何步骤。如果用户体验以收到邮件为开端，那我们的原型就从邮件客户端开始。
在会议开始的一小时前，我们会发一个关于以上内容的提醒。
3、review的进行阶段
设计师在板子上写下方案的目标和评论，让参与者可以记得住。然后他们让参与者看原型，并提供给用户一些可能需要理解流程的情境。
设计师千万不要给参与者灌输他们的设计或者想法。
设计师然后给做review的人一个合理的时间（大概25分钟）让他独立理解原型。做review的人需要做笔记，并且自己拿好自己的反馈意见。我们鼓励做review的人写有价值的笔记：
一直牢记方案的目标
记下你喜欢什么，不喜欢什么
避免主观的看法，比如“这个好丑”
试着不要去代表目标用户，除非你自己是目标用户
把反馈做优先级排序，首先聚焦在最重要的问题上
4、讨论反馈
我们至少留下一半的时间做review的反馈，也可能会更长。
我们问每一个做review的人要一张反馈清单，每个反馈都必须进行讨论——有的建议很明显不错，大家都会同意，有一些产生分歧的意见则需要另行研究。 设计者在引导讨论的时候要牢记以下内容：
让讨论继续下去，不要出现讨论拖延或让一个人主导讨论
如果人们不同意一个观点，记下来稍后投票
记住，不是所有反馈都有用，要忽略一些想法
当所有人都结束了讨论，或者离结束还有10分钟，设计师停止收集反馈并且开始整理。
整理出一个最终的反馈清单，我们鼓励大家在Invision上添加评论，这样设计师可以追踪问题。如果正在在线查看原型，则用像Trackduck这样的评论工具。
5、review的后续阶段
讨论结束后，方案的设计师要花一些时间思考每一张反馈清单，探索可能的解决方案。不要求设计师在讨论会上就做出解决方案，这些可以等到之后有时间再进行。
设计师在后续阶段，不需要考虑所有反馈，设计师需要关注的是哪些要保持，哪些要改变，设计师要做的重点是聆听，并保持开放的思想。设计师需要记住，你不等于你的设计（切记切记）。
只要方法正确，心态开放，设计review便能提供非常有用的观察和视角，如果你的设计能够让自己使用很顺畅、舒适，那么客户也会有同样的感受。
参考：https://www.invisionapp.com/blog/how-to-run-design-reviews/?utm_campaign=Weekly+Digest&utm_source=hs_email&utm_medium=email&utm_content=17833079&_hsenc=p2ANqtz-8b8MTxUgwYjXbaHKnwGim1TrAkmGJ