“新产初评审，问题现原形。” 新入职的高产人员，在初次评审中就陷入困境。这其中究竟发生了什么？是经验不足还是另有隐情？让我们一同揭开评审背后的真相，探寻产品设计与管理的关键所在。

系统方法论，远比经验沉淀更重要。

昨天下午，我受邀参加一个刚入职高产的首次评审，之所以说受邀是因为该同学是新业务团队的，并不是我招聘的。

虽然现在带两个团队，毕竟还挂着这个产品负责人的title，也被要求精力强制分布，也算是分内之事。

说心里话，基于对设计的天然热爱和痴迷，我还是非常乐于投身产品活动，于是也用心听完了该同学的评审会——虽然长达2个小时、虽然我觉得半小时就该结束战斗的。

遗憾的是，这次评审会听下来，又让我发现了作为高产本不应该犯的几个典型错误。

比如，会议通知时既没有提前发送相关的资料内容（TAPD链接、原型设计、需求文档等），也没有组织好会议——没有提前到会准备，以至会议室被占用，所有与会人员白白浪费了15分钟。

当然，这些还只是事务管理层面的失策，他在产品层面也是犯了不少错误，有些还很典型。

他这次评审的设计是运营需求，旨在通过某个产品推广来实现业务增长，核心就是“分销设计”，当然，包括落地页、佣金管理、分销配置等诸多模块。

举几个例子：

首先，我没有干涉该同学的设计评审，只是静悄悄地坐在后排听，但他的评审却和很多初级同学一样，上来就讲原型设计，并没有先把业务背景、需求范围、预期价值等整体讲一遍。

你看，这个误区极其常见——我见过太多太多同学有类似的习惯；同时，这个误区也非常容易改变——你只要讲过一次，绝大多数都会改变。

仅从这个角度来说，很多所谓的产品经验沉淀，如果不是有效的方法论，那就像失去磁性的指南针，只会惯性向前地累计解决问题的成本。

其实，整体看下来，他的设计逻辑并没有大问题，原型设计和业务流程也符合需求场景，但依然存在以下三个典型问题。

1、接到需求就设计，没有深度调研场景

事实上，这类问题咱们也反复提过很多次。

该同学也是一样，我全程听下来后认为他对业务的调研明显不足，事后我单独交流，发现他果然只是被动地接受业务的需求，完全按领导的吩咐去做设计翻译，并没有着重进行业务调研。

比如，我们这个需求主要是产品推广，显然，转化率肯定是北极星指标，而核心的设计要素之一则在产品的介绍内容上，即，要能快速呈现价值点，进而引导用户进行产品推广。

但从他设计的产品介绍内容来看，他并没有把握住该业务产品的核心价值点，追问下得知，该同学竟然都没有和业务同学交流，因为他也是刚入职，他甚至都不知道该产品的业务场景。

你看，只是被动地在做业务的逻辑堆叠，却忽略了设计价值的内核——业务的表达载体，这对高产来讲，属实不应该。

我在知识星球经常会分享设计常识，几乎每周都在强调设计的重点在于业务调研，产品同学的价值在于业务价值。

所以，咱们务必要牢记，产品设计要服务于业务场景，千万不要成为原型设计师。

事实上，你说调研很难吗？并不是！

很多时候我们缺的只是意识而已，而对于高产来讲，所谓设计认知（不仅是业务调研的设计认知）的方法论远远比惯性经验的沉淀要有价值的多得多。

2、宏观框架很饱满、微观细节不完善

很多高产同学都深谙宏观之道，但却不屑微观之学，于是，“不落地”逐渐成为一些高产同学的特有标签。

该同学的评审同样如此，又一次地体现了设计细节的不完善，以至于被开发追着问业务逻辑，轮番质询下完全被拿捏，专家效应荡然无存。

开头没处理好，节奏就乱了。

客观上，他的设计框架的确很系统，包括与不同业务系统、不同功能模块的交互联动、数据处理，等等，都考虑的很全面、很饱满。

但是，对于某个业务的设计规则、页面元素，却存在诸多盲区，这为设计评审带来了不确定性，也是开发反复询问的关键点。

当然，这也是评审被拖堂的主要原因。

就拿“订单分佣”模块为例，因为有不同的订单状态，如，待推广、待分佣、待收款、已完结等，而且，状态的流转逻辑不同，可能涉及多个业务系统。

比如，被推广用户未订阅系统时为“待分佣”，当订阅后则为“待收款”状态。

以往，我们遇到涉及订单等多状态时，都会出具“状态机”表格，把业务流转规则、订单状态、输入输出等都描述清晰，这样开发同学就很容易理解。

但该同学却没有对这些业务规则做详细描述，虽然这只是设计细节，但毕竟设计不容半点凑合，你不写清楚，开发效率就会低很多。

而高产的差异竞争力之一，就是能更好地提升开发效率，不是吗？

3、设计评审要严肃，不能随意做需求变更

需求评审时，当开发说工作量太多做不完时，你会怎么办？

我相信很多同学都遇到过这类场景，镜同学在以往面试时也作为面试题询问过不少产品同学，也收到了各类回答，可谓百花齐放、见仁见智。

该同学在评审时同样也遇到了此类问题，当时有前端同学反馈页面太多、工作量太大，询问能否先做一部分。

让我惊讶地是，该同学竟然不假思索地说可以，而这之后便“一发不可收拾”，后面好几个开发同学都提出时间紧、任务重，得砍需求，该君都笑着一一答应。

咱倒不是说不能减需求，而是需求不能这么砍啊，咱应该得知道需求优先级、业务价值紧迫性吧，退一步讲，至少也得了解开发具体的工作量吧？

可该同学还没等开发说完，他就急着满口答应，这让我很是意外，我甚至觉得他是不是担心转正受影响，把砍需求当做换取好感的兑换券了？

退一万步讲，咱们是产品设计师，需要对上线功能和业务价值负责，要基于市场来做迭代范围的决策，而不是凭个人意志来随意定论。

换句话说，我们要对上线成果负责，当然，尽可能多的上线更有利于业务转化。

更何况作为高产，更应该首先考虑的应该是对业务的支撑，而不是“办差思维”来决定上线内容，再退一步说，有业务需求范围在，怎么也不能主动、随意砍需求呀。

事实上，这位高产下来就被业务总监怼了一顿，因为在他疯狂修剪之下，原业务需求已经完全失真，本次上线的内容根本解决不了客户问题。

你看，这绝对不算是好心办坏事，而是妥妥地设计评审事故，流程意识不强、业务认识不足。

事后我也对他做了指导，他也意识到评审不严谨带来的一系列问题，当然，我相信该同学绝非个例。

最后，镜同学想说的是，产品设计评审绝非是设计的重点，恰恰是需求转化的交接点，是新的起点，不能因此松懈，更要慎重对待。

希望对你有参考。