B端产品设计方法论

B端产品设计指南
B 端产品设计全过程：产品背景分析、需求梳理理、需求分析、系统建设
产品背景分析需求梳理理+需求分析系统建设
①市场需求⽂文档 ②技术⽅方案
③合同、招标书等
了了解产品背景
确定业务⽬目标
①了了解本公司对该产品的期望 ②了了解客户对该产品的期望与诉求
规划业务范围
①⼤大概的功能范围 ②与其他系统的关系
业务流程分析
组织架构业务流程报表
业务流程图
⽤用例例图
需求的获取与梳理理
理理清业务概念
①⾏行行业专有名词解释 ②业务步骤解释
调研访谈
中⾼高层代表：
对系统的期望、⽬目标； 组织架构图、分管领导； 部⻔门职责说明；
中层代表：
业务流程中具体的业务活动； 每个阶段的产出； 具体报表类型；
操作层⽤用户代表： 具体操作流程；
平常流程中感觉不不畅顺的地⽅方；
原型设计
①系统⽤用例例
②原型设计
③业务报表④设计约束
UI 设计、开发流程
交互原型
需求⽂文档
需求获取需求分析需求验证
需求优先级需求变更更需求跟踪需求 ⼯工程
需求获取
需求分析
需求验证
需求编写
证实
重写
重新评估
更更正/减少误差
第⼀一阶段：产品背景分析
第⼀一阶段需要产品经理理把控产品的概貌，通过产品背景、业务⽬目标以及业务范围三⽅方⾯面的分析，了了解产品的价值，客户为什什么需要这款产品，这款产品主要帮助客户解决了了什什么问题。

搞清楚产品的⽬目标与价值
产品背景待解决的问题系统涉及的关键受众客户⽬目标
产品成功标准产品范围….
产品建设⽬目标
功能需求⾮非功能需求
找出系统的关键受众 列列出他们要解决的问题分析业务，确认问题 寻找产品范围分析业务，确认问题 寻找产品范围
客户调研
针对特性，提出系统⽤用例例 细化功能需求与⾮非功能需求
解决了了客户什什么问题？ 客户为什什么需要这款产品？ 适合什什么类型的客户？ 这个产品涉及到的⽤用户是谁，什什么部⻔门？
这个产品帮助客户达到的⽬目标是 这个产品的范围是什什么？ 这个产品成功标准是什什么？
思考的问题
探索过程
各阶段⽬目标
每个产品都有特定的⽤用户群体，B端产品也不不例例外。

背景分析的第⼀一步，⾸首先我们要搞清楚，产品到底是卖给谁？做C端产品时，我们习惯⽤用“⽤用户故事”帮助我们定义⽤用户类型，做B端产品，同样我们可以⽤用⼀一个“企业故事”帮助我们理理清⽬目标群体的需要。

“⽬目标客群是⼀一家______公司，没有我们产品之前，他们是这样⼯工作的：______
当前的⼯工作⽅方式出现了了______的问题
因此想要借助我们的产品解决______需要，期望达到______的效果。

”
假设我们要做⼀一款⾯面向房产中介的CRM产品：
产品的⽬目标客户是⼆二三线城市、中⼩小型的房产中介公司，没有我们的产品之前，他们主要是采⽤用市⾯面上常⻅见的CRM⼯工具实现客户管理理，但是⽬目前使⽤用的⼯工具没有针对房产中介的流程做适应，导致流程不不规范、有些环节在线上有些环节在线下进⾏行行，数据监管不不到位，业务员管理理混乱等问题，因此想要借助我们的产品规范流程，以达到提升业务质量量、提⾼高标准化效率的⽬目的。

通过这个企业故事，我们可以定位到产品针对什什么⾏行行业、什什么规模的企业，然后明确这类公司的核⼼心诉求，将来在做功能与设计的时候可以围绕着这个核⼼心诉求展开，也是产品不不断更更新迭代的⽅方向。

任何⼀一个B 端产品，⼀一定是在某个特定的阶段满⾜足企业的某种价值。

对于企业来说，业务⽬目标分类图从上往下越来越重要，企业为此付费的意愿越来越⾼高。

⽣生存需要：这个产品关系到公司的⽣生存问题
核⼼心发展需要：这个产品有利利于公司提⾼高核⼼心⽣生产⼒力力与竞争⼒力力
次要发展需要：帮助公司改善⾮非核⼼心领域的⼯工作，或改善核⼼心领域的⼯工作
锦上添花需要：有这个产品更更好，没有也没太⼤大关系
越来越重要
⾏行行业壁垒 越来越⼩小
市⾯面上⼤大部分B 端产品主要是集中在这两种类型
第⼆二阶段：需求梳理理+需求分析
在第⼆二阶段，⾸首先我们要做的事情是挖掘业务需求。

主要任务是梳理理清楚⽬目标客户群体所有的业务类型，为不不同的业务类型划分清晰的界限，并且梳理理出每个业务类型中所有的需求。

也就是需求澄清的过程。

业务流程分析⽤用户与使⽤用场景分析
业务流程（⼀一个团队/部⻔门）
业务活动1 A部⻔门负责
业务活动2 B部⻔门负责
业务活动3 C部⻔门负责
……业务活动1（某岗位a）
步骤1步骤2步骤3…业务活动1（某岗位b）
步骤1步骤2步骤3…
流程有组织级、部⻔门级与岗位级三个层次，其中组织级是指经过抽象、提炼后的业务事件；部⻔门级是指具体每个岗位负责什什么活动，以及这些活动之间的关系。

它是需求分析的主线索，也是流程分析的主要输出；岗位级是指每个业务活动具体的操作步骤，属于需求细节。

获取⽤用户需求
⽤用户故事参与者⽤用例例
=+
⽤用户
后台系统
硬件设备
…
①动词+名词
②有意义的结果
业务⽤用例例业务⽤用例例场景
（约束）
抽象、合并、拆分
系统⽤用例例系统⽤用例例场景
（约束）
意识到的需求
⽆无意识的需求
进⼀一步的需求
冰⼭山模型
意识到的需求
⽆无意识的需求
进⼀一步的需求
业务流程、困难点
业务流程、改进点
产品经理理挖掘
需求分析从流程⼊入⼿手，搞清楚业务活动在平时是如
何开展的，再逐步过渡到存在什什么样的障碍，有什什
么困难等等。

在这个过程中，多问⼏几个为什什么，多
思考客户诉求背后代表的⼼心⾥里里状态与利利益冲突。

业务流程分析
⼀一个企业的核⼼心价值就是对外部客户的诉求进⾏行行处理理，在为客户创造价值的同时，为企业创造价值。

因此由业务事件触发的流程是分析需求时的核⼼心线索。

组织级
层次：宏观视⻆角
受众：⾼高层领导、部⻔门⻓长
特点：按部⻔门梳理理，每个业务活动都是⼀一个流程
部⻔门级
层次：企业脉络
受众：中层经理理、中级管理理层
特点：体现了了部⻔门中的具体岗位，每个活动由⼀一个岗位负责岗位级
层次：操作细节
受众：执⾏行行层、业务员
特点：列列出每个业务活动中详细的业务步骤
流程的三种类型
需求分析的主线索 流程分析的主要输出
业务流程分析就是针对每⼀一项业务事件，分析业务活动的特点，并确定业务活动之间的关系。

在这⼀一步，我们要记录企业⽣生产经营主要 有哪些业务活动，这些业务活动需要接收什什么信息，产⽣生什什么信息，这些信息之间如何流转
跨职责流程图
业务流程分析——
从不不同⻆角度来看⼀一个业务流的时候，可能会有很多不不同的流程。

流程会有⼤大⼩小之分，主流程中可能会有⼦子流程等，因此流程分析是⼀一项
庞⼤大的⼯工程，仅仅通过⽂文字讲流程描述清楚是很困难的，我们需要系统化地分析，因此可以借助“跨职责流程图”帮助我们梳理理脉络。

⻆角⾊色与使⽤用场景分析
⽤用户故事由参与者与⽤用例例构成，梳理理⽤用户故事的关键点在于发现使⽤用系统的⽤用户，了了解并梳理理这些⽤用户如何使⽤用系统，从⽽而达到“以⼈人为本”的需求分析。

我们可以从针对各个业务事件处理理过程的流程图中得到⽤用例例。

⽤用户故事：作为某某参与者，通过某项⾏行行为操作，以便便能够达到特定的⽬目标。

这个业务活动，需要什什么样的参与者？参与者是指在系统之外，这个流程中与系统进⾏行行有意义交互的任何事物。

⽤用例例是指⽤用户在系统中执⾏行行
的⼀一系列列动作，通常⽤用“动词
+名词”的⽅方式表达。

⽤用例例是有⽬目标的，它能够为
参与者带来有意义的结果。

参与者⽤用例例
调单环节
⽤用例例1：
查询房源状态
⽤用例例2：
上交调单资料料
从流程中获得⽤用例例
获取⽤用户需求
和C端场景⼀一样，B端场景中的⽤用户需求也像是⼀一个冰⼭山，有很⼤大⼀一部分信息是埋藏在海海平⾯面之下，这就对需求调研⼯工作带来很⼤大的困扰。

意识到的需求
⽆无意识的需求
进⼀一步的需求冰⼭山模型这是在海海平⾯面以上的需求，通常是⼀一些困扰⽤用户的问题，或者是⽤用户⾃自⼰己能想到的功能。

⼤大部分产品经理理在调研过程中获取到的都是这⼀一类需求；
它是⽤用户在实际⼯工作场景中“没有意识到是问题”的问题，这种问题需要产品经理理对业务有⼀一定的理理解才能够发现。

如果对这些场景能做到“感同身受”的话，相信在产品规划的过程中能够设计出更更合理理、⾼高效的⽅方案；
调研的⽤用户毕竟不不是技术专家，只是普通的业务⼈人员，因此他们没有办法对其⼯工作提出产⽣生变⾰革的解决⽅方案。

因此需要产品经理理对问题充分理理解的前提下，选择合适的实现⽅方式以创造出⽤用户未想到的功能；
业务分类，需求梳理理的⽅方法
在整个业务分类、需求梳理理的⼤大环节中，业务流程分析、⻆角⾊色与使⽤用场景分析、以及获取⽤用户需求都是伴随着⽤用户调研进⾏行行的。

⽤用户调研是⼀一个有计划、循序渐进的过程。

具体来说，在针对不不⽤用的访谈对象时，访谈的要点也不不尽相同，
访谈对象计划要点说明
⾼高层管理理⼈人员中层管理理⼈人员
操作层
技术⼈人员/IT部⻔门 1.罗列列出部分问题/机会点
2.准备相关系统的实施经验案例例
3.列列举⼀一些潜在解决⽅方案
1.罗列列出相关业务事件列列表
2.收集与特定业务事件相关的资料料
3.准备⼀一些业务事件的关键问题点
4.准备⼀一些相关的管理理控制点
确认现在企业存在的问题，经营需要，探讨潜在的机会点
确认每个业务事件的流程，相关参与者、事件、报表
1.罗列列出相关业务活动
2.业务活动的问题点、需求点
3.罗列列相关业务规则，数据
从业务现状、功能、数据、⾮非功能、⽤用户环境等⽅方⾯面提问
1.罗列列现在遇到的问题
2.整理理出预想的解决⽅方案
针对现在遇到的问题逐⼀一分析，结合问题探讨解决⽅方案
完善⽤用例例
本阶段的任务是对⽤用例例的细节进⾏行行填充。

上⼀一阶段的⽤用户故事已经说明业务怎么执⾏行行，但缺少表达如何“实现”的机制。

⽤用例例1：查询房源状态
需求1：业务员需要看到房源⽬目前的接触情况
以及接下来的客户安排
①将⽤用例例与需求相对应
⽤用例例1事件流：
(1).获取⽤用户的访问权限；
(2).展示房源的接触情况与⽇日程； (3).
提供可选择的看房时间；
②补充⽤用例例的事件流
前置条件：
经理理审核通过后，业务员才可以查询房源状态；
后置条件：
业务员选择看房⽇日期后需要
锁定已选择的⽇日期；
③补充前置条件
与后置条件
④补充规则与约
束条件
规则：
只有开放的⽇日期可以选择看房时间；
⽤用例例与系统需求对应
将⽤用户调研阶段获取到的⽤用户原始需求整理理到相应的⽤用例例中，以此建⽴立⽤用户原始需求与软件需求（⽤用例例）之间的映射。

需求ID⽤用户需求描述来源⽤用例例ID⽤用例例名称⽤用例例说明
前三列列描述了了⽤用户原始需求的编号、描述与提出者，接下来两列列则是相应的⽤用例例编号及⽤用例例名称。

这些⽤用户的原始需求来源于⽤用户调研、⽤用户提供的需求说明以及在使⽤用系统过程中获得的反馈。

需求整理理与分析
需求分析是需求⼯工程中最重要的活动之⼀一。

需求分析并不不是在分析系统如何实现⽤用户的需求，⽽而是选择⼀一种业务导向的指引将零散的需求串串联起来，形成⼀一个体系完整、内容清晰的框架，为下⼀一阶段的产品设计⼯工作做准备。

产品
系统级职责级事业群2
事业群3
…
部⻔门级
岗位级
……
业务事件1
报表1
报表2
事业群1
业务步骤1业务步骤2
功能点1功能点2
业务事件2
通过需求整理理与消除⽭矛盾，获得完整的系统需求列列表，并设计对应的功能点满⾜足需求；
①将需求列列表按照职责、部⻔门、岗位整理理归纳；
②消除需求列列表中⽭矛盾的需求；
完成这⼀一步后，才算是将整个产品的系统需求全部整理理出来。

以后每次迭代就是在业务需求与⽤用户需求的基础上，创建新的系统需求，不不断完善、丰富产品。

第三阶段：系统建设
在规划产品原型的过程中，产品的信息架构设计是重要⼀一环，其中菜单结构设计、CRUD原则与RBAC模型的应⽤用，可以帮助我们设计出更更合理理、⾼高效的产品形态。

菜单结构设计以“⼈人/物”为主线：⼤大部分的通⽤用型B端产品由于各⾏行行各业的垂直差异性，⽆无法做到统⼀一的流程管理理，⽽而产品需要满⾜足尽可能多的⾏行行业，因此只能以“物”为主线划分菜单结构。

以“事”为主线：以业务流程的职责划分为菜单划分的标准，也就是以“事”为主线的设计⽅方式。

CRUD原则CRUD原则对于系统创造的东⻄西才适⽤用，例例如管理理系统⽤用户、管理理数据字典、管理理权限这类的东⻄西就适⽤用该原则。

RBAC模型每个⽤用户都要被赋予⼀一个或多个系统⻆角⾊色，每个系统⻆角⾊色都对应⼀一个明确的权限集合，包括对菜单、⻚页⾯面元素等资源的访问与操作权限。

建⽴立⼀一个“⽤用户——⻆角⾊色——权限”之间的对应关系。