C端重交互，B端重逻辑。看过很多关于C端产品设计的方法论，但对B端产品的设计宝典却少之又少。构思了一个月，增增减减，总结了几条关于B端的产品设计思维，抛砖引玉，欢迎各位朋友一起查漏补缺！

小Q最近在思考一个问题， 工作5到8年以上的高级产品经理和1到3年的初中级产品经理，除了趟了更多的坑以外，在产品设计能力上到底有哪些优势？作为供应链这一类的典型B端产品经理，随着年龄的增长，咱们的沉淀到底体现在哪些方面？如何保持持久的竞争力而不被后生们埋汰？

经过一段时间的观察思考，小Q发现产品技能本身并不是衡量高中级之间的标准，基本上干满3年以上的产品经理们，都具备足够的需求分析技巧和系统设计能力了（如果还不具备，那是不是要考虑一下自己是否适合这个行业了？）。

但随着阅历的增长，高级产品经理们会更加注重积累自己的产品设计思维和知识体系，而这些思维并不是一两个项目就能够快速催生出来的技能，而是需要在无数的经历中不断的提升自我认知，最终找到的一套自己独有的放之四海而皆准的设计法则。

01 业务思维

做B端产品，首先要培养的就是业务感。在做产品设计时，你代表的不是产品经理，也不是技术，而是设想一下自己作为一个真正的需求提出方，你面临到问题是什么，希望系统提供怎样的支持？

如果不能有很好的代入感，不能深刻的理解业务痛点，那么设计出的产品一定会有所遗漏，如同保姆和亲妈带孩子的区别一样，虽然保姆技巧足够，但情感投入相差千里，自然孩子的感受也就相去甚远了。

设计建议

服务心态。要明白所有的系统都是为业务做支撑的，解决不了业务问题的系统设计的再华丽也只是浮云一片；同理心。跳出系统和自己的岗位，站在需求提出方的视觉来充分体会业务痛点，并以此思考解决方案。这样你就能很清楚的知道自己的设计是否实用，是否有遗漏和改进空间。如果你能做到在业务和产品经理双重角色中切换自如，那你就具备极强的业务感了；流程和系统的结合。设计系统功能之前，将业务流程从头到尾梳理清楚，充分考虑线上和线下操作的联动，再在流程中需要系统支持的环节中加入系统功能，让线下流程和线上功能完美贴合。流程和系统是相互成就的，系统是为了更好的辅助流程，千万不要本末倒置，让流程来迁就系统。

02 极简思维

刚出校门那会，总以为能够设计出一套比别人复杂的系统就是牛叉，本来一个很简单的功能，一定要锦上添无数的花，每天沉浸在自己制造的复杂的逻辑和交互里无法自拔；也曾经天真的认为那些看起来简单的功能是设计者的失职，直到无数次的锤炼和洗礼以后才慢慢明白，什么是真正的“大道至简”。

无论是系统功能，还是流程上，我们都要尽量追求极简，极简的流程可以极大的减少人工成本，极简的系统操作起来更加流畅更容易上手。

但是，极简并不意味着简单，而是要求我们能够分清楚主次，充分提炼，对于重要的功能和流程，一个都不能少，但对于可有可无的功能，能少则少，能系统自动处理的就不要人为操作，能操作一步就不要用两步来实现。

设计建议

B端系统，流程大于交互，首先要思考流程的极简，再考虑如何基于流程来实现系统的简洁；交互设计上，可以向C端设计取经：突出页面核心功能区，让用户一眼就明白主次；核心按钮摆放在更加显眼的位置，以突出重点；由于B端功能状态和逻辑比较多，可以根据不同的场景和状态展示不同的功能，不要一股脑都罗列出来，形成乱花渐入的局面；B端功能以成本和效率为首要目标，设计时让系统代替人工，极力减少人为操作和人为判断成本。

03 积木思维

好的产品设计和架构一样，也是符合SOA理念的，理想的B端设计模型是将已有庞大复杂的流程化繁为简，先碎片化为一个个可以独立使用的服务，将这些服务都存放进工具箱里，然后再根据业务场景提取相应的服务，像搭积木一样，重新组装为业务需要的模块，快速适应业务变化。如此可以极大的降低研发成本，这也是目前广为流传的中台化思想。

设计建议

1）很多服务是在业务发展过程中慢慢被提炼出来的，当一个功能能够被多个业务共用时，就可以考虑将其抽象出来，作为一个独立的服务。

比如订单取消，由于客户、客服、库房都可以发起，所以就应该将各个系统的取消逻辑统一为一个取消服务，供各个系统调用。

2）服务的拆分和重组的颗粒度需要根据实际需要来制定，太粗了可复用性不高，太细了又容易增加开发成本。可以将常用的关联性强的功能一起封装打包为标准服务，若业务需要更粗或者更细粒度的服务，再定制化开发。

例如：常规场景下分配发货仓库和占用库存是一体化的服务，可以统一封装为一个分仓服务；若某些情况下只需要占用某仓的库存，则再封装一个库存预占服务，只提供占用库存的功能。

3）积木虽好，但终有其局限性，当一个工程的需求超过了当前所有积木能够组装的范围，强行组装往往会适得其反。同理，服务化和中台化也不是万能的，它们更适用于支持标准化业务场景，当业务的发展超过了当前服务所能覆盖的范畴了，就需要制造新的积木块了。

04 脉络思维

B端产品设计工作中，80%的时间都是在梳理错综复杂的流程和业务逻辑，特别是遇到一个突如其来的大项目时，业务的同事往往不可能考虑的一应俱全，这就需要产品经理协助梳理。

如何将一团乱码的需求化解成一条条清晰明了的可落地执行的需求点呢？这就需要我们具备脉络思维。

脉络思维要求我们像庖丁解牛一样，先找到需求的主骨架，顺着骨架继续拆解四肢、内脏、筋骨，一步一步拆解到最小颗粒度，做到游刃有余。

设计建议

1）先理清主干场景和次要场景。主干场景往往是业务方提出需求的初衷，最需要支持的功能，此类需求优先级一定最高;次要场景一般是搭配主干场景使用的，再没有主干之前，实现了也没有用，所以优先级较低。

2）再基于主干场景扩展出辅助场景和异常场景;辅助场景和异常场景，业务方往往不会考虑太多，需要产品经理在梳理主干和次要场景的过程中进行完善。比如设计采购录取功能，万一提交以后发现录入错误了该如何补救？

3）当一个流程中包含多个功能，涉及到多个角色或者多个操作步骤时，就要考虑充分解耦，分成多个场景需求来处理，千万不要强揉到一起，否则会变得不伦不类。

例如：库房需要增加盘点的审核功能，要求盘点员提交盘点差异数据，由仓储经理审批。

很明显，此需求中涉及到两个操作角色（盘点员和仓储经理），两个操作页面（盘点差异提交和盘点审核），尽管页面差不多，也要分开为两个功能，一个页面是专门为盘点员提供的所有盘点数据，以及提交差异功能，另一个页面是仓储经理查看并操作的盘点差异审核功能，此页面权限只能开放给仓储经理。若两个页面合到一起，万一盘点员不小心操作了审核，后果岂不是很严重？

05 全局思维

全局思维是一种大局观，要求我们站在一个更高更广的视角俯视全局，做到心中有数，不要在单个细节的得失处理中迷失自我了。

设计建议

1）明确方向，目标为王。

做为某个产品的总设计师，产品经理往往充当着船长的角色，在航行过程中，经常会遇到风雨坎坷和烟雨迷雾，这就要求船长能时刻保持清晰的目标感和方向感，分主次、懂取舍，带领船队突破阻碍，到达目的地。

2）大局意识，合纵连横。

设计一个点，要考虑到一个面，由面再及点。在设计单个功能时，要考虑到上下游系统的联通，以及本系统横向模块的影响，不能只考虑到此功能本身。

例如库房新设计了一套借出流程，满足了临时将商品借出库房的需求，但若只考虑到WMS本身改造，就狭隘了，因为涉及库存的变动，一定要考虑到ERP和营销侧系统的联动。

3）以终为始，反向演绎。

项目中经常会遇到倒排期的情况，这就需要我们具备反向演绎能力，根据项目的目标，结合资源、时间等因素综合评估，反向推演出各个里程碑和阶段性目标，并以此做取舍，保证大目标的实现。

4）审时预判，提前规划。

产品经理要懂得审势，根据自己的经验和公司战略，提前做出一些预判和规划，以防事情到跟头了措手不及。

例如年初公司确定OKR，提到今年要从线上业务向线下发展，作为供应链产品经理，就要提前考虑到采购、库存、仓储这些系统是否能支持到线下业务的开展，设计系统时提前做好规划。

5）适时归零，空杯心态。

新环境新业务面前，为了更好的掌握全局，我们要学会适时的归零，多吸收，懂变通。如果没有这种心态，我们可能会变得不思进取，顽固不化，而我们最傲娇的旧经验终会变成自己前进路上最大的绊脚石。

06 回路思维

无论我们设计的现场动线，还是流程，还是系统功能，都要有很清晰的路径，路径包括正向和回路，除了能正向操作达到目标以外，还需要能回转到上一阶段。有来无回的，就是死路。

设计建议

1）设计上要实现自闭环，不要过分的依赖于外部系统和因素。比如应该使用系统自己的内部单号做流转和逻辑处理，并与外部系统做好映射就可以了，而不是直接用外部系统单号来处理逻辑，如此可以避免因外部系统的规则变更而影响系统本身。

2）系统流程上和操作设计上要充分考虑逆向流程和异常流程，而往往这些是最难却最容易被忽视的。

比如：当操作提交到下一步以后，若发现了错误，是否还能返回上一步继续修改？在一个关键节点开启之前，是否有足够的规则校验和容错机制？如果出现了异常情况，流程和系统上该如何应对等。

3）系统新功能上线时，要考虑到新老功能切换的间档期的数据处理和老功能的正常使用，比如正在老功能里运行中的数据该如何处理，历史数据该如何处理，查询报表是否会受影响等。

07 开放思维

业务是进化的，系统也要跟着进化。在一个系统设计之初，需要我们有开放的心态，尽量考虑到未来与内外部业务和平台的协同，打破孤岛效应，让系统联通协作起来，如此才能产生更大的价值。

设计建议

在以某个需求为出发点的设计时，思考此功能是否可以支持其它业务的发展，若有其它类似的业务发生的可能性，那就可以提前做好预留；设计新系统时，思考与其它系统的协同和联通，开放自有数据、服务、接口，让数据自由流转，产生单个系统无法实现的价值；实现公司内部业务的功能时，思考未来能否为外部业务赋能。例如履约、采购、库存、仓储、配送能力的开放、系统的开放等。