B端产品心法（1）：如何设计B端产品，且让用户愿意用？

诸振国 2023-07-22 14:18:40

前言：

家好，我是老诸，好多年没在写东西了，我还是我，一向喜欢用大白话写产品思考分享的我又回来了，因为嘛，做B端产品这么多年了，很多产品一出来就得到了用户很好很适用的肯定。其间有建筑行业，医药企业。虽然有两次差点能在这个领域里切出一个不亚于阿里的生态产业体系，也搞出过建筑行业的像支付宝这样的关键枢纽APP产品及能支撑其的后台，ERP。所以，我的B端学生朋友们总是催我写一篇关于如何做好B端产品设计的文章，希望能分享我在这行的思考。

先，我认为优秀的B端产品人的视角应始于宏观，行于微观，而在产品设计中没有什么终结，只有业务的阶段需求下的“适可而止”。

这个原则下，才会找到B端产品设计的正确合理的思路。而让B端产品设计变得更简单，也更容易快速切中价值入口，针对这个要求，及对学生及部员的要求，我整理了几个B端产品的一些关键问题：

B端产品怎么设计？用户凭什么会用你的产品？
B端产品的形态：ERP，CRM，后台，中台，及C端业务产品APP？小程序？
B端产品的真正价值是什么？大数据？价值链条？利益关系？人脉关系？
B端产品有什么发展？及怎么发展？市场有多大？
B端产品更大的价值：生态链关系，产业格局。以格局观看B端产品设计。
B端产品引入区块链有啥发展？合适什么行业？引入区块链的几点可行的实际业务设计。
怎么建设生态圈及形成自己的生态壁垒？

在多年C端，B端的工作中，我一直觉得做B端比通行的没有目标盲目的C端容易得多，因为B端每个用户都有其明确的预设立场。不像肓目不清的C端，你都不知道用户想要什么。有了预设立场，那么用户想要什么就自然好分析出来了。

但是B端最麻烦的是业务复杂性，业务一多了反而把自己搞乱了。

B端产品怎么设计？用户凭什么会用你的产品？

这个问题，我们先看前半段B端产品怎么设计？

这个问题一开始看好像无从下手，但只要搞清楚产品给谁用，什么人用，怎么开始用，那这个问题就简单了很多。所以我们要先明确产品人的三个基本设计原则：

先要搞清楚你的用户在哪，是啥，长啥样，要达成什么目的。
你的产品怎么帮助用户达成目的。
做这事对产品对公司有啥价值，能不能找个平衡点把这事做成了，还能为自己带来价值。

具体参看：《好产品只帮用户做好一件事》

B端的用户角色如何定位？从哪开始？

答：你帮用户解决什么业务流程的问题就从哪开始。

这时我们一般会先画清楚业务流程，或是设计出来吧。我先随便找些B端业务，可能相关的角色与部门都会非常多。业务内容可能也不少。截取两个简单的例子来给大伙看看：

例一：

产品经理，产品经理网站

例二：

产品经理，产品经理网站

相信很多人其实都是从业务流程着手，虽然这是如此的正确，但业务流程其实是可以换个简单的分析角度，以组织结构来考虑的。

所以我们可以将上边的业务关系分成几个维度来看：业务中的组织关系、组中的权利关系、相关角色权限及权限的领域。

思考法：

B端的用户无非是达成一个他在商业或工作中的目的，所以其职能及在企业里组织里的角色定位要搞清楚。而任何一个组织都有相似的目的导向，那就是他要完成自己所在环节的任务。高效并明确有质量的把经手的东西或事情推到下个环节。

我们先看看一般的组织结构：

产品经理，产品经理网站

组织基本上，都是树状的。一个节点下几个分枝，某个分枝下还有分枝，组织越大，分枝越多。

如果一个业务需要经历非常多不同的组织节点时，是不是业务就会变得非常复杂？每个环节都需要搞清楚？

其实这个担心是不需要的。因为任何一个组织无非只有两个：上级发布命令并审核推进情况。下级执行并反馈执行情况。

所以我们可以简单的拆分，最上层领导，看的是事情被推进的情况及对事情进行评估。自然会产生相应的手段。而下层，自然是推进这个事。被上层监督与审核。

这就是B端最原始的设计思考的开始。然后将最上与最下以不同业务维度展开，加入中间层，中间层要满足上下关系，在这之间做好自己的环节。那么你会发现，其实角色的定位思考就变得非常清晰明确了：

怎样的角色，设计围绕业务的什么功能，角色间发生什么样的关系，功能如何体现，而功能的合适标准则是这个功能的业务产出上中下游内容是什么，哪些人负责哪个业务段（领域），哪些人做为这个业务段（领域）中的执行与监督，或是接口人、审核人。定义好相应可以看见并操作的功能。即可。

（小结：任何组织必要有绝对上与绝对下两层，组织的业务多了，依业务情况自然会产生中间层。中间层。哪怕组织有非常多层，也可以先简单的以上下层关系来推导出业务中的不同角色关系。及其在业务中的定位。）

而这种思路可以适用于非常多的领域，包括医疗、基建、教育、军事、政府、党组、公司企业，各种组织中的业务整理。这是个将组织关系化简单的一种方式。

（其间复杂的其实是中间层的层层关系复杂性。但是同样可以看成是组织中的角色权利在一个业务中的简单的上中下关系）。

所以，我们可以清楚的整理出在产品功能设计上的两个必须有的性质：供需关系。发任务与收任务、监督与执行。以这个为骨架原则设计功能，就能很好的把握住用户的定位。

比方上边业务流程图例一中：

签合同的业务吧，普通客户与业务这两角色产生询单业务。发起是客户，但业务要提供相应的资料。之后客户下单，下单消息传给“物流/仓储/采购”，财务要确认这个单子，要审核要担保。

所以相应的功能与业务。出现在哪个阶段，给什么人看，一目了然。这里需要向后台，或是平台数据中心发送什么样的数据做关键记录也非常清晰。

这样前端功能如何设计，缶后端传什么，后端应该有个什么界面或功能要处理什么，及当前相关的角色方便在什么样的终端上处理这些业务，当前用户合适在什么场景下去操作？可以兼容哪些场景及操作的平台？如何保证执行的效率与信息传递的效率加质量？产品形态是什么APP还是小程序，PC上的工具还是WEB工具？，你看，确定这个B端产品是什么样的是不是自然就很容易整理出来了。

用户是谁搞清楚了，怎么设计产品解决他们问题这也有了，接下来讨论下一个问题：

用户凭什么用你的产品呢？

这就要回到产品的根本——“用户体验”这个问题上。（了解用户体验本质，具体参看：《最浓缩的概念：什么是用户体验，用户体验设计怎么做？》

用户的体验是多层次的。很多时候他说不清楚。但是能在使用的过程中去感受到。很多产品功能设计没问题，但体验这环就不知道怎么做了。如果光是停留在好看、用色、美观、易懂易学这个层次上。那基本上可以算是碰运气了。

所以在体验上，怎么说服还是要回到设计的相关业务的本质上：让用户用第一次，第一次的感觉决定用户凭什么会用你的产品。当前业务的重点。用户在做这业务的时候，内心时刻想知道想看到想触及到的是什么？

（当用户不知道你怎么让他知道呢？

答：广告呀，通过关系介绍下，用户自己找呀，群内推广呀等等营销手段我就不说了，总之，用户不知道你产品的时候自然没办法用，重点是是当用户第一次知道你并用了你的过程才是凭什么继续选择用你产品的开始）

所以，我们还是回到业务本身。如果是以客户开始，那么要想清楚，客户凭什么会开始进入，并愿意点下一步。我们需要把最开始的环节做为关键去思考。

客户第一步是询单，这里需要非常明确的是——询单发生时，到传递这个信息，如何高效的传递到业务上。那么，他想要的自然是业务给的回馈信息。如果在这个阶段，由人完成，则要提供非常快的机制，让用户一发消息，业务人员就能快速跟上。

那客户是询什么单？怎么询单？这个就成了产品第一位要考虑的事。买东西？问价格？是问什么产品的？在什么情景及场景下问？

在这里，我举一个采购型电商的例子：

当一个客户发生询单时，一般会快速的将这个用户当前是在什么店下什么场景下的什么商品，及问的什么相关信息，一并快速发给业务人员。（更好的是将当前客户的其它业务行为参数，是否浏览相关商品的可购买性评估也传递给业务人员）。

并快速从数我据资料库里将相应的常用询单信息，几个版本的不同信息，发给业务，由业务与客户间的对话，快速的做出回应。

不要让客户等待，不要让客户不耐烦，让用户快速的得到自己咨询的答案，则是体验的最基本要求。

这里我们可以再拆分：客户需要的的是业务能快速回答询问的答案是否满意。业务需要的回答客户的资料快速及可掌控的随机应变，并能引导到下个环节。

而让客户达成目的，则业务需要先具备相应的可控条件。这是体验在这环节中最关键的地方。

那如果机器化完成这个环节呢？没有业务人员。只是客户发出询问，机器能不能快速取得相关信息并快速反馈出相应的资料答案呈现给客户？那这个就成了产品设计中另外一个需要考虑的分枝。总之，做为第一位的客户而言，快速明确直接的拿到满意的资询问题的答案是客户会不会再来第二次，并愿意继续使用你的工具的前提。凭什么，就是来源于这个基本体验后的感受。

所以，在视觉层，让用户优先看到什么，怎么看，哪个区域看，多大面积看，怎么设计才合适，应该传递多少份量感？这时体验设计才有谱。在这个根本下，体验设计的达标要求才能明确量化。这也是说服用户凭什么用你的最好也是唯一解释。