做B端产品的一些设计过程与方法

一、认知B端

做C端以数据驱动，关键词“拉新转化留存激活变现”–面向对象：个人。

做B端以业务驱动，关键词“效率提升，产业发展”–面向对象：企业。

B端产品的本质可归纳为两点：

①提供怎样的服务增加了效率？ ②降低成本和控制风险

明白了以上两点后，就可以从行业属性；业务流程；信息结构和用户特色来规划产品。比如说我是做医疗体系内的产品设计，首先要了解医疗这个行业在国家政策下的一些现状，医联体系里的各种关系及从属人员的特征与区别，甚至还要了解内部的组织结构，横向部门和纵向业务交集等等… 科技时代下技术可以解决很多问题，都说B端产品要系统化流程化思维，但怎么把这些线下繁冗的角色场景功能，串联转化为逻辑清晰易用的系统工具呢？ 下面，就来分享一下工作中的一些心得吧。

二、B端产品的设计

第一个要考虑的因素是：理解服务的对象

新接触做任何一个行业的企业型客户，都要尽可能用自己最快感知力去做理解组织结构，分析出来利益的牵涉者，分割出彼此间各自细分的专业范围，范围圈又是如何去进行信息的交互，每个渠道之间哪些是受抑制的，哪些又是有效的信息等。进而才衍生出来，将有效的共享信息环境结构化设计。

（举个例子配些图）

如现在就横向做一个远程协同功能时，把这些角色对应的业务，一个个地定义出来功能模块：

清晰任务流程与功能后，分配到产品，形成对应产品的功能结构，那么这样一个基于线下标准化流程的需求，就顺利地推导到我们设计的系统方案里了。

当然，其中涉及到很多例如：条件的判断，接口的请求与返回数据等等问题，都会对有这个需求的版本规划和项目管理产生影响的，但这里先不作一一细说。下面再举例说明一下，就纵向做一个跨终端的应用，B端也不完全任何时候都是臃肿的产品，还是会有些轻巧的小量级产品，比如直播。

基于角色关系太多，又需要轻巧实用，直接抛弃现有关系网，建立定制化账号与权限，配置在云服务中，做到了跨院科都可以用。

纵观上下关联的跨度，基本上来说现在医疗体系的B端产品难是不难的，只是在严谨的业务流做梳理会稍为复杂了些，但你一旦掌握了这个体系中各个岗位角色中权限与关键性任务，做出来的解决方案完全可以做到足够合理的。那关于对象与业务先讲到这里，下面继续分享一下B端的设计曾经踩过的坑。

第二个要考虑的因素是：高效设计模块化

刚刚入B端行业的设计常会有一个现象，就是看到原本的UI后动不动就想到了“改版”二字，确实存在原有的系统风格会过于老派，可能迭代慢，已经跟不上时代感觉，于是这样：

其实企业软件用户对UI的感知没有那么多情绪抓点，满足了具体业务才是关键，所以也不是说这样改了不好，而是改改几个图标更漂亮，哪怕是整个版式都改了也意义不大。真正要用上设计改造的地方在组件方面，如何把你理解的业务，将它们封装成一个个模块，应用到业务流中，用可增可减的弹性来响应各种数据配置，这才是做B端设计的功力所在。

（举个例子配些图）

好了，做界面的设计有了组件化的思维后，进一步就是和开发的同学一起搭建出组件库。结论：把UI规范做成一个快速复用的库 +技术选型react-native混合开发 = 可基于业务整合迭代的扩容性框架。以这个标准框架为准，后期就可以很快的给不同的企业进行跨平台的定制开发了。所以，前面说到的改版改界面之事，真的需要吾日三醒吾身，深思一下设计到开发的工作价值？

第三个要考虑的因素是：先尊重后定制

听过很多的TOB的产品功能多，角色多，菜单多，权限功能多的道理，都教着如何去设计0-1这步，可是也不要忽略了这些道理背后一些场景中特定的模式，就比如还是拿医疗来举例，医院中的现有用的HIS;PASS系统，早已经是庞大得焦头烂额，这意味着对接这些指数所做出来的一些交互，做不到像C端那样砍掉几步操作步骤直达，导航栏用7±2法则等是行不太通的。体验上很繁锁，以至于产品或项目在和企业的合作中偶尔有摩擦，那么这个时候要尊重企业组织架构原来的和新有的，再评估产品的阶段是否适合给企业做定制化，正视内部研发资源合理度，如果牺牲一点体验去做技术上的优化，让产品更稳定安全地上线也没有坏处。

三、项目落地

企业级的产品生命周期长，实施周期长，长到有时候你无法想象，比如这套方案我在A医院和B医院同时进行，A医院签合同到实施跨度半年，B医院的话分分钟可能是一年半载……其存在的问题纷纷纭纭。具体讲可能是技术没问题了，是人文服务没做好；又有可能是某些医院采用的一些设备的供应商不配合，又可能该有的接口文档迟迟没有，又可能是人事物的工作环境因素没形成共识。例如我曾做过的“叫号系统”执行到具体业务场景中，因为声量在环境中的得不到院方满意，就这样一个事，整个团队反复调整才被验收，所以不是坐在办公室中，走测试流程就能让项目顺利落地的。

还有一些医院的上上级单位（比如省厅）要对医院进行考察评级时，只要与合作项目有关的事，哪怕是项目还在招投标期间都要出一分力，意思大概就是为了让更多人听得懂，看得明白，懂得用。所以，就有了不挂名做的视频宣教片，现场会宣传广告物料，甚至是业务介绍的动画，公众号长图……等方案。

（真实案例贴图）

然而不管怎样，为了项目落地所做的一切输出方案，也是为了降低了产品上线后的感知成本和沉默成本，同时也可以给到业务销售和实施培训有一定的帮助。另外，也会产生一些优良服务的口碑，还是有价值的！

四、专注

曾合作过一位从C初入到B的产品经理，他说“我几乎看过了全部的国家政策和相关文献了，可我还是不知道怎么做…”。是的B端显著特点是没有竞品没有数据模型等等可以给你参考，甚至做出来一期二期产品投用到行业的现状中可能也不过是星星火花，不像C端产品那样放到市场能打便是鞭竹声声，不能打便鸣金收兵。TOB简直是一场漫长而煎熬的战争，决定某些环节某些阶段快慢成败的因素太多了，但如若把时间拉长了去看待，能明白现在做这些事情，可能就是在累积它日来改革这个行业的基石，那现在做的哪怕只是一个小小的效率工具都是对推动行业有价值的事！点点星火亦可燎生态之源头，不坚持去做，不在行业做深潜？如何感知到呢？

所以简单地用一句话去概括是：靠谱比小聪明更重要！因为小聪明的人一般都容易找到借口放弃，而靠谱的人会明白依“谱”而练，虽然枯燥重复却会练就深厚内功的道理。可能这也是做B端产品的团队喜欢找些稳定性高的人原因所在吧。

以上四个板块内容仅代表现处阶段中自己的一些看法与心得，不算是方法论，分享出来欢迎拍砖和交流，谢谢。