HOME/Articles/

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

Article Outline

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 中。

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

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

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

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

最终方案是怎样的呢?

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

外观设计

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)

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

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

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

有一句简单的话叫:大巧若拙,大道至简。

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