产品设计完毕后如何验证产品方案

编辑导读：在写完需求画完原型后，在进入产品设计开发阶段之前，产品经理要对自己的产品方案进行自我验证。本文作者根据自己工作经验，对此进行了分析，希望对大家有帮助。

一、为什么要自我验证产品方案

我们接到需求经过调研和分析过后进入产品设计的阶段，需要产出高保真的原型设计图并写需求说明文档。但在拿着完整的方案去找业务方和开发团队评审之前，我们需要自我先验证一遍或多遍（哪怕是新人产品经理可以咨询带教leader也需要自我验证），否则拿着漏洞百出的方案给到别人让别人来纠错和吐槽，只会给人留下“不专业”的印象。

我们在产品设计阶段不一定能产出100分的方案，但可以尽可能地产出90分的方案，思考得足够完整和深入，这样面对业务方和开发团队的一些质问时可以有底气地回复他们，不被他们牵着鼻子走，久而久之就会形成强弱关系，产品经理在团队中的地位也逐日下降。

我认为好的产品经理作为研发团队发电机应该是要能够引领团队的。那好的产品经理就是要具备独自产出好的产品方案这一能力。

二、如何验证产品方案

如何自我验证产品方案可以分为五个步骤：

原型逻辑验证→流程验证→业务验证→可扩展性验证→用户体验验证

1. 原型逻辑验证

逻辑能力作为产品经理基本功这是必备的，面对复杂的情况能否清晰梳理，若这方面较弱可能就要考虑自己是否适合B端产品经理了。

写需求说明文档可以很好验证原型的逻辑是否合理，每一处标注要尽量写得细致一些，每一个功能、每一个字段、每一个数据都要考虑到。一来是让自己可以仔细地思考，二来是开发、测试在看你的文档能理解得更清晰，不然他们看得云里雾里还要反复跟你沟通不就提升沟通成本了吗。

2. 流程验证

若是新增/修改了一个模块，那该模块在系统里的上下游模块是哪些，甚至关联其他系统的哪些模块。要梳理出流程，如果一个页面变动往往不只是该页面变动，其他的页面也会有略有调整的地方，也要通知到负责其他模块的产品经理，内部先协商好统一方案。如果只改自己的，也不告知别的产品经理最后导致他们不得不迁就着你的需求跟着改动，那就很搞笑了。

比如电商物流的系统——TMS、OMS、WMS、财务系统等等，系统之间的交互很多，一个复杂的需求由业务部门提出要考虑整个核心流程，不能是只看见听见业务方提的那一小块东西。

3. 业务验证

产品方案是否符合业务场景，这个很多文章都在写就不过多赘述了，主要提一下异常操作的场景。

比如设计好一个配置页面，根据这个配置页面出账单，那突然有一天用户乱修改配置项怎么办，已经出账的历史数据怎么处理，还未出账的账单又怎么调整。又比如用户误删除一条数据导致整个流程卡住了怎么办。

不要想着用户不会犯错，尤其是to B的产品，用户也是每天工作繁忙处在一个疲劳的状态，很容易误操作的。并且会有许多新员工入职，他们不会看什么产品使用手册，使用新系统怎么保证不会出错呢。

所以如何通过产品设计规避一些异常操作，面对异常操作如何用一些功能去应对，这就是产品经理需要考虑到的点了。

4. 可扩展性验证

系统必须要支持不断发展的业务，会有源源不断的需求提过来，也会有源源不断的功能需要增加。

大到整个产品的架构，小到每一个列表，都需要考虑新添东西进来现有的产品是否能够兼容，这就需要一定的行业经验了，对业务具备前瞻性，能够考虑到接下来可能会有的需求，这样在每一次设计时都可以有前置动作。想要有一颗好树最好的种树时间是十年前。

如果每次接到新需求都是大刀阔斧一连串的改动，开发团队会叫苦连天。

5. 用户体验验证

用户使用系统的体验也非常重要，哪怕是B端产品。系统要使得用户能更快捷高效地处理事务，但体验很糟糕的话，用户心情恶劣反而是降低工作效率的。重要的信息让他一眼就能看到，重要的操作让他简单几下就能完成，这都是非常重要的。

经过这五个步骤的验证，反复修改优化你的方案后，大胆拿去找别人碰撞吧，再吸取一些好的建议那一份满分的产品方案就做出来了。

作者 @半瓶水

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！