00前言

本文目的

写这篇文章的目的是帮助对B端产品设计能力有需求的同行人，让他们更直观的感受B端产品的特点，并掌握B端产品的设计方法。我并不是一个很成熟、很强大的分享人，因此我写的东西可能不足以让人从0到1的、系统性的学习B端的产品知识。我认为好的工具和方法论有很多很多，且每个人所处的团队、环境也千差万别，因此只有合适自己的工具和方法论，才能发挥最大的价值。我所写到的内容都是在学习中和实践中所得的，在当前我的这一阶段，十分适用，如果对大家有所启发，哪怕只是其中的一点两点，也是好的。

本文受众

这篇文章的受众是产品经理（PM）、设计师。有人可能会说，PM和设计有什么相关，去研究行业、研究用户啊，去发现痛点、发现需求啊，去建立指标、做用户增长啊，去增强转化、提高收入啊。甚至最近有一种迹象，大家对于PM去做设计很鄙视，甚至去鄙视PM画原型。个人猜想，估计是因为很多PM在入行初期，是通过学习画原型踏入这个岗位的，加上对PM入行门槛低的普遍认识，导致无论是PM自身，还是其他相关岗位，都想去鄙视一下去建立自己的存在感。

本质上PM要对产品负责，从发现到解决。发现是很重要，但是解决同样重要，因此你要去解决你的发现，并合理高效的落地成产品。而获得前人的设计经验，特别是已经验证过的设计经验，绝对是最有效的方法，哪怕你不是最终的设计者，你可以帮助团队匡正方向、提高效率。

01 何谓B端产品

何谓产品？

根据菲利普·科特勒的一个著名的营销学术观点，产品是市场上任何可以让人注意、获取、使用、或能够满足某种消费需求和欲望的东西。B端产品里的“产品”，专门指软件产品或者互联网产品 。来自维基→

何谓B端产品？

我们人为的按照用户维度，将互联网产品分成了C端产品和B端产品。

• C端产品：为个人产生价值。
• B端产品：为组织产生价值。有时候B端的产品也可以为个人产生独立的价值。

如何定位C端产品与B端产品？

随着互联网的发展，互联网产品的复杂程度大大提高，让用户交付价值的方式也变的更加多元。因此很多时候很难准确的定位一个产品是C端产品还是B端产品。比如淘宝，他的APP主要是向C端用户交付购物的价值，而他的商家系统（淘宝后台）则在不同场景、不同的业务维度，为个人卖家或者企业卖家交付价值。

下图从价值交付对象、业务复杂程度、用户的组织复杂程度三个维度，给常见的互联网产品定定位。
注：【使用用户的组织复杂程度】是指产品用户在角色上的多样性，以及协同关系的复杂性。

B端产品的形式

从产品形式上来讲，C端产品一般以APP、小程序、智能硬件的形式呈现；B端产品一般以WEB系统——通常说的管理系统或者后台——来呈现，有些业务领域对随时随地的要求较高，因此产品也会以APP的方式呈现，比如钉钉。

这里要说明的，一个产品的采用什么样的形式为用户提供价值，其唯一根据就是需求，而不是惯例。B端产品之所以一般采用web系统呈现的原因主要是：

1. 业务的复杂性对界面展示面积的要求较高，web能有效降低交互难度；
2. 某些操作比如导入文件等在web上更高效；
3. web上成熟的前端框架，有利于高效实现产品；
4. web上更容易实现“可配置性”。

同理，形式并不决定产品的属性，比如一些产品是通过web端进行的，比如微信公众号的管理平台，比如头条的内容发布系统，我们虽然是管理系统，看起来像是B端产品，但事实上他们主要是面向个人交付价值的。

B端产品由于其封闭性、业务和协同的复杂性，通常很难被大众轻易接触到，更难以体验其完整功能，因此B端产品有一种与生俱来的神秘感。说直接点，C端产品好抄，B端产品不好抄…没得抄。如果没有真实的从业经验，产品经理很难通过对开放资料的学习，积累B端产品的设计能力与经验。

B端产品的分类

借用B端产品领域前辈杨堃在《决胜B端》中的描述，B端产品可以分成3个主要方向：1.业务平台方向，2.办公协同方向，3.商家管理方向。基本认同他目前对B端产品的划分。

图片内容来自杨堃《决胜B端》

B端产品的决策机制

C端产品具有用户（使用者）客户（消费者、决策者）统一的特点，B端产品则有用户客户分离的特点。因此，相对C端产品来说，B端产品的决策机制更加复杂，同时客单价相对较高。图中B端产品和C端产品的交汇处是面向中小型企业的产品，这种B端产品具有一些C端产品的特征。

图片内容来自于第三届seeconf的分享

02 B端产品设计的关键特征

1. 以事为目标，强调效率

C端产品是以“用户”为目标的，关注人，核心是解决人的需求；B端产品要更多的以“事”为目标，关注业务，核心是如何高效的完成任务/业务，企业效率第一，而非个人效率第一。B端产品一般都是基于企业现有业务做优化，先有业务后有产品，因此必须尊重企业组织的业务的客观情况，不能以管理员视角，随意的创新来引领用户。

图片来自于第三届seeconf

2. 范围比深度重要，强调功能完整

C端产品常常会有一个核心的价值或者功能点，基于这个功能点，用户就已经有足够的动力来使用产品，其他的已知需求慢慢满足，未知需求慢慢挖掘即可。C端产品可以很轻，B端产品不行。必须给用户提供足够全的功能，不然由于他们的业务很复杂，功能不全可能会造成他们的业务断路。

有没有客户要的功能比好不好用重要；使用效率够不够高比使用门槛够不够低是否易用重要；是否易用比是否好看重要；产品结构是否稳定，比不断的创新产品呈现方式重要。——有赞白鸦

延伸一点，关于交互设计，关于用户体验。

• 关于交互设计，交互设计很重要，但是远不是最重要的，甚至对B端产品工作来说，交互是锦上添花，核心还是对人、事、痛点的认识，并解决问题、优化效率。如果对人和事的认识都不够，根基都打不稳，何谈交互的有效性。
• 关于用户体验和交互设计，用户体验一定是大于交互设计的。举个例子，一个产品能够实实在在的解决了用户的问题，但是交互设计上做的粗糙、不专业，这个产品是有用户体验的。另一个产品交互设计做的很用心，细节天衣无缝，但是解决用户问题上产生了断路或者部分空白，这个产品也是有用户体验的。但是前者的体验好于后者的体验。
• 在B端产品中，范围和深度一起决定用户体验，体验仍然重要，但是交互设计没那么重要。利用成熟的web框架，可以用极小的成本，高效实现出交互体验还不错的产品，比如个人最为推崇的Ant Design。

3. 尊重差异化需求，强调可配置性

C端产品常常是颠覆式创新，产品引领用户，用户适应产品。B端产品必须尊重企业组织的业务的客观情况，先有业务，后有产品，需要采用渐进式创新。企业业务的客观情况千差万别，和企业的组织、战略、发展阶段等息息相关，因此几乎无法用一套固定的模式适应所有的企业。所以，为了降低产品的边际成本，B端产品的功能需要更强的“可配置性”，通过配置功能模块、页面组件、工作流、角色、权限，来适应不同企业的不同需求，帮助企业高效地实现价值。

4. 多角色，多权限，满足组织需求

B端产品的用户在使用产品获得价值的过程中，通常需要多角色的协同，这与现实中的企业的运营情况相似。在B端系统设计的前期，仅仅研究用户个体是不够的，对于企业组织架构和用户角色的调研至关重要，需要产出基于角色的用户画像。

多角色的协同，不仅仅是多用户的协同。多用户和个人仅是数量的区别，而多角色体现的是不同角色间的不同的描述，即角色复杂性，其核心属性是权限。因此B端产品中权限的数量和颗粒度就很关键。

5. 架构复杂，强调架构的合理性

由于企业的业务多样性与复杂性，企业组织的复杂性与职能的多样性，B端产品有时需要架构复杂的产品来整体满足企业需求。

比如对于一家电商公司来说，前端系统可能包括对细分领域1的在线自营电商A，对细分领域2的在线自营电商B，2B2C的电商平台C，对下游分销客户的分销系统D，等等，为了支持这些前端业务，需要的业务后台系统包括电商管理系统、仓储管理系统、会员系统、CRM系统、呼叫中心系统，等等，每个系统需要可以支撑多个前端业务中共同的领域，既保证业务的高效运转，又提高效率避免重复建设。最近很火的中台建设，也是基于此的考量。另外，基于组织运转的需要，职能协作系统要包括OA、HRM系统等等。如此复杂的企业级产品架构，十分考验架构设计能力。

图片来自杨堃《决胜B端》，这本书关于企业产品架构有很多详细讲解。

03 B端产品设计的流程方法

04 B端产品设计的核心环节——调研

知己知彼，百战不殆；不知彼而知己，一胜一负；不知彼不知己，每战必败。 ——孙子兵法·谋攻篇

创业或者做产品，都是太不断的突破自己的认知边界。

“认识”是PM的核心工作，行业研究、竞品分析、用户研究都是认识这一部分的工作。足够认识行业，才能判断项目未来在商业上获胜的机会；足够认识企业或用户，才能做出符合需求的产品并卖出去以获得收益。认识的越完整、越准确，决策正确的机会就越大，反之，则犯错的机会更大。精益创业中的MVP和快速迭代试错，其实也是期望通过更小的成本、更快的速度，获得更准确的认识。

上面提到的行业研究、竞品分析、用户研究都是互联网PM常做的事情。从整体上，我将B端产品PM的工作分为四个方向：1.行业；2.企业；3.用户；4.事。本文会重点讲认识用户和认识事。

1.认识行业

创业是战场，你需要知道你在哪里，对手在哪里。在地图上的位置与作战的方式，注定了企业的进退生死。 ——梁宁《增长思维30讲》

先认识行业，再认识自己，再认识对手。往往很多时候，PM的视野对外只能关注到对手的产品（竞品）这一个点，这会带来很多问题。因为你的企业和对手的企业不一样，所以对手的产品手法也许适合对手的企业，却未必适合你的企业，你学过来未必合适。

这几天在读《三体》，读过的朋友应该会对里面的“射手”的假说印象深刻。

“射手”假说：有一名神枪手，在一个靶子上每隔十厘米打一个洞。设想这个靶子的平面上生活着一种二维智能生物，它们中的科学家在对自己的宇宙进行观察后，发现了一个伟大的定律：“宇宙每隔十厘米，必然会有一个洞。”它们把这个神枪手一时兴起的随意行为，看成了自己宇宙中的铁律。

当你在更高的维度去回看低维度下自己纠结的问题，你会发现那都不是问题。

举一个很有意思的案例。引用和君商学院产业大课里的内容：

沿着人均GDP的轨迹寻找产业机会：

• 汽车：1000美元时汽车开始进入家庭；3000美元时私人购车爆炸式增长
• 旅游：1000美元时观光游剧增；2000美元时休闲游骤升；3000美元时度假游渐旺；6000美元时进入休闲游时代
• 酒类：2000美元以下（主要是烈性酒）；3000~4000美元（啤酒消费陡峭上扬）；5000美元（红酒啤酒交辉相映）
• 教育：300美元（教育经费所占比重不应低于3.299％）；800美元～1000美元（教育经费所占比重的下限为4.06％-4.24％）；当人均GDP达到4000美元左右时，教育会成为居民消费的重点
• 医疗保健：1000美元时补钙需求骤增；5000~6000美元医疗卫生成为消费增长点；7000美元时保健品支出增加。

——王明夫，和君商学院产业大课

看国家/地区的人均GDP轨迹和产业的关系，结和行业发展曲线——萌芽期、成长期、成熟期、衰退期，你更容易在更高的维度来决策，而非一门心思在低维度的细节中拼杀。当然我这里只是举个例子，谈笑风声而已，真正要做好，路很长，难得很。

1.1 行业研究

行业研究并非新鲜事物，有很多成熟的模型，比如波特五力分析模型、和君的SMART产业分析模型，还有万能的SWOT模型等等。关于行业研究的方法，找时间专门写一篇，或者大家也可以去看专业的文章和课程，这里不过多讲解。上图中的行业下面的节点，是我较为关注的维度。还是那句话，适合我的。

1.2 阅读行业研究报告

除了自己做行业研究，阅读第三方发布的行业研究报告，是快速认识行业的好办法。

很多行业研究机构会定期发布各行各业的研究报告，比如艾瑞咨询、易观国际、亿欧智库等，适合在初期快速认识行业。不足的是，由于这些机构涉猎的行业很多，很多行业并非他们深度参与，因此是以旁观者的身份、从宏观角度、采用传统框架方法、结合公开半公开的数据或者简单的调研样本数据，得出的研究结果，基本上算是停留在桌面研究阶段，深度不是很够，但也足够让人快速认识行业。

另一个获取途径是，很多行业内的巨头、领头羊也会发布本行业内研究报告。比如团餐行业的禧云国际，他们拥有场内玩家的身份，对行业的接触更深入，可以通过对场内玩家的深度访谈，以及披露数据的方式，挖掘整理更具深度的行业认识。

1.3 用脚步丈量中国商业大地

研究报告大都偏宏观，在微观层面，还应该多与行业从业者接触、交流。行业内的创业者、从业者、客户、供应商、投资人、监管者、税务等等，他们都是可以给你关键信息的人。我自己很深的体会是，他们的表现往往和宏观认识的有不同，最开始你会对他们的表现嗤之以鼻，你希望通过对行业的宏观认识，来“降维”打击他们，但是最终发现他们的表现才是最真实的行业反映。另外他们会告诉你一些上不得台面的灰色细节，这些细节恰恰是组成这个行业的不可缺少的一部分，而它们不会被披露在行业研究报告里。

除此以外，还有大量的行业认识需要通过亲身“踩坑”才能获得，你干过就是干过，没干过就是没干过，装不来的。

2.认识企业

B端产品用户客户分离的特点，导致了你必须去认识企业——他们是你的客户，否则你的产品就很难卖出去。

在过去一年的项目进程中，我发现实际上我们没有明确的去区分客户和用户，虽然在概念上我很清楚他们不一样，但是在很多真实的讨论、决策场景中，在潜意识里面，我们是将二者混为一谈了。

3.认识用户

用户研究的首要目的是帮助企业定义产品的目标用户群、明确、细化产品概念，并通过对用户的任务操作特性、知觉特征、认知心理特征的研究，使用户的实际需求成为产品设计的导向，使您的产品更符合用户的习惯、经验和期待。

对用户的研究以产生用户画像，帮助产品设计落地和运营增长。

研究对象包括个体对象和组织对象。C端产品研究个体对象，B端产品则是要研究个体对象和组织对象。互联网公司内设的用户岗位一般是对C端产品的，网上流传的较多的用研的理论方法也大多是对C端产品的。

3.1 个体对象

同样是研究个体对象，B端产品和C端产品的侧重点也不相同。关于C端的用研，可以找到大量的文章和课程，不多赘述。重点讲讲B端产品的个人用户研究。

3.1.1 研究方法

• C端产品的用研，一说就是各种数据分析、焦点小组、问卷、可用性测试等等。
• B端产品的用研没那么复杂，访谈、实际观察、轮岗。尽量投入更多的时间去企业中驻场调研。

3.1.2 用户画像

个体对象用户研究的关键输出物是“用户画像”。C端产品的典型用户画像如下图，包含了基本信息、标签、痛点和需求等角度的信息。

B端用户画像有很大不同，这里会通过一个典型的B端用户画像案例来进行说明，它是从我的真实项目中摘出来的。说实话它并不是在项目最开始就产生了，而是在我们踩坑的过程中，学习、总结出来的。画像的框架包含基本信息、岗位角色、能力素质、工作内容、工作感受等项目，每个项目下面又设有多个要素（具体要素见案例）。

（两个孩子的妈妈，爸爸比较忙，在家庭中负责孩子教育等事项） | | | 地域 | 城乡结合部（农村青年随家庭到城市打拼，长期从事时间自由度比较高的职业，比较能吃苦） | | | 学历 | 中专 | | 岗位角色 | 岗位名称1 | 学生餐业务经理 | | | 岗位介绍1 | 负责市场开拓（包括获客、投标、签单）、客户关系维护、业务数据核对、收费业务、退款业务、客服业务、管理校服人员等工作。 | | | 岗位名称2 | 教师餐业务经理 | | | 岗位介绍2 | 略 | | | 职业收入 | 8W-15W（职业收入由基本工资+岗位绩效构成） | | | 组织结构 | 所在的组织节点，上下级汇报对象，见组织结构图 | | | 工作中的协作关系 |
- 财务出纳：1.核对业务数据，协助财务收入支出
- 仓库管理员：1.给库管提交业务数据，由库管进行采购、出入库，2.由库管向厨房下单
| | | 具备的权限 | 负责A学校，B学校，C学校的学生餐业务 | | 能力/素质 | 互联网背景 | 思维层面对互联网缺乏认知，对互联网的价值缺乏认同，学习意愿不强，能力层面对互联网产品基本没有操作能力。 | | | 专业能力 |
- 办公电脑使用能力很弱，具备初级的word、excel、ppt能力，能使用基础功能做出基本的文档；能使用浏览器上网，但是对于过程中产生的没见过的问题，几乎没有能力解决。
- 沟通能力比较强，同理心比较强，策略思维一般。
| | | 专业背景 |
- 在校过程中无专业，有过一段时间的自主创业（小生意）经历
- 15年工作经验，在本公司不到4年，一直在业务岗位
| | 工作内容 | 工作目标 |
- 达成更多的客户，赚取更多的钱
- 对工作的自由性比较看重
- 对公司关怀、工作氛围融洽度、技能成长性等高阶职场需求不足
| | | 工作描述 |
- 年度：接触市场，搜集市场信息，寻找潜在的学校及其他团餐客户，跟踪销售线索，参与招投标工作事项，维护客户关系等
- 月度：定期维护学校关系，联系学校协调“收费、退费、数据核算”等工作，选聘管理校餐服务人员，解决客诉问题等；
- 日常：
—在每日生产前，通过各种渠道接收到的请假信息，确定请假数据，给到生产部门。（生产部门会根据每月的订餐人数结合当日请假数据，得出具体生产数额）
—略
| | | 使用工具 |
- 日常使用手机作为工作中联络的主要的工具
- 大部分工作需要线下实地处理或者通过电话微信处理
- 小部分工作会使用纸质的表单进行
- 几乎不使用电脑处理工作（除了投标做PPT，给客户做数据统计表格）
| | 工作感受 | 工作需求与痛点 |
- 获客环节：希望第一时间获得市场商机，有稳定的客情关系网络，能够获得更多市场份额和机会，惧怕失去客户；
- 内部协同：希望公司生产环节安全营养卫生达标，财务人员能够正常的结算申报的各项款项；
- 收退费环节：希望有一个简单好用的工具，能够有效的和学校、家长完成收退费协同，减少直面学校、家长的频次，各种数据可以自动准确汇集，快速共享给协同人；
- 服务环节：怕麻烦，希望信息有限共享，不愿意接受家长反馈，惧怕12345，惧怕超过餐企能力处理范围内的敏感信息传播，不愿意通过微信群组解决家长问题。
| | | 其他感受 | 对工作和服务流程缺乏主动规划的意愿，服务改变对来自客户倒逼 |

相信大多数内容通过案例，都很容易理解。挑几个重点内容说一下：

专业能力
描绘用户所具备的各种专业能力，如果做专业的细分领域比如财务、医疗器械等，需要细致的描绘用户所具备的细分专业知识。在我的案例中，则省略了这一块细分专业知识，重点描述了用户的电脑使用能力，因为我们的产品形态是web产品和移动端产品。而在这个案例中，基于描述其实可以做出几个预测：

• 产品上线后，前期用户对你的产品的认识会很不到位，这个产品在他的已有认知里很难找到对应。
• 产品功能必须足够简单易用，但即使够简单，他可能也不会。所以负面情绪很容易被激发。
• 运营和客服的压力会很大，该部门的成就感会受到挑战。
• 基于惯例，你对产品形态的第一想法可能是web产品，但是这一次可能移动端可适合。

具备的权限
通过事项、区域、级别三个维度还描述权限，但是注意，画像里的描述不能作为产品最终落地时的权限描述，要结合最终的产品设计，形成最终的角色、权限、页面、元素、数据的关系表。在这个案例中，用户的组织关系和协作没有那么细致，因此写的比较简单，仅仅能通过描述提现角色和数据权限的关系，功能（页面/元素）权限和角色的关系没有很详细的描述。

工作描述
尽可能的穷尽用户的工作内容，且尽量细致的描述。这对于后面确定产品范围、组织产品功能至关重要。关于工作描述的方法，我会用到一个标准句式，这个句式同样适用于做需求管理时，进行需求描述：
工作描述=在 {什么情景下（通常为时间、地点、条件）}，{什么人} 需要做 {什么操作}，达成 {什么结果}。

工作需求和痛点
PM认为应当是最重要的事情来了，确实也很重要。但是，大家之前最关注的这部分，反而没什么好些的。通过访谈以及运营中的实际感受，会形成并完善这部分。

小结
用户画像确实很重要，无论对宏观层面的产品定位，中观层面的功能范围，还是微观层面的功能设计，都会带来贡献。同时画像并不只是在产品初期的调研中产生，像迭代一样，需求会随时产生，画像也要随时更新。

3.2 组织对象

组织结构
我以一张组织结构图，来描绘企业的组织结构关系，目的是让团队读懂这家企业的组织关系。组织结构图的画法不重要，重要的是把握其中的关键要素，能在几个关键点上将企业组织描述清楚：1.纵向层级；2.横向关系；3.特殊的汇报关系；4.各节点的职能；5.各节点的权限。

• 纵向层级：代表汇报关系，同时也代表业务职能的继承关系。
• 横向关系：代表了不同的业务职能，横向节点的职能之和大约是上一级节点的职能。
• 特殊的汇报关系：除了纵向实现描述业务关系之外，现在中很多公司也有交叉汇报的情况，比如IT公司的矩阵式组织等。通过一条虚线描绘虚线汇报关系。
• 各节点的职能：描述各节点的职能，可以以备注等形式进行。
• 各节点的权限：权限主要体现在事项、区域、层级上。比如图中校餐业务经理1，在组织中他下面的节点应该是校服人员（N个），但是为了表现出区域关系，我加了一级学校。意味着校餐业务经理1负责学校1和学校2的业务，学校1会设置N个校服人员，学校2会设置N个校服人员，校餐经理2是无法干涉学校1的业务，也无法管理学校1的校服人员。可以以备注等形式进行。

延伸一点，做B端产品，特别是做SaaS产品，考验的是你能否以标准产品满足行业内大量的、不同的企业，要能覆盖他们的大多数需求，因此在前期组织架构的调研中，要尽量多的面多不同的企业，描述他们的组织形态，抽象提炼出组织模型，这对后面的事的认识（业务设计）至关重要。

4.认识事

4.1 建模——面向对象

前面对于B端产品，事很重要。认识事最好的方式是建模。

这一部分主要将面向对象建模的思路和方法。一提到面向对象，很多人开始不自主的产生抵触心理，认为那是开发的知识领域，其实不然。对象是对客观世界中事物的抽象，通过将客观世界中的事物抽象成模型实体，描述实体之间的关系，描述清楚他们各自的状态变化情况，以及产生变化所需的行为和条件，就可以像庖丁解牛一样将“业务”分解并描绘清楚。

面向对象的另一面可以说是“面向过程”，听名字好像很陌生，然而实际上我们大多数人所熟悉的认识、描述事物的方法都是面向过程的，比如，PM最常见的调研操作是画流程图，包括复杂一点的阶段流程图或者泳道图，都是面对过程的方法。个人感觉面向过程的描绘，很容易陷入“粒度的选择难题”，即我是否需要在流程图汇总描绘出每一个细节。

掌握面向对象的方法，可以：

1. 通过更科学的方法，完整深入的认识事物、业务；
2. 通过图形、文档更清楚的表达调研结果和设计结果；
3. 更容易与研发伙伴同频交流。

既然面向对象很重要，那么每个PM都应该学习UML的建模方法，学习通过面向对象的思路和方法来模拟你要认识的真实世界。至于UML建模方法的细节，大家可以自行研究，很成熟了。

4.2 建模方法

如何建模？你只需要把握两块：1.实体对象；2.业务逻辑。下图表述了你需要通过什么样的结构框架来建模。

4.2.1 实体对象

包括实体和实体关系。实体包括属性信息、状态与操作、状态机；实体关系包括依赖、聚合、包含、关联、实现、泛化。通过对实体对象进行描绘，实际上是解决了上面所写的建模工作的前三步。

实体

• 属性信息。不解释，比如订单这个实体，他的属性信息有订单号、用户姓名、金额、订单内容、状态等等。
• 状态与操作。状态实际是实体属性的其中之一，但是它过于重要，因此单独拿出来。你要做的是穷尽客观实体的所有状态，并明确状态和操作的关系。注意，实体可能有多个与之有关的用户，要穷尽，穷尽！

• 状态机。了解过UML的同学，都一定知道状态机图。他是典型的面向对象思维，节点是实体状态，节点间的连线是操作或者条件。顺便多说一点，为什么说以前画的流程图都是面向过程，因为节点是动作，你的交互越复杂，动作就越多。这也是为什么我上面说到“很容易陷入粒度的选择难题”。下图中是我系统中的实际业务逻辑，做了部分的隐藏，同学们重点关注多实体多状态的协同变化，变化的原因（操作或条件）

实体关系
实体关系包括依赖、聚合、包含、关联、实现、泛化。他可以准确的表述实体之间的关系，重点是数量关系，即1对多，多对1。实体的属性信息和实体关系，可以通过一张ER图来进行表示。

使用实体-联系图(entity-relationship diagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。ER图中包含了实体(即数据对象)、关系和属性等3种基本成分。

4.2.2 业务逻辑

如何描绘业务逻辑？通过以下几点可以比较完整、准确的描绘业务逻辑：操作实体、工作目标、工作发起、工作流程、业务规则、工作结果。

• 操作实体：这个业务所需要操作的实体，注意很多业务都会有一个主实体，这是大家都会重点关注的对象，然而很多业务会伴随着其他实体的变化，这是很多同学常常忽略的地方。
• 工作目标：描述业务的目标。
• 工作发起：描述业务是在什么条件下在哪里发起的。
• 工作流程：描述业务具体的工作流程，可以是面向过程的，注意和状态机进行对应关联。
• 业务规则：描述工作流程推进过程中的具体规则。
• 工作结果：描述工作过程中的结果和输出物，结果可能是多个，输出物也可能是多种。

05 B端产品设计的核心环节——设计

认识了行业，用户和事，接下来就需要将认识转化成产品。如何高效的设计出有效易用的B端产品，我将从5个层面和几个关键点进行简要的阐述。

由于主流的B端产品，以web产品居多，主要的形式为管理系统类。因此本篇关于设计的内容，以web管理系统的设计为目标进行讲述。

相信每个PM都一定读过一本书——J.J.Garrett所著的《用户体验要素》。书中将用户体验分为5层，即战略层、范围层、结构层、框架层和表现层，这5层的分析方法几乎成了PM在谈产品时的基本原理，像圣经一般的存在。我个人虽然对其表述内容的适用性和某些细节有所保留，但对这种分层的框架思路十分认同，因此也尝试将B端产品的设计进行了分层，即自下而上分为：架构层、框架层、功能层、页面层，以及贯穿的权限层。

B端产品设计的5个层次

1. 架构层

简单理解即一张系统架构图或者应用架构图，目的是梳理企业级产品的系统级架构关系，使产品高效支持业务，并且合理、稳定、可复用。

应用架构（Application Architecture）是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次：

• 企业级的应用架构：企业层面的应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。在企业架构中，应用架构是最重要和工作量最大的部分，他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。
• 单个系统的应用架构：在开发或设计单一IT系统时，设计系统的主要模块和功能点，系统技术实现是从前端展示到业务处理逻辑，到后台数据是如何架构的。这方面的工作一般属于项目组，而不是企业架构的范畴，不过各个系统的架构设计需要遵循企业总体应用架构原则。

在这里我们所说的架构即企业级的应用架构，当你的产品有两个以上的明显不同的业务群组或者职能群组时，你就会面临产品架构层面的问题。关于架构的内容建议直接看杨堃的《决胜B端》，或者作者在其他论坛上发布的相关文章，比如《从一个故事说起，谈谈企业应用架构的演变史》，《换个视角，看中台》等。我本人没有更多更好或者更有效的观点进行分享。

图片来自杨堃《决胜B端》，这本书关于企业产品架构有很多详细讲解。

2. 框架层

简单理解，对研发团队来说，即是一张功能结构图；对用户来说，即是功能导航。

功能结构图

功能结构图的目的是梳理系统内的功能关系，可以最直观、快速的掌握功能点的内容、数量和组织关系，是确认功能范围，评估工作量和测试目标的必要输出物。要注意功能结构图和之前大家所说的信息架构图并不一样，他是由多层级的功能（而不是信息、字段）组织形成的结构图，最小粒度应该是用户所能感受到的最小功能，比如导出，导入，删除等功能。

组织功能时，常见的结构层次包括：系统-应用模块-功能页面-子功能。如果是单系统产品，一般为应用模块-功能页面-子功能。以下面这张功能结构图为例，图中是2B产品：运营管理系统-商家管理模块-商家列表页面-创建商家/待审核列表/已通过列表等。

结合思维导图工具的时间标签、数字标签等，可以对功能点标记已实现、本期实现和储备功能点，还可以引申出其他很多功能，重要的是要做好功能结构图的版本管理，对每次版本升级的重要内容做记录。通过processon等工具，可以快速存储云端版本，并管理。

功能导航

功能导航的目的是使用户在使用产品时，更容易找到自己需要的功能和与之相关的功能。常见的功能导航有：水平、垂直、混合型。每种导航的形式有各自的优缺点，网上很容易搜到，不多说。
**
功能导航的设计，要重点关注：

1. 形式的选择
2. 功能的组合
3. 导航的排序
4. 导航的文案

3. 功能层

简单理解即PRD文档中的详细需求设计那部分，这块内容要写的话有大量的篇幅，在此不做过多赘述，有机会整理好思路系统的写一写。

4. 页面层

简单理解即页面内的交互设计与视觉设计，设计内容包括页面的布局、元素（组件）和视觉表现。经过长期的设计和总结，会发现B端产品80%~90%的页面（数据不严谨）不外乎是几种功能明确的页面，比如列表页、表单页（基础表单、分布表单）、详情页、数据可视化页面（数据分析、数据明细、数据监控等）、结果页面（成功、失败）、异常页（空、404等），掌握这些页面的设计方法非常重要。

布局

以列表页为例，页头+数据过滤区+数据统计区+数据展示&操作区+分页区

• 页头：标记页面名称和位置，需要时加返回
• 数据过滤区：通过各种控件筛选查询数据
• 数据统计区：展示当前筛选条件下的数据的统计
• 数据展示&操作区：展示当前筛选条件下的数据和对数据的操作，另外页面级操作比如创建，通常也在这个区域。
• 分页区：不解释。

上图来自see conf

组件

这个层面的设计建议直接使用成熟的前端UI框架，比如早期的bootstrip以及现在最火的antdesign等，这些框架在视角规范和交互规范上都给出了非常优质的方案，完全可以直接使用。我的团队通过对antd框架的交互规范的学习，可以实现团队内部从产品到前端的直接协同。暂不多说，找机会细讲。

使用成熟前端UI框架的好处：

1. 不必重复造轮子。以antd为例，由蚂蚁金服的用户体验设计团队产出，给出了一整套组件，几乎可以覆盖95%的需求。且组件的设计水平极高（几乎是国内顶级水平），交互逻辑高效且被验证过。你要做的就是充分理解自己的业务，明白需要用什么要的组件，如何组合成你要的功能。这样设计也省事，前端也省事。何必自己苦苦钻研组件内的细节呢？当然我承认做组件很有成就感。
2. 容易形成统一的设计规范，并落实应用。当你的产品越来越复杂，你的设计规范无法适应新页面的机会就越大，特别是你去自己造轮子的时候。
3. 省掉设计环节，高效协同支持业务。如果你的团队从产品到前端的伙伴都对框架足够熟悉，完全可以做到从需求到前端的直接对接。

提高效率

如何高效的利用框架元素来表达自己的想法。我是使用axure软件来做这部分的，先简单放置一个视频，表现一下一个页面可以多快地搭建。当然这依赖于个人不断的优化组件库、模块模板、页面模版。有时间再整理一下详细讲讲。

5. 权限层

权限层是贯穿整个B端产品设计的层次。关于权限部分，可以查找RBAC的设计模式，很成熟的设计方法。

关键设计——应用模块管理部分

这部分这要讲讲，如何管理应用模块，使之具有高灵活度、可配置的特点。可以说网上有很多讲关于B端产品设计的文章，但是我个人很少看到有对这部分进行详细讲述的，也造成很多同学对它充满好奇。

待补充。

06 产品价值判断公式

互联网产品前辈俞军的产品用户价值公式：

产品价值=（新体验-旧体验）-替换成本

经过这一年的创业经历，对此有深刻的感受。关于新体验和旧体验，这里没有说新产品和旧产品，因为用户原来可能用的是传统的、线下的方式，也可以满足需求，但是使用新产品后，在效率、易用性等方面的体验会远远超过传统的线下的方式。但是要注意，体验的提升除了是产品带来的，还伴随着用户付出的努力，也就是替换成本，这个常常被产品人所忽略，但又至关重要。

替换成本是指用户为了使用新产品的所需付出的时间成本、学习成本、金钱成本等。

• 金钱成本：如果新的产品通过技术升级等原因带来了更低的价格，那么金钱成本可能是负的。
• 时间成本：也许从长期来看，用户使用新产品后效率提升带来时间的节省，但是短期内，在替换阶段内产生的时间成本常常也会使用户产生负面情绪。
• 学习成本：如果在替换阶段内，需要用户付出很多的努力来学习产品的使用，那么用户很容易产生负面情绪。比如我们在做校餐领域时，发现客户的员工的信息化能力和素质极差，虽然我们尽可能的提升产品的易用性，但是你不得不频繁的为他们普及一些基础知识比如浏览器的问题。运营的同事将这件事比作教小学生学习初中的知识。
• 适应成本：即用户在使用老的产品时，长期的使用带来的适应性和舒适性，使用新的产品实际上会让人跳出舒适区。而这种适应性会被组织协同放大N倍。
• 已沉淀的数据等一些列沉默成本：即用户在使用老的产品时，长期产生的大量的数据和已有的配置，如果不能迁移到新产品上来，会给用户带来极大的替换成本，即使能够迁移到新产品上来，同样会使用户付出很大的替换成本。基于以上两点，可以说B端产品的替换成本极大。

本来一直想尝试替换“=”左边的内容，感觉似乎有更合适的目标，但是试了很多都不满意，比如产品成功，用户使用意愿等等。

除了对上面公示的感同身受以外，还对其做了一个延伸，即对于B端产品来说，
产品使用意愿=（新体验-旧体验）-替换成本+X
**
X是指某些组织内存在的强制力量，比如关键人的强势决策。还记得上面写道B端产品的决策机制，带来了产生X的机会。哪怕产品价值是负的，仍然有机会通过这种强制力量，使得产品使用意愿为正。当然这种力量的产生来自于多方面，你懂得。最终还要说这种正向的意愿并不是很靠谱的，本质上想要产品成功，其核心动力还是上面的产品价值。