“过度设计”的坑,你踩过吗?

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

一、什么是“过度设计”

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

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

相同的方案,在 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协议。

主营产品:全贯流泵,轴流泵,潜水泵,矿用深井泵、潜水泵