编辑导语：产品经理对于输出需求可谓是非常日常的工作了，然而有时候在工作中不可避免地也会出现过度设计的情况，本篇文章作者分享了谨慎对待过度设计的问题，讲述了过度设计的定义、出现过度设计的原因以及如何解决该问题的方法，一起来学习一下吧。

产品经理出需求如何喝水吃饭一般自然，但总有些时刻会觉得出的方案有点过于复杂或者过于纠结细节了，所以就有了过度设计的问题。

理论上，产品经理是不应该做过度设计的方案的，如同设计有缺陷一样，过度设计也表明方案不够合理，产品经理对于需求的把握还是有待加强。

但现实并不和理论一致，总是会有一些微妙的地方。

我因为最近也遇到一些微妙，所以谈一谈过度设计这个问题。

一、如何定义过度设计

前面提到过了，过度设计的其中一种情况就是方案的复杂度超过了需要本身的需要。

譬如，业务初创阶段，需要做一个推送系统，运营原本的需求是支持导入用户名单批量发送即可，需求点很简单。

创建计划的时候支持设置计划名称、批量导入名单、输入发送内容、设置消息类型和选择发送账号、设置发送时间就可以。

但是基于产品设计原则，产品经理在设计的时候会考虑通用性和扩展性，就会自然联想到要不要做用户属性选取功能、要不要做内容模板功能、要不要做流量分配测试功能、要不要做统计模块去跟踪效果。

做都可以做，用也会用上，问题是对于一个初创的业务，很长一段时间内都用不上后面关联的复杂功能。

如果方案里面包含了后面的这些功能就会有过度设计的问题。毕竟资源总是紧张的，总需要处理更重要的事情。

这种情况下，方案设计和当前业务阶段匹配程度是判断是否过度设计的标准。

过度设计的另一种常见情况就是产品方案过于纠结细节的东西，反复在调整一些很小的东西。

成熟的业务会更容易出现这种情况，业务成熟表示整体的产品框架也很成熟了，那么怎么去做优化？

就反复去调整一些细节的东西，流于形式，工作是做了不少，但是效果却非常小。

譬如一个贷款申请流程(我是做信贷业务的，以我熟悉的举个例子)，业内所有的平台产品方案都差不多的，非常成熟了。

步骤总共就5个：

1. 填写个人基本信息（婚姻、学历、住址等等）；
2. 填写工作信息（公司名称、公司地址、公司电话等等）；
3. 填写联系人信息；
4. 上传身份证照片和活体识别；
5. 绑定放款银行卡（部分平台有）。

差别仅仅在于采集的具体字段和页面顺序、页面UI有差别。

其他的差别真不大，各种营销的系统支持都已经非常成熟了。

这种情况下非要对这个申请流程做优化，这就其实很没有必要，做来做去也就是对界面的UI和交互做一些调整，但是对于整体的完成率影响很小。

极端情况下自然波动都比优化效果的变化大。

这种情况下，其实要和行业的数据进行比较，如果和最优的数据差不多，那就可以暂时放一放，不要去折腾了。

真的，一个业务想要做成要看整体数据，局部数据比别人高3-5个点没有任何意义。

二、为什么会出现过度设计的问题

如果是第一种情况，实际上还是产品经理对于业务的理解不够，没有和业务关联起来看。

商业总是要考虑成本的问题，不必要提前投入一些成本，需要的时候再投入即可。

如果是第二种情况，那就得看了。

有的时候是因为产品经理比较局限，暂时做不出好的方案，就在一些小细节上调整，确保不至于出现大问题。

有的时候出现这种情况倒不一定是产品或者其他同事的本意，但是又确实到了短时间难以有什么突破的时候，老板们又天天说要优化，那就只能做一些优化。

做的时候其实一线的人都知道是怎么回事，但是又不能不做，不然老板会觉得员工能力不行。

不要以为不会出现这种情况，这种情况其实比大家想的要常见的多。

每天都想要改变和提升，但是现实世界的逻辑不是这么走的，一个成熟的业务哪里还会有每天都有提升的事情。任何一个业务都是有天花板的。

当然，我还遇到过一种情况，产品框架搭完了，业务已经跨过了从0到1的阶段，开始往10走，这个时候发力的阶段重点不是产品和研发了。

但是产品和技术还是不能停啊，产品和技术空下来的话公司不就亏了吗，老板心里过不去啊，必须得让大家干活。

这个时候的重点是必须让大家有活干，而不是产品方案是不是过度提前了或者调整过于细节了。

三、如何解决过度设计的问题

如果是产品经理能力局限的问题，这个就只能自己提升了。能力的提升是一个水磨的功夫，只不过有的人的磨转的快，有的人的磨转的慢。

如果是出于老板的要求或者KPI的压力，尽量用行业数据和竞品的方案跟老板沟通，让老板理解方案的调整意义不大，问题的关键不在这里。

如果老板坚持的话，那就不要纠结，你没有义务为一个成年人的选择负责，付了钱也不行。

我知道有些产品经理是崇尚改变世界的，老板不对的话坚持说服老板。我不赞成也不反对，但是我自己绝对不会这么做。

如果是因为技术要空转了，那我的建议是就补补课，把之前遗留的历史问题处理一下，做做重构。

其实这个工作是不容易做的，因为不能在业绩上得到体现，所以要说服大家做这个是很难的。

我最近就遇到这个问题，之前技术设计的框架不合理，兼容性和合理性都不好。

但是因为在业绩上无法得到体现，所以代码重构推了好几次也推不动。

修修补补的经常出问题，但是还是就这么跑。

我还遇到过一种情况，老板拿着别人的后台截图跟我说参考一下，言下之意自然是抄一下。

我就发现很多功能我们暂时用不上，当然我并没有反驳，就设计了一个完整的方案。

然后告诉老板合在一起做版本太大了，可以分版本做，有些功能现在暂时用不上的，可以放到后面做。

至于后面做不做，那就根本不是个问题，老板根本不会记得还有这件事情。

你可能会多花点时间，但是仍然可以有效的把落地的方案掌握好。

四、写在最后

过度设计的问题远不如方案不合理或者方案不完整那么显眼，大家对于过度设计的边界认定是不一样的。

但我们做为产品经理来说还是要更谨慎的判断这个问题，这是专业能力的一部分。

产品经理是提解决方案的人，方案提的好不好直观的体现了一个产品经理的水平。

尽量确保产品方案在一个合理的范围内，考虑各种因素，控制成本，包含信任的损耗。

完全规避过度设计我认为是不大可能的，但确实需要尽可能规避这个问题，让自己专业起来。

本文由 @产品人玄青 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议