互联网B端产品设计经验总结

一、什么是B端产品

B端产品，可以概括为：在供求关系中，给供给端使用的产品或系统。

B端产品区别于C端产品的特征是：

C端产品，侧重满足个人生活需求，给用户提供愉悦感（满足便利、新鲜感、虚荣心、欲望冲动），好玩。
B端产品，侧重满足组织生产需求，帮用户提升效率（发现并解决业务问题），有用。

有一个段子讲“手机那么好玩，还找什么女朋友呀”，这里的好玩，多数来自C端产品给用户的愉悦感。

而贯穿B端产品迭代发展的落脚点是：在业务流程中发现问题、解决问题，并提升效率。

二、我的B端产品设计经验

写这篇总结的基本思路是：如果要做一个独立且相对复杂的B端产品系统，该如何开展产品设计工作？

主要包括以下几个方面：

B端产品系统设计的基本原则（指导思想）
B端产品系统设计的五个步骤（具体怎么做）
B端产品系统设计中需要避免的误区（不要那么做，或不要做成那样）

（一）基本原则

1.“产品思维，业务导向”

先说“业务导向”：产品系统是为业务服务的，所以要尊重业务的发展规律，最终让产品帮助到业务的发展。产品经理要到业务中去了解业务的宏观与细节，根据业务抽象系统逻辑，用互联网的方式系统性的解决问题或提升效率。

再说“产品思维”：产品经理有责任把原来自己可能不熟悉的业务，熟悉并抽象成产品需求且把事说清楚，并能够提供合理化的解决方案，不能只做需求的传声器——“他们给我提了一个需求，我们就做这么一个功能”，避免为了做而做。

由于业务快速发展，有些组织中没有“产品经理”的角色，又或者其他角色的成员主动承担了“产品经理”范畴内的工作，岗位名称无所谓，是否有经验无所谓，重要的是在承担这个事情的时候做到“产品思维，业务导向”，这是把事做好的基础。

2.用使用者角度去思考

所有的产品经理都知道“用户体验”，不过很多人理解的“用户体验”偏重在前端交互、视觉文案上。对于B端产品来说，只关注这些是不够的。所以我喜欢用更普通直白的说法——关注“使用者角度”。在设计产品的时候，想一想真正的使用者他们需要一个什么系统？他们会怎么用这个系统？现在的实现方式对他们来说好用吗？

很多B端产品，当产品经理离开办公室作为一个普通用户的时候，是想不到或者用不到的，所以极端的情况会出现，在需求开始之前产品经理没有用过相关产品，系统上线之后产品经理也不会用自己做的产品。B端产品经理，一定要走入具体工作场景，观察真正的产品使用者在具体的业务氛围中是怎么工作的。我一直相信一点：只有沉浸其中，才能更好的理解。

在小度掌柜（百度外卖商户端）电脑版上线第一周，我去一家商圈头部商户的后厨蹲点了俩小时，看餐厅的工作人员是怎么接单、处理订单的，在现场我发现我们的“接单”按钮有点小、不够明显。回来之后，我和视觉设计师沟通优化方案，给他们描述我们产品使用的具体场景：8平米的小屋（拥挤嘈杂），配置不高的组装电脑（显示屏分辨率不高），工作人员站着处理三四个平台的订单（紧张慌忙）。在这样的场景下，还需要工作人员俯下身去“寻找”操作按钮是不够效率，也不厚道。以此说服视觉设计师愿意接受“不符合设计规范”的大号按钮。

还有一个案例，是在优化客服系统之前，我去百度外卖的客服工作区，站在客服同学的背后，看他们怎么接电话、怎么记录信息、怎么解决投诉，只有这样才能了解客服人员在使用系统的时候需要什么功能，在哪些环节浪费了时间。

针对和内部使用者的沟通合作，个人觉得可以重点做好以下几点：

产品经理是来解决问题的，不要担心一锤子买卖（而提海量的需求），开发资源是有限的，我们可以一起来排需求优先级（不是所有的功能能一下子全上线）；
建立好信息同步机制，固定时间固定方式同步关键进展（当然所有信息同步方式里，面对面沟通效果是最好的）；
不要依赖业务方提需求，要帮业务方想方案，由于角色的不同、思维方式的不同，业务同学不一定能提出自己真的需要的功能，产品经理要主动去思考业务中的问题，并形成需求；
通过一两个项目，建立互信，形成互相支持的关系。

3.考虑系统的延展性与弹性

业务肯定是发展的，而当前的资源和时间是有限的，一个版本的需求，不会解决所有问题，迭代是必然的。怎么增加系统的延展性与弹性，减少后续研发的开发难度、减少使用者的后续学习成本就很重要。尤其是在设计1.0系统的时候，更考验产品经理的这项能力。

一方面，需要增加对业务发展的预见性，当前业务是怎么样的，以后一到两年会怎么发展，甚至未来五年的形态是什么样？没有人能保证自己的预测一定是对的，但是尊重业务规律，去思考业务可能的发展方向，提前想到的越多，在设计系统的时候能考虑到的延展性与弹性就越多。用“谋全局”的高度去思考一个系统，才会生成更合理的当前“谋一隅”的一版需求。
另一方面，在具体的产品方案里，针对这个系统的核心业务落脚点、基本单位尽量做到“模块化”——方便组装、方便基于这个标准模块叠加逻辑。下文的“定义最小颗粒度”会详细阐述这块的思考。

总之，一个好的产品系统要做到适合延展、有容纳新功能的“弹性”，B端产品经理要有这个自我期许。

（二）五个步骤

1.确定产品系统的目标

接到一个需求，首先要想：这个系统给谁用？要做哪些事（解决什么问题）？系统的边界是什么（需要覆盖到什么范围）？

在这个大目标下，开展后续的工作。

2.梳理业务流程（用逻辑把系统串起来）

业务流程中包含哪些角色、包含哪些关键节点，从头到尾的顺向流程是怎么样的，从尾到头的逆向流程是什么样的，中间的分支流程是什么样的，从上到下、从下到上各类角色怎么配合……

梳理业务流程要做到以下几点：要闭环（不能有半逻辑，不能有停留在某个环节走不下去的流程）；要看到底（不只是宏观上合理，最底层的细节逻辑也要覆盖到），要有边界（一个全的系统是什么，不是没边没延）。

争取用一个大的业务流程图，把整个系统要解决的问题包含进去。这样做的好处是，可以把功能想全了，防止有重大逻辑缺陷，或遗漏功能。

3.定义最小颗粒度（基本单位）

基于上述业务流程，会发现有一个“基本单位”可以从头到尾、从尾到头、从上到下、从下到上顺畅的在这个系统里流转。

这个基本单位就是需要我们定义的“一件事”，拆解到合理大小颗粒度的“一件事”——这个系统主要解决的问题的基础组成部分，靠这些最小颗粒度的“一件事”组成整个系统。
这个“一件事”在系统存在、流转有哪些“节点”，这个“节点”对应的是系统里的关键状态；
不同的人，在这个系统里存在，就是系统里的“角色”；
有哪些“角色”可以针对“一件事”的“节点”产生影响，针对哪些内容产生哪些影响就是“权限”和“数据范围”。

根据业务流程，抽象出：基本单位“一件事”、关键状态的“节点”、使用者的“角色”、“权限”、“数据范围”。这个系统就基本成型了。

以客服工单系统为例：

最小颗粒度的基本单位“一件事”是指“一个投诉”，不是一个电话（太小了），也不是一个人的所有投诉记录（太大了）。
“节点”：就是工单的状态，从投诉开始、到流转到相关部门或负责人、到最后投诉解决，工单的每一次停留都可以作为一个“节点”。
“角色”：除了一线客服、小组长、客服负责人，还有其他配合部门的角色等，凡是参与到这个系统的人都可以概括到某类角色里；不可概括的参与者或需要细化分工的参与者，需要增加角“角色”以适应需要。
“权限”和“数据范围”：各个角色能做哪些操作、操作哪些内容、造成哪些影响就构成了“权限”和“数据范围”。

一个好的基本单位就像集装箱一样，具有普适性（可以灵活被处理）、具有弹性（方便添加功能）。定义好一个系统的最小颗粒度，系统就成功一半了。

我见到的B端产品设计里，做的不好的多数就是由于最小颗粒度的定义不合理，造成系统逻辑不全或延展性很差。

4.建立框架与归类（用页面把系统串起来）

根据不同的角色、不同的功能，进行归类，进而组合成一个整体框架，用页面的形式呈现出来，就可以形成交互稿。

从第二步到第三步，从第三步到第四步，是一个拆解再组装的过程，先拆解了、揉碎了再用产品思路组装起来以形成最终的产品形态。

5.撰写需求文档

将上述梳理的过程和内容，用文字的形式将产品逻辑、图表、页面、功能点串起来，并进行丰富细化，就形成了需求文档。

好的需求文档应该：逻辑严谨，条理清楚，文字简练，能把事说清楚。

每个角色（交互、视觉、开发）都能准确理解需求的背景、目标、实现方式，大到流程逻辑，小到功能细节。可以针对不同角色，提供侧重点不同的需求形式。

尽量用平实的语言（而不是形容词）描述需求，挤压任何歧义空间。

（三）需要避免的误区

1.看不到底

一个新用户，第一次使用系统但通过自己的琢磨看不懂这个系统（不会用、不知道都有哪些功能），我觉得这个系统不算好系统。好的系统，可以通过页面功能或者不多的介绍，就能把底层逻辑和边界看明白。

看不到底的伴生现象是特殊逻辑多，造成的问题往往是枝蔓太多。产品逻辑用打补丁的方式，解决某个问题可能很快捷，但长期来看，这种方式影响产品系统的简洁性和条理性。

看不到底的坏影响是，一方面使用者（尤其是新人）学习成本高；另一方面新增功能时容易挖到“电线”，增加了维护与迭代成本。

2.延展性差

上面的文字已经提到，由于初期考虑的不周全（业务理解的前瞻性不够，或者最小颗粒度定义不清楚等）造成系统延展性差，增加一个功能就像给系统做一次大手术。所以尽量在产品设计初期，考虑的多一些，每一次迭代都想着为后续迭代提供便利。

3.所有问题都想着用产品系统来解决

一个系统不能解决所有的问题，也不是所有的问题都适合用产品系统来解决。有些事（需求）从投入产出比、灵活性上来说，通过管理规范、SOP、Excel去解决可能比做一个系统更适合。

三、B端产品经理的自我修炼

在和那些令人佩服、事业有成的前辈/领导一起共事过程中，还有我这几年的工作感受，我觉得B端产品经理需要持续沉淀的能力有：

1.理解业务

无论是O2O也好，互联网+也好，B端产品要解决好业务的问题，必须要去理解业务，要了解这个行业的历史与现状、关注行业的发展。

除了垂直的业务逻辑，多数的互联网+都会涉及到商业问题，经济管理、市场营销这些知识会帮助产品经理开阔思路、提升商业思维。

2.沟通协调

B端产品多数业务链条比较长，涉及角色较多，一个B端产品的成功，离不开相关角色共同努力与相互支持。

通过一两件事，建立与合作部门的互信，是后续合作的基础；建立固定的信息同步机制（与研发团队的每日站会，与业务部门的每周周会等），是合作顺畅开展的保障。

在工作中，能够发现资源、利用资源都是一种能力。

3.持续学习

让我佩服的那些前辈，平时办公桌上都会有一本书。一个人能力很强不可怕，可怕的是他还一直在学习。

无论是这个时代，还是互联网行业，都发展太快了，我们需要持续学习。

主要结论总结

B端产品是指：在供求关系中，为供给端提供服务与支持的产品。
B端产品系统的核心价值在于：发现问题、解决问题，提升效率。
B端产品系统设计的基本原则：“产品思维，业务导向”；用使用者角度去思考；考虑系统的延展性与弹性。
B端产品系统设计的五个步骤：确定产品系统的目标；梳理业务流程；定义最小颗粒度；建立框架与归类；撰写需求文档。
B端产品系统设计中需要避免的误区：看不到底；延展性差；所有问题都想着用产品系统来解决。
B端产品经理应该持续沉淀的能力：理解业务；沟通协调；持续学习。

作者：刘玉强，腾讯OMG内容平台部，高级产品经理。之前在百度外卖任高级经理，陆续负责了商户端、客服系统、供应链系统、电销系统等B端产品的策划与管理工作。作者公众号：theorangly。

互联网B端产品设计经验总结相关推荐

【万字干货】产业互联网B端产品经理实操手册
一.前言时光飞逝,转眼间,距离编辑<字节跳动-飞书团队工作1年收获总结>已经过去一年半左右,离开飞书后加入贝壳金服.这一年半的经历真可谓"丰富多彩",虽然有很多动荡和 ...
产品经理（14）#移动端产品设计
目录用户体验最小团队配置今日十大热点贴吧移动端产品设计做方案案例(自由行产品) 具体内容启动项广告页新手引导 1.幻灯片引导 2.遮罩引导 3.浮层引导 4.交互引导案例(快车- ...
万字好文 | B端产品设计指南
本文由作者阿翘AKIU 于社区发布很多人都说,做B端产品最重的是搞清楚业务逻辑,只要搞清楚业务是怎么运作的,就能做出满足业务需求的产品. 但是B端产品所处复杂的业务需求环境,如同茂密的森林一样,产 ...
设计|从活泼的C端产品到严肃B端产品设计，我是如何自如切换的
大饼,资深交互设计师,UEDC交互项目组主管 2013年加入网易,先后在参与或主导易信.网易杭研质量保证部项目.网易云信.网易七鱼云客服.网易易测等网易云产品等多项产品的规划构思与用户体验设计. 我最 ...
B端产品设计之原型设计
前几篇文章从B端产品设计的业务.流程设计角度出发,给大家阐述了自己的想法,这篇文章将从原型设计角度出发,主要是原型设计工具,如何设计原型,设计边界,设计规范以及PRD结合这几个方面阐述. 话不多说,开 ...
B端产品设计与运营实战
老于笔记·03.28 有创造力的人不会沉溺于过去的痛苦,他们会学会教训:而弱者则是整日沉浸在痛苦里,回顾以往的苦难来折磨自己. 正文随着互联网和传统行业的深度融合,产生了新的生态,面向企业的产品和服 ...
产品经理基础-10运营平台端产品设计(完结~撒花~）
10运营平台端产品设计文章目录 10运营平台端产品设计一. 运营平台端产品功能规划二.平台端用户管理产品设计 1.用户列表 2.用户审核三.平台端内容管理产品设计 1.内容审核 2.分类管理 ...
产品经理基础--07用户端产品设计
用户端产品设计文章目录用户端产品设计一.确定用户端产品核心功能产品简介: 产品描述: 关键词:有态度的技术分享: 产品定位:技术性头条: 目标人群:IT行业从业者: 使用场景:遇到技术难题时, ...
B端产品设计：价值主张与需求对应的价值
老于笔记·01.04 你可以要求自己对人好,但不能期待人家对你好.你怎样对人,并不代表人家就会怎样对你,如果看不透这一点,你只会徒添不必要的烦恼. 正文 B端产品的需求来源于场景,产品经理通过满足客户 ...
B端产品设计——批量导入
作者:weag (转载已取得作者授权) 最近工作过程中,涉及到两次批量上传文件的设计,也存在一些异常情况等的困惑,参考了一切B端产品进行总结. 本次总结,参考了:钉钉.有赞.草料二维码.企业微信等产品 ...

互联网B端产品设计经验总结

互联网B端产品设计经验总结相关推荐

最新文章

热门文章