一些个人思考

关于产品过度设计的一点思考

一、什么是过度设计
“度”本义是计量长短，后由此引申出“程度”、“限度”的意思；“过度设计”是指设计的功能超出了需求范围。
那么如何衡量一个设计是恰到好处的呢？恰到好处，并不是给用户的东西越多越好，而是在合适的时候为用户提供合适的功能，满足用户的需求。

设计本就是一个取舍的过程，无论是过度设计还是设计不足的问题，都是取舍的结果：

1. 如果不预先设计，随着时间越久，更改成本越大
2. 如果预先设计，会增加当前程序的复杂度
   这种取舍没有放之四海皆准的标准，需要根据不同项目不同人员做选择。
3. 可隔离的实现不做优化设计，当性能需要时再进行优化，需要单元测试支持。
4. 如何为扩展性预留设计？
   这 是个很纠结的问题，这里面其实有两个概念：扩展和设计。设计是为了扩展，但是设计不能完全解决扩展问题，如果非要用设计解决所有的扩展问题，那基本上就会 造成过度设计。其实很多大型项目，到了一定阶段，就是基本上重写架构了。这时候，相比可扩展的复杂设计，倒不如简单的设计，但是因为设计简单，所以代码更 易懂，更容易被重写。之前看到过一句话：有一种设计，很复杂，不会有明显的问题；有一种设计，很简单，明显不会有问题。我们应该选择后者。

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

二、为什么会出现过度设计
设计在取舍的过程中本身就是一个取舍的过程，是一个哲学问题，在产品0到1的设计过程中，过于的追求完美，设计之初就想面面俱到。
产品经理对于自己的产品，都会有一个美好的愿景，但所谓“心中有蓝图，手中有残缺”——产品的成长，是需要时间和机会的，随着市场、政策、目标用户需求等变化，产品也会不断地更新迭代。
起步阶段，抓住用户，先满足其核心使用场景的需求，再逐渐丰富产品功能和用户体验，相比耗费资源搭建一个大而全的框架更为重要。
希望功能具有可复用性
每个项目可支配的资源都是有限的，产品经理永远觉得开发、测试人力不够用，产品设计过程中也会考虑投入产出比；但因为吝惜人力成本，而“过度设计”，反而会造成资源的浪费。
没有流量的情况下，产品经理过度关注风险
产品设计过程中，注意风险把控是好事，但风险需要分等级，风险把控需要分阶段；前期产品拉新阶段，过度把控风险可能会将兴致勃勃的用户拒之门外，之后再想提高他们的活跃度，难度就增加了好几倍。
需求来自“专家”用户反馈、领导需求、产品经理猜想，用户在使用过程中根本不需要或者现阶段不需要。要知道，对于用户而言，操作越简单，使用成本越低。

三、过度设计带来的影响
产品的需求本身就不是来自于用户，还一定程度上增加了用户使用的负担，和用户的入门成本。繁杂的操作、花哨的功能，并不会得到用户的青睐，反而会给用户带来困扰
过度的设计，复杂的产品，功能都需要产品经理、UI、UE、开发、测试多方资源的投入，占用现有资源的投入，影响其他更有价值的功能开发。
没有跟紧业务节奏，业务方失去激情。一个功能的“过度设计”会导致该功能上线周期变长；尤其在业务拓展阶段，如果不能跟紧业务节奏，等业务方失去激情、信任与支持，产品也就失去了拓展的好时机，之后的合作会变得难上加难。
过度的设计在耗费了大量人力物力的时间上线之后，得到与之相反的评价（负反馈），打击了UI，UE，开发的信心，消耗了老板的耐心。加之上线之后复杂的产品带来了很多未知的bug，消耗着大家的激情。

四、如何避免过度设计
1.小公司资源有效的情况下，适当学会借用资源，比如每个app需要的埋点。产品的从0-1上线之后三方的埋点能快速的接入业务中，而不是消耗人力物力，服务器成本去自己弄一套。三方的埋点对于分析用户存留，页面停留时长，用户喜欢的功能…还有一些界面按钮具体点击情况已完全足够，安全性也完全能有保障，在公司得到长足的发展之后，再尝试自己来接手这一套埋点的业务
2. 把握核心流程
抓住最核心的产品流程，进行快速试错，完美并不是我们的目标，剥离多余的功能，保证主流程可用。
有一个思考“不追求单一维度的极致，选择全面的可成长性”
我个人观点而言，把握核心流程能有一个60分的设计，再产品初期已经足够，当然不是永远要求它只能得60分，而留下的40分是它的成长空间，它可以继续变得更好，变的更完善，这样它可以拥有良好的可拓展性、拥有可发展的高复用性。
3.明确迭代目标，有的放失
再产品前期的设计之内尽量，尽量考虑的周全一点也做到把握核心流程，做一点边缘业务的取舍。到了产品的开发周期中，产品需求的微笑调整是在所难免的，但是大调整除了已经在市场上证明这本身就是一个错误的需求，用户不需要的需求，可以调整外，没有必要动不动就推翻自己的设计，再重新设计。反问一下，难道在设计之后的没有经过市场的验证难道就一定不好吗？就一定是用户需要的吗？

在一个产品的设计中，要做做里程碑式的递进，而不是散乱的修修补补。真实的设计开发中，你很少遇到把一个设计做的完完整整再开工，这是国内软开氛围的通病，我得承认趋利的存在是必然的，所以我们经常会面对做了软设，还得回头修补。
通常来说，修补还得评审，评审还得继续走一轮流程，避免埋下风险和隐患。
这时候如果没有良好的递进，你会感受到，雪花纷飞的邮件、消不掉红点的群消息、无数的@带来的消息提醒……
里程碑式，是我对于这种混乱状态的一种解决方案。
当一个设计问题被发现，最需要立即向团队成员公开透明的应该是两部分：1是待讨论问题是什么，2是讨论结果正式反馈的最晚时间。
然后才是会议组织、问题讨论、风险评估，把这三步就在正式反馈的最晚时间前倒推出来。
这也是透明度的良好保障，每个问题都是里程碑，每个问题都会被更好的跟进和推进。
这样才能让一个需求最终转化为良好的设计，并让设计良好的产生自己的效用。