过度设计的原因不是想得太多，而是想得太少

null

上周我们在进行产品评审时，聊到了这么一个需求：活动 Banner。

在新版 Fox.ONE App 中，我们预留了一个位置，用于呈现运营和活动入口。大概是这个规划：

null

团队的产品经理最初设计时，将这个运营 Banner 位设计成一个合集，并且有比较复杂的出现和展现逻辑：

Banner 位支持多个运营广告。
运营开始时广告上线。
当用户主动关闭广告，或者用户参加完活动，对应的广告隐藏。

我看过这个方案以后，告诉她虽然方案看上去很完整，但是属于过度设计了。

在产品设计领域，过度设计(over-designing)和设计不足(under-desgining)经常困扰产品经理：

设计不足：方案复用性差，扩展性不强，不能灵活的应对需求变化，简言之，设计没到位。
过度设计：方案繁琐、复杂、臃肿，过度抽象、封装、分治。简言之，杀鸡用牛刀。

困难在于，这二者与“恰到好处的设计”并没有明显的分界线：相同的方案，在 A 场景可能是适当的设计，在 B 场景可能属于设计不足或过度设计。这完全取决于所处的场景、需求、以及你可以调用的外部资源。

相比设计不足，过度设计更危险。因为过度设计的过程往往让产品经理愉悦：炫技或是把简单的问题搞复杂化，想得特多——这似乎产生了很多高质量的工作输出，让人倍感舒适。

实际上，过度设计并不是想得特多，而是想得不够。

过度设计的问题

我们的过度设计出在两个问题上。

套用竞品或者产品设计范式

产品经理在工作中常进行竞品分析（读作“借鉴”），研究类似的产品解决问题时的做法；或者总结相似的产品设计范式。

当出现类似问题时，这些知识可以迅速用来解决问题。

这本来是好事。但如果没有意识到其他产品与自己的差异，或者没有意识到范式的适用边界与现实问题之间的关系，就会出现偏差。

很显然，我的同事肯定看过很多运营位的设计，也检验过他们的逻辑。但是忘记了我们的实际情况：没有那么多运营需求，流量也不足。

所以复杂的策略对我们来说是冗余的，即使做了，很长时间也用不上。

没有考虑到自身的实际情况对方案的影响，是想得太少。

缺乏成本意识

互联网产品经理并不是传统意义上的“产品经理 Product Manager”。相比传统的“产品经理”，大部分互联网产品经理都比较缺乏成本意识，也就是评估“划算不划算”的认知。

一个产品设计方案，内容多一点，就意味着多付出一部分额外的代价。

这里的代价可能是时间，也可能是费用。更常见的则是过度设计导致的系统僵化，无法应对未来需求变化要付出的代价。

作为一个小团队，首先我们永远都处于人力不足的情况；其次我们的需求变化会更快。

对此，方案得正确地评估成本。降低对研发资源的消耗，减低未来变化的成本，才是应该做的。

没有考虑到方案的成本对方案实施的影响，也是想得太少。

过度设计普遍存在

过度设计的问题非常广泛，即使是富有经验的团队也经常难以避免。

我曾经作为产品顾问参与了一个面向企业的 SASS 系统的项目。项目成员都非常优秀，能力也非常强，思维非常灵活。而且团队中的工程师都听过“过早优化是万恶之源”这句话，但依然会对产品进行过度设计。

例如，在一个业务场景中，他们研发的系统 A 需要将另一个系统 B 内嵌在后台中，向企业客户提供统一的使用体验。

方案的实践过程中，项目成员设计了一套完整的 UI，将整个系统 B 包装起来。这套 UI 覆盖了系统 B 的高频功能和低频功能，实现起来非常复杂，对人力和工期的要求很高。

我看过以后，提议将系统 B 的低频和高频部分分开：高频使用部分，实现一套 UI 提供一致的使用体验；低频使用部分，主要是对系统 B 的配置功能，则直接将系统 B 的配置方式暴露在系统 A 中。

这样可以在不丢失日常使用体验的前提下，大幅降低开发时间，尽快完成功能上线。

团队的项目成员能力并不差，为什么也会出现这个问题呢，有几个可能的原因：

太爱自己的产品了，太想把自己的东西做好了。
高估了团队的可支配资源（包括工期、人力、资金等）
高估了自己的精力和实现能力。
低估了复杂项目实现中可能出现的问题。
想得太少。视线局限在自己手底下的工作，缺乏统筹思考。

总的来说，我认为任何技术团队都应该阅读一次《人月神话》来降低出现这些问题的概率。

最终方案是怎样的呢？

结合我们的业务实际情况，我们给出的最终的运营位方案如下：

外观设计

null

是一个简单的矩形。
矩形的背景由一张图片充填。
矩形比例固定，以便图片充填的时候可以直接拉伸。
矩形左侧为一段文案。
矩形右侧为一个关闭按钮，是一个图标。

交互逻辑

null

当点击关闭按钮时，该入口关闭。客户端将这个广告 ID 的关闭状态记录在本地设备。这样可以免除服务器开发成本，而重装/换设备作为低频事件，广告重新可见是可以接受的体验。
当点击关闭按钮以外的区域时，跳转到运营落地页，引导用户参与活动。

接口设计

一个获取当前广告详情的接口：从服务端读取运营位详情。接口的描述如下：

{
  "code": 0,
  "data": [
    {
      "content_id": 1, // 内容 ID
      "cover": "https://www.abc.com/2019/08/10/cover.png", // 背景图地址
      "end_at": 1565737425000, // 运营结束时间
      "id": "z1Ez", 
      "schedule_id": 1, // 运营计划任务 id
      "slot": "homepage_top", // 运营位的位置
      "start_at": 1565381025000, // 运营开始时间
      "subtitle": "", // 副标题
      "title": "性感荷官在线摇骰子", // 运营文案
      "url": "https://www.abc.com/" // 运营活动落地页地址
    }
  ]
}

需要注意的是，虽然目前 UI 上运营位只有一个入口，但是接口返回的内容是一个数组，如果未来运营位要做出走马灯或者根据策略调不同的广告，这样的设计拓展性更好。

渐进式设计

无论团队用什么方式、模型、风格来合作，对于产品设计，我推崇演进式的设计(Evolutionary Design)。不是创造性设计（Creative Design），也不是计划性的设计（Planned Design）

即每一次的需求的变更和产品迭代的后续跟进，都必须完整、深入地思考，将他们映射和更新到最新的设计中来。目的是用最小成本满足最大限度的需求。

因为世界瞬息万变，需求是变幻莫测的。完美的设计和计划是不存在的，没有任何一个系统能完美地随需应变。

我们的目标只是最大限度的封装变化，最大限度的估计（而不是预测）某些未来可能的变化，提供某些系统扩展和变化的可能性，最小规模地试错，重复利用现有的数据寻找佐证，从而减低未来变化的成本。

有一句简单的话叫：大巧若拙，大道至简。

但是有一句不简单的话是：你思考得越多，用户需要思考的就越少。