编辑导语：团队在进行项目时，特别是从0到1的项目，很容易产生“过度设计”的想法；产品经理在设计时会对新项目过度关注，可能会导致人员和成本的浪费；本文作者提到了几个“过度设计”的坑，我们一起来看一下。

一、什么是“过度设计”

“度”本义是计量长短，后由此引申出“程度”、“限度”的意思；“过度设计”是指设计的功能超出了需求范围。

那么如何衡量一个设计是恰到好处的呢？恰到好处，并不是给用户的东西越多越好，而是在合适的时候为用户提供合适的功能，满足用户的需求。

相同的方案，在 A 场景可能是适当的设计，在 B 场景可能属于设计不足或过度设计——这完全取决于所处的场景、需求、以及你可以调用的资源；比如用户中台设计，当公司刚起步、资源有限、业务系统单一时，是不需要做中台设计的；而当业务系统变多，公用业务可以下沉，用户中台此时可以起到降本增效的作用。

二、为什么会出现“过度设计”

下面以我负责过的一个从0到1的项目为例，含泪说明：

1. 产品经理追求完美，设计之初就想面面俱到

产品经理对于自己的产品，都会有一个美好的愿景，但所谓“心中有蓝图，手中有残缺”——产品的成长，是需要时间和机会的，随着市场、政策、目标用户需求等变化，产品也会不断地更新迭代。

起步阶段，抓住用户，先满足其核心使用场景的需求，再逐渐丰富产品功能和用户体验，相比耗费资源搭建一个大而全的框架更为重要。

我们曾做过一款赋能销售的微信小程序产品，在前期商业模式还未得到市场认可的情况下，我们花费三周的时间搭建了一套标签管理系统，支持企业自定义标签，试图为用户画像做前期数据积累；但功能上线好几个月，企业最多只建了十几个标签。

产品经理想要做标签管理功能的出发点是好的，但实现方式需要基于当前产品所处阶段进行判断；在产品启动之初，可以通过系统内置标签的方式，帮助用户完成打标签的最小闭环，后期有实际业务需求再丰富标签管理的功能；而不需要一开始就耗费资源将其做成一个复杂的功能模块，影响其他核心功能的开发。

2. 产品经理希望功能具有可复用性

每个项目可支配的资源都是有限的，产品经理永远觉得开发、测试人力不够用，产品设计过程中也会考虑投入产出比；但因为吝惜人力成本，而“过度设计”，反而会造成资源的浪费。

我们团队成立之初，曾并行开发过多个业务系统，其中一个业务系统需要开发内容管理功能；为了避免后续重复开发，八人团队做了两个多月，搭建了一套模块化的内容管理平台。

但功能上线一年半，也只有起初的那个业务系统在调用，并没有达到预期想要节省成本、产生多份收益的目的；而且两个系统联调时，也需要消耗双方项目的资源，反而耗时耗力、产出有限。

3. 没有流量的情况下，产品经理过度关注风险

产品设计过程中，注意风险把控是好事，但风险需要分等级，风险把控需要分阶段；前期产品拉新阶段，过度把控风险可能会将兴致勃勃的用户拒之门外，之后再想提高他们的活跃度，难度就增加了好几倍。

我们产品有一个自定义个人信息以便于销售展示个人形象的功能，支持销售人员更改个人头像、从业年限、所获荣誉等信息；更改后，需后台人员审核通过，客户才能看到。

设计之初，是担心销售编辑个人信息时含有违规内容，给公司带来不必要的麻烦；但功能上线后，销售人员吐槽：更新信息后不能立即使用，还需要等待审核，其使用产品的积极性大大降低。

从数据上看，目前销售人员注册用户数不超2万，月活用户数不超5千，85%的用户仅修改头像信息，基于以上数据，对于个人展示信息着实没有必要严格审核机制；一方面用户活跃度很低，违规风险系数低；另一方面，当前不涉及资金问题，即使有违规现象，也不会给公司带来经济损失——该阶段的风险审核机制，着实有些过度设计。

三、“过度设计”带来的影响

1. 功能上线后，用户不关心

一方面，“过度设计”的需求来自“专家”用户反馈、领导需求、产品经理猜想，用户在使用过程中根本不需要或者现阶段不需要；另一方面，对于用户而言，操作越简单，使用成本越低。

繁杂的操作、花哨的功能，并不会得到用户的青睐，反而会给用户带来困扰。

2. 资源浪费

每一个功能都需要产品经理、UI、UE、开发、测试多方资源的投入，“过度设计”的功能需要占用现有资源的投入，影响其他更有价值的功能开发。

3. 迭代速度慢，失去业务拓展的好时机

没有跟紧业务节奏，业务方失去激情。一个功能的“过度设计”会导致该功能上线周期变长；尤其在业务拓展阶段，如果不能跟紧业务节奏，等业务方失去激情、信任与支持，产品也就失去了拓展的好时机，之后的合作会变得难上加难。

四、如何避免“过度设计”

从0到1的产品，最容易出现过度设计，产品经理一定要明确每个阶段的目标，通过MVP来验证迭代效果，用最快的速度去接触核心用户，验证假设。

艾永亮老师曾经说过三个关键词：“洞察”、“试错”、“偶然性”，告诉我们为什么要使用MVP快速迭代。

• 洞察：指产品调研、市场分析、目标用户分析等前期工作。
• 试错：快速地将产品迭代推向市场，根据用户反馈，不断迭代产品的过程。
• 偶然性：外界偶然性因素的存在，是助力我们将产品推向市场的关键。

那么如何进行MVP呢？

1. 明确迭代目标

通过MVP进行快速试错，明确迭代目标，有的放失。

不同阶段，迭代目标也会不同，如果是验证需求，设想的需求是真需求还是伪需求？高频还是低频？

在迭代上线后，需要根据迭代数据得出结论；如果是用户拉新，目标用户数是多少，可以通过什么方式最小闭环达成目的。

2. 把握核心流程

抓住最核心的产品流程，进行快速试错，完美并不是我们的目标，剥离多余的功能，保证主流程可用。

MVP并不是回答产品设计是否优雅，技术是否高效这样具体的问题，而是用来验证产品是否被用户接受、被市场接受，是否有人愿意为这个产品买单？那么什么是核心的产品流程？

这要结合现阶段的产品目标来看，譬如一款内容管理平台，现阶段的核心目标是支持运营人员通过后台发布内容，前端展示；那核心流程就是创建内容-发布内容-前端展示，个性化推荐这类功能就不需要在一期MVP实现。

3. 学会借用资源

尽可能借用已有资源，避免自己开发，节省投入资源；比如对于B端产品，如果“用户登录”功能，已经有通用的模块可以提供相关能力，那就不需要另行开发。

产品MVP虽然不能“包治百病”，但它的优势在于能快速验证未知的市场；唯有合理运用好产品，“小步快走，快速迭代”才是正确的做事方法。

本文由 @菡子同学 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。