关于产品过度设计的一点思考
一、什么是过度设计
“度”本义是计量长短,后由此引申出“程度”、“限度”的意思;“过度设计”是指设计的功能超出了需求范围。
那么如何衡量一个设计是恰到好处的呢?恰到好处,并不是给用户的东西越多越好,而是在合适的时候为用户提供合适的功能,满足用户的需求。
设计本就是一个取舍的过程,无论是过度设计还是设计不足的问题,都是取舍的结果:
- 如果不预先设计,随着时间越久,更改成本越大
- 如果预先设计,会增加当前程序的复杂度
这种取舍没有放之四海皆准的标准,需要根据不同项目不同人员做选择。 - 可隔离的实现不做优化设计,当性能需要时再进行优化,需要单元测试支持。
- 如何为扩展性预留设计?
这 是个很纠结的问题,这里面其实有两个概念:扩展和设计。设计是为了扩展,但是设计不能完全解决扩展问题,如果非要用设计解决所有的扩展问题,那基本上就会 造成过度设计。其实很多大型项目,到了一定阶段,就是基本上重写架构了。这时候,相比可扩展的复杂设计,倒不如简单的设计,但是因为设计简单,所以代码更 易懂,更容易被重写。之前看到过一句话:有一种设计,很复杂,不会有明显的问题;有一种设计,很简单,明显不会有问题。我们应该选择后者。
相同的方案,在 A 场景可能是适当的设计,在 B 场景可能属于设计不足或过度设计——这完全取决于所处的场景、需求、以及你可以调用的资源;比如用户中台设计,当公司刚起步、资源有限、业务系统单一时,是不需要做中台设计的;而当业务系统变多,公用业务可以下沉,用户中台此时可以起到降本增效的作用。
二、为什么会出现过度设计
设计在取舍的过程中本身就是一个取舍的过程,是一个哲学问题,在产品0到1的设计过程中,过于的追求完美,设计之初就想面面俱到。
产品经理对于自己的产品,都会有一个美好的愿景,但所谓“心中有蓝图,手中有残缺”——产品的成长,是需要时间和机会的,随着市场、政策、目标用户需求等变化,产品也会不断地更新迭代。
起步阶段,抓住用户,先满足其核心使用场景的需求,再逐渐丰富产品功能和用户体验,相比耗费资源搭建一个大而全的框架更为重要。
希望功能具有可复用性
每个项目可支配的资源都是有限的,产品经理永远觉得开发、测试人力不够用,产品设计过程中也会考虑投入产出比;但因为吝惜人力成本,而“过度设计”,反而会造成资源的浪费。
没有流量的情况下,产品经理过度关注风险
产品设计过程中,注意风险把控是好事,但风险需要分等级,风险把控需要分阶段;前期产品拉新阶段,过度把控风险可能会将兴致勃勃的用户拒之门外,之后再想提高他们的活跃度,难度就增加了好几倍。
需求来自“专家”用户反馈、领导需求、产品经理猜想,用户在使用过程中根本不需要或者现阶段不需要。要知道,对于用户而言,操作越简单,使用成本越低。
三、过度设计带来的影响
产品的需求本身就不是来自于用户,还一定程度上增加了用户使用的负担,和用户的入门成本。繁杂的操作、花哨的功能,并不会得到用户的青睐,反而会给用户带来困扰
过度的设计,复杂的产品,功能都需要产品经理、UI、UE、开发、测试多方资源的投入,占用现有资源的投入,影响其他更有价值的功能开发。
没有跟紧业务节奏,业务方失去激情。一个功能的“过度设计”会导致该功能上线周期变长;尤其在业务拓展阶段,如果不能跟紧业务节奏,等业务方失去激情、信任与支持,产品也就失去了拓展的好时机,之后的合作会变得难上加难。
过度的设计在耗费了大量人力物力的时间上线之后,得到与之相反的评价(负反馈),打击了UI,UE,开发的信心,消耗了老板的耐心。加之上线之后复杂的产品带来了很多未知的bug,消耗着大家的激情。
四、如何避免过度设计
1.小公司资源有效的情况下,适当学会借用资源,比如每个app需要的埋点。产品的从0-1上线之后三方的埋点能快速的接入业务中,而不是消耗人力物力,服务器成本去自己弄一套。三方的埋点对于分析用户存留,页面停留时长,用户喜欢的功能…还有一些界面按钮具体点击情况已完全足够,安全性也完全能有保障,在公司得到长足的发展之后,再尝试自己来接手这一套埋点的业务
2. 把握核心流程
抓住最核心的产品流程,进行快速试错,完美并不是我们的目标,剥离多余的功能,保证主流程可用。
有一个思考“不追求单一维度的极致,选择全面的可成长性”
我个人观点而言,把握核心流程能有一个60分的设计,再产品初期已经足够,当然不是永远要求它只能得60分,而留下的40分是它的成长空间,它可以继续变得更好,变的更完善,这样它可以拥有良好的可拓展性、拥有可发展的高复用性。
3.明确迭代目标,有的放失
再产品前期的设计之内尽量,尽量考虑的周全一点也做到把握核心流程,做一点边缘业务的取舍。到了产品的开发周期中,产品需求的微笑调整是在所难免的,但是大调整除了已经在市场上证明这本身就是一个错误的需求,用户不需要的需求,可以调整外,没有必要动不动就推翻自己的设计,再重新设计。反问一下,难道在设计之后的没有经过市场的验证难道就一定不好吗?就一定是用户需要的吗?
在一个产品的设计中,要做做里程碑式的递进,而不是散乱的修修补补。真实的设计开发中,你很少遇到把一个设计做的完完整整再开工,这是国内软开氛围的通病,我得承认趋利的存在是必然的,所以我们经常会面对做了软设,还得回头修补。
通常来说,修补还得评审,评审还得继续走一轮流程,避免埋下风险和隐患。
这时候如果没有良好的递进,你会感受到,雪花纷飞的邮件、消不掉红点的群消息、无数的@带来的消息提醒……
里程碑式,是我对于这种混乱状态的一种解决方案。
当一个设计问题被发现,最需要立即向团队成员公开透明的应该是两部分:1是待讨论问题是什么,2是讨论结果正式反馈的最晚时间。
然后才是会议组织、问题讨论、风险评估,把这三步就在正式反馈的最晚时间前倒推出来。
这也是透明度的良好保障,每个问题都是里程碑,每个问题都会被更好的跟进和推进。
这样才能让一个需求最终转化为良好的设计,并让设计良好的产生自己的效用。