刚结束完新版本更新迭代需求评审会议，忙了好几天的工作算是告了一段落，趁着有空,写写评审这件事。
记得去年刚开始工作的时候，对于评审这件事感觉很是恐慌,每次面临评审的时候就会紧张到睡不着觉,那段时间评审简直算是一个工作噩梦，造成这个情况的原因有二，一个是不知道该怎么去表达讲解方案，另一方面是在做评审方案的时候思考的维度太小了,只想着方案的一个点。最后的结果就是导致在评审会上错漏百出的方案被研发人员打成筛子,简直像是一场屠杀。后来随着评审次数的增多才有所好转。现在就写写我自己对于评审时做得不好或者不够好的地方进行反思吧。
1、理清思路，提升专业度
在工作中经常会接收来自各方各种各样的需求，有时是对于产品的功能需求，有时则是其他业务部门提出来的内部需求。众所周知，产品规划与交互设计最核心也最难得的是怎样去思考用户体验与商业价值之间的平衡，用户体验与运营成本的平衡，因此，在很多时候，如果完全的按照用户角度出发去做理想的方案在产品设计中是不太实际的。所以当我们接收需求的时候，抛开需求目标与实现方案以外，我们也需要从其他角色的角度去思考这个方案的可行性是怎么样的。比如，纯用户角度的心理模型，业务部门的出发点（诸如运营、销售..）、技术条件的约束、研发资源的安排等等..这些都是会影响到我们最后呈现出来的设计方案。
因此当我们沟通完需求,双方在需求的理解上达成一致开始做设计方案的时候，首先先过一遍逻辑，不要漏掉各种边际状态与条件，在评审前先跟团队里的相关人员有个初步的确认，比如跟技术同事确认这个需求在技术实现上的问题，研发的工作量大概是多大，功能设计在现有的技术框架内是否会造成影响，影响的范围及限制是怎么样的；所以在需求评审会议上，应该把所有会出现的问题先过一遍，把这些业务或技术冲突点全面描述给相关人员，探讨是否能够取得更加平衡的方案等。在产品交互上往更高的专业去深造对需求有更高的追求是每个人必须努力的方向，只要做出的方案更加认真专业,自然而然评审会议就会开得轻松一点。
2、不要沉溺产品细节,分清优先级
罗列目标优先级，在设计评审时引导大家聚焦在需求最核心的目标上，分清楚芝麻与西瓜各自的重要性。比如一个优化注册流程的需求核心目标是提高转化率,因此会设计到登录框与注册页面的设计，但这些页面设计不是重心，那么就需要在优先保证需求目标的基础上再去探讨注册页面怎么去引导用户。在需求评审中，内心要清楚知道哪些是核心,哪些是次要，优先解决核心目标，而不要太过早的沉溺到产品细节里。
3、学会做好PPT及演示方案
在日常产品设计研发中，带有清晰注释说明的静态交互文档是远比动态文档要更有效率得多了，但是,在涉及多个部门的需求方案评审中，带有接近真实效果的Demo演示出来的效果是更加直接一目了然，大家能够在短时间内更好的理解。虽然对于需求评审而言，评审是目的，静态设计稿的好处在于可以呈现多种边界场景及注释说明，能够花费较低的成本对设计稿进行修改。而高还原的设计稿如果想要涉及到每一个页面的跳转与每一个元素细节还原会耗费非常高的时间成本，因此，在需求评审中，我们可以利用一些交互工具做一个动态demo辅助静态说明稿来进行演示，这样可以使得大家更加直接理解设计方案，给出更有针对性及有用的建议。
以上就是我个人近期对于需求设计方案评审的一些反思与总结，希望接下来能够在工作中有更好的发挥，做出比较优秀符合自己预期的产品。
