2023年B端产品小白必备产品设计自查文档

B端产品小白必备产品设计自查文档class="size-fullwp-image-5796870aligncenter"src="/wp-files/2023/04/hmXb4OzTH8gdqBGCOtJu.jpg"alt=""width="900"height="420"/>

作为新手产品小白，当一个业务极其不熟识的项目向你扑面而来的时候，你是否措手不及？

小瑶同学最近刚参加一个成熟行业从0到1的项目，深感不易。

首先，在业务上，我要从了解行业，到了解行业细分领域，了解行业赛道的竞品，目标客户详细业务流程和诉求摸透业务需求和场景并不简单。

其次，在产品上，我要能快速地上手产品设计，需要肯定的方法论流程，习惯性地高效地做出产品设计。

因此，我认为有必要建立一个让自己理性、有规律、有框架地思索产品设计的思路框架，以在又快又好的节奏下开展设计工作，提高工作效率。

后面的正文内容就是我在近期0-1的产品设计工作中渐渐建立起来的B端产品设计思路框架，可以把这份框架及内容变成一个自己的「产品设计自查文档」。

这份文档使用的场景和起到的作用是：

产品设计阶段：根据这个流程规律去思索项目/产品，在平常做0-1的功能设计或产品时，能够起到帮助正确思索、围绕目标做正确的事的作用项目结束阶段：再次帮助自己对项目和产品的理解，回顾对比现在和过去对产品的思索，发觉自己的成长项目汇报/沟通场景：有助于「汇报产品/项目/需求」，让我们在各种「汇报」场景都能如鱼得水。比如和领导老板汇报需求、需求评审、面试叙述项目经受等。不过，这只是它的1.0版本，还需要经过许多迭代，在这里先经过大佬们的检验，期盼伴侣们提出建议~也盼望它至少能带给一些人在产品设计上的关心~

以下是B端产品设计思路模板的结构框架，供伴侣们提前了解。

一、项目背景

项目背景主要阐述我们设想要做什么样的产品以及为什么要做这个项目/产品。目的在于对产品的来龙去脉有更足的把握。

1.产品设想：我们要做什么样的产品？

老板、领导们把任务交给我们，告知我们要做什么，但我们真不肯定已经理解我们要做什么样的产品，或者可能只是听了个会，但是并没有详细描述产品的定位，而这一问题就是为了让作为产品的自己清晰明白的知道产品的定位。

产品的定位，对于ToB产品，包括：

产品方向——行业垂直型？综合泛行业？/小客户？大客户？/工具型产品？管理型产品？平台型产品？/纯SaaS？SaaS+增值服务？客群及对应方案——为什么样的客户供应什么样的服务理清晰这些，接下来就得思索为什么——我们（产品）的目标。

2.目的：我们为什么要做这样的产品？

作为产品小白，老板和领导们打算要做一个产品，但我们并不肯定知道（或者只是以为自己知道）做这个项目的缘由。

为什么要做这个项目/产品，即产品的目标，它打算了我们做产品的方向，是产品设计围绕的核心。

（1）对公司的价值

对公司/部门的价值，是期望这个产品能制造的商业价值，理解了这些，才能知道如何做产品才能给公司/部门制造这样的商业价值。

（2）客户痛点和产品对客户的价值

用户需求是产品存在的根源、基础，没有用户/客户的需求，就不会有产品的存在。

因此产品对客户的价值，无疑是最重要的，产品经理必需对客户业务当前存在的问题、客户痛点、设想产品给客户带去的价值了如指掌、熟记于心。这样在后续推断需求的必要性、重要性及优先级上也有强有力的依据。

把握好客户价值与商业价值的平衡，让两者价值同时最大化，才是在做正确的事。

二、项目指南针

这一部分梳理的是，目前项目的顶层设计、客户的业务模式等如何，整理后在设计产品时能有清楚的指向标，所以取名“项目指南针”。

1.产品规划/蓝图（做法+缘由）

（1）产品范围

产品范围是指当前已经确定的产品掩盖服务的业务范围，打算了产品做什么和不做什么。

假如产品范围是由上级领导确定，我们还要知道这么做的缘由是什么。

（2）产品演进蓝图

演进蓝图是指产品范围要怎么一步步实现，最终要实现的样子是如何。

其用于从0-1的产品或模块，亦可以在做1到N产品前了解产品历史时整理。

如此，我们就能够知道本期产品所处位置，并且对当前开发的项目的产品延展性做出合理要求。

另外，与产品范围的确定一样，假如产品范围是由上级领导确定，我们同样要知道这么做的缘由是什么。

2.产品面对的客户是？目标客户定位是？为什么？客户期望是什么？

用户/客户需求是产品存在的基础，假如连面对的客户/用户是谁都没有搞清晰，就无法透析产品的打法——思索为什么是这类客户，而不是那类客户，这类客户有什么需求未被满意，这类客户为什么可以带来商业价值等。

读懂客户是最基本的功课，也是最难的功课，读不懂客户就设计产品，肯定会在做设计时迟疑，最好的状况也会降低效率。

定位了目标客户，我们还要知道客户对产品的期望是什么。

客户的期望包含三类，第一类是执行层的期望，其次类是管理层的期望，第三类是决策层的期望。先了解这三类客户的期望，然后再结合业务重点问题，在产品的不同阶段满意不同不同的客户期望。

比如执行层关注业务处理效率，管理层关注业务结果和管理效率提升，决策层关注数据报表，通过报表的业务状况供应决策调整支持，这些需求都需要分阶段不同程度地满意：可能最开头业务管理的效率是企业迫切需要解决的问题，那么明显管理层管理效率提升的需求优先级是最高的，据开发资源状况优先满意。

3.定位客户的商业模式、经营策略是什么？

客户的商业模式，是指企业运作的业务链路，以及各个环节的参加方在整个业务链路中所处的位置和各节点参加方之间的交易关系、盈利方式。

再说简洁点，即客户与其上下游之间的连接关系和交易方式——客户是如何赚钱的。

经营策略则是，在其与上下游合作盈利中，核心重点做法是什么。

明白客户是怎么赚钱的，我们才能想方法帮他提高赚钱的效率。另外，了解了商业模式，也才能基于业务流合理的设计产品架构及功能。

4.组织架构

我们对产品范围掩盖的客户业务进行概要的了解，将所涉及的业务中的部门和岗位排列出来，明确企业客户内部组织架构中，部门及部门职责定义、岗位角色及岗位职责定义是什么。

我们还可以对使用系统的部门、岗位和重点部门、岗位做标记，清楚定位其在组织架构中的位置，比如像下面这张图中对组织架构的梳理，将门店运营中心、品牌与市场部、门店拓展中心标星，提示我们理解其在业务运转中是如何与各个部门协作的。

业务是血肉，组织架构则是撑起业务的骨架，没有组织架构里的每一个部门、每个部门的每一个人，业务就不能运转。

只有知道客户的组织架构是如何的，也才能理解整个企业的运作流转。

5.业务概况

业务概况指的是，企业规模、经营状况、战略定位、资源力量等基本信息。比如了解一个公司的产品种类、产品销售量、销售金额、销售产品占比等等。

这个一般都是详细项目确定实施之前去了解，假如是从0到1做标准化产品，也可以针对行业中的客户群体多做几个客户的调研，了解大部分目标客户的状况，或是了解调研SaaS产品的第一个实施交付项目中的客户业务概况。（详细如何了解，结合实际状况即可）

有人可能会问，我们为什么要了解这些看似和产品无关的东西呢？

由于做B端产品，得从管理层、战略层的角度理解业务，了解企业的基本经营状况，才能明白为什么有些企业的流程是这样，而有些企业的流程是那样。我们不仅要懂得它的作业流程，也要懂得为什么企业的作业流程是这样，以打造更贴合客户甚至行业业务进展的产品。

用一种推理的思维去理解，就像我们做C端产品一样，要深度了解用户，对用户的特征、行为都做调研，刻画出用户的真实全貌，围绕「用户故事」做设计，才能做出“让用户为自己尖叫”的产品；B端产品设计同理，我们要深度了解企业，作出企业的「企业故事」，才能做出“让客户为自己尖叫”（客户感到本企业使用产品后变得特别优秀）的产品。

三、业务概要流程

业务概要流程是指客户所需支持的全部业务场景的最简化拆解：主要流程最大化拆解，并对主要流程上的分支流程也进行最大化拆解，直到没有新的业务场景可排列。（类似MECE原则，但不需要细化）同时，从这些流程中拆解出对应所需的功能模块。

为什么作为小白需要梳理【业务概要流程】呢？

1.理解各个模块之间的关系和业务价值

通常来说，我们作为新手，不会接触全部模块的需求以及核心模块的需求，也并不肯定有人清晰的告知你，你要做的模块是怎么来的，为什么要做，跟其他需求有什么关联。项目相关的许多信息我们是不知道的，需要自己花更多的力气去接触和学习。

而思索概要流程的目的在于，在产品设计之前，对要做的产品的模块如何而来做个拆解，以确保自己对各个模块之间的规律、关系链路有深刻理解，这样从上往下看，就知道底层的产品设计如何做。

2.梳理并了解在产品供应支持的业务范围内所需要对接的系统

一般来说客户都有不少已在使用的现有系统，可能涉及系统的对接，因此我们可能需要了解系统处理的业务，从中我们也更能理解客户的业务。

借用王戴明老师举的一个例子来解释一下：给你一个需求，告知你要支持业务员在访问零售店时录入订单并传送至ERP系统发货。

这里面的主要流程是【业务员访问零售店】→【业务员录入订单】→【ERP系统接到订单】→【仓库发货】→【零售店收货】。

而【业务员访问零售店】这个场景需要【门店管理】【客户管理】【业务员管理】模块来支撑，【业务员录入订单】需要【商品管理】【价格管理】模块支撑等等。

由此我们可以梳理出如下形式的业务概要流程图，理解业务流程的同时，理解抽象出的模块是怎么来的，还能了解需要对接的系统在其中的价值、意义。

四、细节业务流程图

细节业务流程是整体业务流程的拆分，是针对整个业务下某一流程的绽开。

对细节业务流程的梳理除了让我们进一步理解业务流程，找出细节业务流程中不解之处，还能让产品设计的流程规律更缜密、完整，避开不必要的规律漏洞（或发觉产品设计中是否有规律缺陷）。

这里就如下图所示，把各个模块的细节业务流程梳理出来即可。

五、功能结构图

依据跨角色和跨阶段的流程图，就能够梳理出所需要的功能结构图，这样也对自己的需求做了结构化处理。（结构图这里就不实例了，太基础）

六、页面流转与需求列表

当功能结构和流程都已梳理完成，可以进入页面流转及详细页面的设计，这时可以同时将一些不确定做不做或者本期是否做的需求列在需求池中，以便后续查询。

当然，我们也可以把确定做的需求列入需求池，在【业务场景】【需求价值】【开发成本】【优先级】等字段做必要的记录。以此要求自己对每个需求都考虑清晰，对其了如指掌，保证每个需求有凭有据，在任何人对需求提出疑问时都有较充分的理由支撑。

对于需求池，这里提一下需求池的含义及其意义和最近工作中渐渐建立的需求池模板。

需求池是需求管理的一个高效的形式，用它记录产品的各种各样的需求，可以高效管理需求。

需求池中的需求，可能是产品功能设计之始的竞品分析、产品思索、用户调研而得，也可能是产品迭代中业务、运营、市场、领导等提的需求特别之多，因此需要常常更新和整理。

需求池的意义在于：

保证每一个需求被记录，不遗忘需求，对每一个需求提出方都能够有交代帮助产品经理对每一个需求进行归类、理性分析（价值、成本、优先级），让需求宽进严出，帮助版本规划让每一个需求都有它的生命周期，有头有尾，能追根溯源，也能看到它的演化，关心产品经理渐渐建立健全产品全貌了解每一个需求的进度，让产品经理对需求了如指掌，让工作更清楚下面是近期工作建立的适用于我工作的需求池模板，用EXCEL建立好表头字段，需要记录需求时，按字段思索、填写，即可。

对于页面流转，可以通过【功能】【角色】【场景】的方式来梳理，不简单遗漏规律。最终可将这些页面汇总至一个表，供开发了解，一目了然。

当然，假如已经熟识B端设计工作，其实在脑子里也能想好应当有哪些页面，直接列出来就好了。

但话说回来，这一步骤主要在于穷尽用户使用功能的场景，这样我们就能在做页面详细设计的时候，思索每一个需求的成本和价值，将每一个详细需求（元素、规律等）都设计到位。

以某公司课程培训功能为例设计页面流转，参考如下：

1.页面流转图

功能：课程培训

角色1：企业

场景1：创建、编辑和发布课程

场景2：

场景3：

场景n：

角色2：员工

场景1：

场景2：

场景n：

2.页面汇总表

最终可以将上述流转页面的全部页面汇总到一个表中，页面开发一目了然

七、权限设计

无论是标准化ToB产品还是定制化ToB产品，都会涉及功能/菜单权限、数据权限的设计。

虽然现在多数标准化ToB产品设计都是在自定义角色时添加功能权限，但功能权限可能会预置一套，且需要分析哪些角色要用到哪些功能，详细到增删改的按钮和查询的权限，所以需要提前思索功能/菜单权限如何拆分，数据权限又如何掌握。

下面就分三类权限设计分别介绍下如何梳理权限设计的思路，提高设计效率。

1.功能/菜单权限设计

设计功能/菜单权限时，可根据下面的模板梳理不同角色需要的菜单、页面、操作元素的权限，思索并梳理一般性的角色（标准化产品中的通用角色/定制化产品中的指定角色）需要哪些操作

2.RBAC权限模型

RBAC权限模型是迄今为止最普及的权限设计模型，全写Role-BasedAccessControl，翻译过来即基于角色的访问掌握。

（1）RBAC权限的定义

首先还是要解释一下RBAC权限：每个用户都要被给予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问和操作权限。

一句话概括RBAC权限的作用，当用户基数增大，角色类型增多时，RBAC权限设计能够将具有相同属性（相同权限）的用户安排相同的角色及角色下的权限，提高权限管理员的工作效率。

（2）RBAC权限模型的模式

将RBAC权限设计绽开，它包括RBAC0、RBAC1、RBAC2、RBAC3四种模式。其中RBAC0位核心模型，RBAC1、RBAC2、RBAC3都为建立在RBAC0上的扩展模式。

这里简洁介绍一下四种模式，主要依据业务需要选择合适的模型来思索设计，详细就不再绽开，网上有许多资料详细讲解该模型：

RBAC0模型：在最核心的模型中，用户和角色是多对多的关系，角色和权限也是多对多的关系

RBAC1模型：RBAC1模型引入角色继承的概念，即子角色可以继承父角色的权限。

如下图，在某个大部门中，规定总监的权限不能超过总经理的权限，部门主管的权限不能超过总监，若采纳RBAC0模型，权限安排失误时，将消失总监拥有总经理没有的权限，RBAC1模型则能够解决这个问题：创建总经理角色并配置权限后，总监角色继承总经理角色的权限，并可支持在总经理拥有的权限上删除权限。

RBAC2模型：RBAC2基于RBAC0增加了角色的约束掌握，主要包括：

角色互斥：同一用户只能安排到一组互斥角色集合中的其中一个角色。该约束掌握运用于责任分别的场景。基数约束：指一个角色关联的用户数量/一个用户可关联的角色数量/一个角色对应的访问权限数量受限制先决条件：指想要有某个上级角色的权限，需要先拥有下一级的角色的权限RBAC3模型：统一模型，RBAC0、RBAC1和RBAC2模型的整合详细的RBAC权限设计思路可参考纷享销客、销售易，现成的产品体验，成熟、浩大的系统，易用性强，亲自实操记得更牢，这里就不再赘述~

3.数据权限设计

定义：角色在页面中能看到的数据范围（数据集合）。比如针对某个列表页，能看到的是某个区域下的数据，也可能是某个账户下或某几个账户下的数据。

实现方案：

（1）方案一

通过组织机构树掌握：当前节点能够看到其子节点下的数据。该方案实现方式较简单，但敏捷性强。如下图，各个账号分别对应能看到的数据范围由他所在的组织机构位置及其他额外数据掌握（如限制某一账号只能查看当前节点）打算

图源：《决胜B端》

这种通过组织机构树来设计数据权限的方式，表现在原型设计上，通常为如下所示。在角色权限配置中，可配置该角色的权限为【本人】【本人及下属】【本部门】【本部门及下级部门】和【全部】

（2）方案二

通过客户地区掌握：依据该账号所在区域推断，方式简洁，简单实现，但敏捷性差

八、报表设计指南

报表设计涉及到客户管理层、决策层对业务管理工作的分析，报表功能往往打算了企业对产品的评价，打算企业是否付费，是特别重要的留存功能。

其次，假如是SaaS产品，不同行业、不同公司都可能会有不一样的指标，因此考虑哪些可以纳入通用指标需求，难度较大。所以需要有一个指南来带着自己思索，以免头大的同时，让自己对思索流程越来越熟识，达到熟能生巧的水平。

由于在0-1的设计中，我并没有参加报表模块的设计，因此也只是在阅读了相关资料后，整理“假如我来设计报表，我会如何设计”的思路思索，仅供参考共享。

1.设计核心

从角色用户使用报表和分析问题的角度考虑问题

2.设计思路

（1）业务体系构建

明确目的：明确报表分析目的，需要监控和分析什么问题，为什么要监控和分析这些问题，他们属于何种业务诉求？→通过一线业务人员、管理层访谈得出建立方法：采纳何种方式、何种指标识别这些问题？→可以通过一线人员总结出的分析框架、思路