产品设计之抽象思维（下）
Pirate Ship
前阵子，一直想写需求分析的文章，就是平时收集到的小场景业务的那种。这种需求最多，也琐碎。正好抽象思维在需求分析应用得的多，就结合一起讲了。
看个例子。
小明在京东网领了一张满100减10块的优惠券，然后买了价值400元的移动硬盘，用掉了那张优惠券，并收到了新订单通知。
流程不复杂，路径清晰。按照一般的方法来做需求分析，先一步步分解业务操作，理清主干，再画出流程图。
上面的流程尽可能照顾了每一个业务细节，这也符合完整流程设计要求，看起来让人放心，没有遗漏。现在要隐藏业务细节，仅保留关键业务对象信息，将上面的流程简化成下面的模型：
这个流程模型看上起来粗糙，没有安全感，不能帮助正常的流程梳理。实际，上面的流程图并不是对第一次的随意简化，而是作了刻意处理：
- 隐藏业务操作细节，保留业务对象。比如登录网站，准备结算。
- 将提取的业务对象抽象化。比如把优惠券抽象为卡券。
同上个流程相比，这个模型简单，不能直接辅助产品人做流程设计，但给了产品设计者绝佳视角。因为只有关键的业务对象和业务操作，我们可以把注意力放在产品结构上，来简化流程设计。
上面模型里，有4个清晰的业务对象：用户，卡券，商品，卖场（网站）。这个流程图反映的是不同业务对象之间的事件流转，正是因为不同的对象之间的业务关联操作形成了事件流，然后就有了流程。想像下面场景，一个叫小明的顾客走进了卖场，进门时领了优惠券，然后使用了优惠券买到了个想要的东西。在这一刻，小明是个具体的普通顾客角色，但来卖场买东西不一定都普通顾客，还有大买家。设计角色的时候自然要考虑这种情况，跳出具体对象。
先以用户对象为例分析，上述两种不同角色的属性和业务操作不一样，普通顾客只会发生一般性购买业务，价格是固定的。而大买家是批量采购，他会希望以优惠的价格购买某一商品，另外要享受企业级的售后服务。基于这两种角色来抽象设计业务对象时，要模糊两者之间差异细节，让这个对象具有更强适用性，既能代表小明那样的普通客户群，也能代表大买家的客户群。
对优惠券来说是一样。在上面的流程里，优惠券被抽象为卡券。为什么啊，现在是一张明确的满100-10的优惠券，但以后有活动推广需要，还会做2折折扣券，代金券等等。但系统不可能为每一种券都重新设计一次程序。就像富士康，它的生产线，肯定不会是只能加工生产iPhone外壳，而生产不了其它电子设备外壳。不然的话，你需要为一种外壳做特定的生产设备，显然是巨大的浪费。所以在做产品时，设计好合适的业务对象，能节省成本。出于产品结构设计考虑，你还需要将这些需求告诉研发团队，不然等到后期需要快速迭代时，你可能会被告知『你以为直接拿过来就可以我复用啊，前期也没需求说要考虑这些东西』。
再复杂的业务流程，分离业务对象之后，再根据事件把业务对象连接起来，业务操作作按业务对象作好相应的归属，整个流程看起来就清晰得多。不是像刚入行做流程设计，仅仅把实际操作步骤以流程的形式画出来，业务操作与业务对象混在一起，没有做任何的解构和分享，业务流程图看起来跟实际操作流程图好像没有任何区别。
这样设计的好处是，前期，产品可以做得足够简单，也能满足用户需求。后期呢，产品保持足够稳定性，还能适应产品快速迭代需要。
2B的产品工作中，一般接到的需求和业务场景都是明确的，需求方甚至会说，我需要你如何如何做，来帮我达到怎样的目的。我的做法是：
- 从业务流程出发，提取主要业务对象，再对其进行抽象化。
- 将抽象化的业务对象代入到产品结构中。
- 然后再从业务对象出发，看业务对象的变化在系统中会引起哪些影响，需要考虑哪些内容。
- 将业务对象重新代入业务流程中，将流程转化为不同业务对象之间的数值传递。
知乎上，看有人说抽象是不断去除不重要的东西，提取本质，去伪存真的过程。这个观点，我不认同。抽象化是为了获取主干信息，降低复杂度。抽象过程好比爬梯子，一端指向抽象化，另一端指向具象化，我们总是需要在梯子反复地爬上爬下，就像PS画图，有时要缩小，俯瞰全貌看看整体效果是不是在控制之中。有时要放大，深入局部看细节有没有画到位。帮我们实现：站在高处，把控和规划好产品的发展。落在实处，能够设计易用的功能和优秀的交互体验。
文／Sisyphus60
关键字：产品设计, 业务
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
