07【需求评审】& UED

1，什么是需求评审？

是产品设计完成之后，产品经理和研发团队进行细节确认的一个重要环节。

这里边包含3个比较重要的方面：

一，有谁参加？

产品经理

研发团队（前端，后端开发工程师）

交互设计师UE, （静态页面）视觉设计师UI

测试工程师：测试用例，测试产品每一个细节

二，需求评审需要准备什么？

原型图: 方便大家理解

PRD：背景，框架，流程，每个页面的规则

三，需求评审需要讨论什么？

为了满足需求，大家一起来讨论产品设计在逻辑上是否合理（责任归属：产品经理），

以及凭借现有的研发能力是否可以实现（责任归属：研发人员）

【总结】需求评审是需求的可实现评估的重要确认阶段，只有完成了需求评审，项目才能顺利进入开发阶段

2，需求评审的重要作用

主要包括一下三方面：

2.1 细节走查：

在产品设计时，需要进行产品设计和内审，基于用户操作行为，对底层交互较少

比如）

如果有个页面可以查询全站的用户使用数据，且给出可视化图表

这就意味着每次用户按下查询按钮，系统都要从底表全部查询，如果平台的用户量级很大，会造成查询速度较慢，这不是研发技术能力的问题，也不是产品设计问题，二是由产品设计延申出来的问你题

产品经理在设计时，是无从得知的。这就需要在需求评审上，以同讨论解决办法

解决办法：创建数据中心，专门维护需要查询的数据，提供中间表储存结果数据，在查询的时候仅遍历中间表，这样会很大程度上提升查询效率

2.2 可实现性评估：

评估目前研发团队是否有能力实现，或者那些部份实现起来困难

比如）跨平台对接

分销平台和仓储平台对接：多角色，多账户问题，底层数据混乱

2.3 共识的达成：

产品经理和研发人员共同达成的一个约定，约定了项目中每一处细节，每一个业务流程，确认验收标准

【总结】需求评审是需求的确认，以及最终方案的敲定

3. 为什么我的设计大家都说“没必要”

研发人员觉得你这功能设计的没什么意义à大家开始发散思维去想怎么设计会比现在更符合需求à这样直接导致需求评审被终止

研发人员不会有这种反馈，因为过少或没有需求会间接影响他们的绩效，甚至引起研发裁员

为什么呢？

• 功能相似：如果当前的需求与之前的某个需求在使用路径上截然不同，但是在应用场景上高度相似，这会让研发人员觉得在做重复事情配合程度不高
• 需求过剩：产品经理通常会维护一套项目进度表，有的地方叫“进度看板”，里边记录目前进行中，排期中和计划中的项目。如果已经有很多项目通过了评审进入排期，可以先等研发团队消化一下这些需求在组织新的需求评审
• 没有解决实质性问题：z在需求评审起初，产品经理将就该项目进行背景描述，介绍为什么要做这件事，目的是帮助研发人员理解项目的背景及价值，但是如果在后续的细节评审过程中，研发人员发现，你的设计并没有实质性的解决问题，他们自然会有些他们认为更合理的设计分享出来
• 技术实现困难

有时候让研发人员亲口说出这个功能不会做或是很麻烦，有点困难，他们通常会找其他理由来搪塞产品经理的需求，比如在会上表示这个需求实现起来不难，但是对于用户来讲没什么太大意义或者是给出其他相对简单的方案，这个时候，产品经理要弄清楚原由，如果真的做不到，可以选择其他简单方案

【总结】作为产品经理，应该观察会中细节，实时的选择合理的处理方法

4，需求评审中的“自杀式行为”

同样一个需求，每个产品经理评审的可能都不一样，导致有的需求被改的面目全非。

为什么会出现这样的情况？

主要包括三个方面：
准备不充分：框架图，流程图，原型图&PRD; 材料是否齐全，文档质量是否合格

过度妥协：过度迎合研发人员的想法，导致 前后评审需求不一致，产品总监不会接受上线后的产品

忽略验收标准：协议，上线后具备那些能力

【总结】需求评审过程中，产品经理要考虑设计的初衷，结合项目现状，做出适当且合理的决定

5，UED是？

= User Experience Design 用户体验设计 = 互联网公司设计部的名字

这个部门里有：

交互设计师 UE：产品交互方面设计，提升用户体验（简化操作流程，缩减层级机构，动态效果设计）

• 产出交互文档与产品经理确认，经过原型图设计后的产品交互,,确认没有影响到任务流程之后
• PRD 和 交互文档给 视觉设计师

视觉设计师 UI：静态页面，布局，公共组件，色质定义

发给前后端人员—进行正式开发

【总结】如果说产品经理的作用是让产品拥有一个合理的业务逻辑，那UE和UI一定是让用户有一个良好的体验

6，如何把项目将给UED 听？

产品经理设计后，

给研发人员讲解产品细节，同样也要为交互和视觉设计师讲解同样的内容

但是对于不同角色他们思考问题的方式和出发点都不一样，

• 在给 UE 和 UI 讲解时，需要注意三个方面：
  注重背景介绍：设计的样式，风格，配色等灵感依赖于产品本身。背景介绍让他们了解到 这是以及按什么事情？为什么要做这件事情？怎么样才能做好这件事情？
• 摒弃技术语言：有经验的产品经理，逻辑经常不会流于表面，会涉及到技术方面的内容，接口，数据库，前后端，服务端交互。这些对于UE 和UI无法理解，我们可以停留在行为层讲解，便于理解，角色在产品中的行为
• 大量引用场景实例：便于理解不同角色，不同操作路径，以及不同应用场景

【总结】我们需要考虑这些团队之间的差异，选择最优的描述方法

7，UED 真的会该流程设计嘛？

产品经理产出原型图需求文档PRD之后，需要转交给负责交互设计和视觉设计的设计师团队，

有的产品经理会发现，他们会和你讨论什么样的流程更加合适，出现这种原因，不鄙视流程图，而是某种原因，影响了用户体验，他们的出发点，仅仅是想提升用户体验

什么样的情况下他们会修改流程呢？

• 过长的流程：产品经理在设计时，核心要素在需求时候贴合使用场景，逻辑时候正确合理，这难免导致会将业务流程设计的过长

他们会：将长流程分层级，然后归类总结，甚至舍弃一部分节点，来解决业务流程过长

• 分支流程：如果某一流程分支 很多，在设计页面的时候要为每个流程设计页面，对视觉设计师来讲，很大的工作量，也不好后期维护，这是 视觉实际是会提出聚合的概念，将类似的业务流程聚合到一起，通过TAB切换，同时 流程间使用公共页面，省去很多绘制和维护成本

• 怪异流程：为了满足用户需求，产品经理会想尽办法再产品中添加功能点，有的会涉及不太常见的交互流程，比如再弹窗中进行滑动或者很多层级的弹窗等，他们会引用主流的交互设计来替换掉怪异的流程，从而带来比较良好的用户体验

【总结】在于设计师团队合作时，流程修改很常见，关键在于是否影响到流程的完整和安全性