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

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

作为一名产品小白，初次接触不熟悉的业务时，该怎样快速投入有效的工作中？本文作者整理了一个B端产品设计思路框架，帮助产品新人建立一个让自己理性、有逻辑、有框架地思考产品设计的思路，以便更好地进入工作节奏，希望这份“产品自查文档”能对初入产品的你有所帮助。

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

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

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

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

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

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

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

1. 产品设计阶段：按照这个流程逻辑去思考项目/产品，在平常做0-1的功能设计或产品时，能够起到辅助正确思考、围绕目标做正确的事的作用
2. 项目结束阶段：再次辅助自己对项目和产品的理解，回顾对比现在和过去对产品的思考，发现自己的成长
3. 项目汇报/沟通场景：有助于「汇报产品/项目/需求」，让我们在各种「汇报」场景都能如鱼得水。比如和领导老板汇报需求、需求评审、面试讲述项目经历等。

不过，这只是它的1.0版本，还需要经过很多迭代，在这里先经过大佬们的检验，期待朋友们提出建议~也希望它至少能带给一些人在产品设计上的帮助~

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

一、项目背景

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

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

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

产品的定位，对于To B产品，包括：

1. 产品方向——行业垂直型？综合泛行业？/小客户？大客户？/工具型产品？管理型产品？平台型产品？/纯SaaS？SaaS+增值服务？
2. 客群及对应方案——为什么样的客户提供什么样的服务

理清楚这些，接下来就得思考为什么——我们（产品）的目标。

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系统接到订单】→【仓库发货】→【零售店收货】。

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

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

四、细节业务流程图

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

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

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

五、功能结构图

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

六、页面流转与需求列表

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

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

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

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

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

需求池的意义在于：

1. 保证每一个需求被记录，不遗忘需求，对每一个需求提出方都能够有交代
2. 辅助产品经理对每一个需求进行归类、理性分析（价值、成本、优先级），让需求宽进严出，协助版本规划
3. 让每一个需求都有它的生命周期，有头有尾，能追根溯源，也能看到它的演变，帮助产品经理逐渐建立健全产品全貌
4. 了解每一个需求的进度，让产品经理对需求了如指掌，让工作更清晰

下面是近期工作建立的适用于我工作的需求池模板，用EXCEL建立好表头字段，需要记录需求时，按字段思考、填写，即可。

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

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

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

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

1. 页面流转图

功能：课程培训

角色1：企业

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

场景2：

场景3：

场景n：…

角色2：员工

场景1：…

场景2：…

场景n：…

2. 页面汇总表

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

七、权限设计

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

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

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

1. 功能/菜单权限设计

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

2. RBAC权限模型

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

（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增加了角色的约束控制，主要包括：

1. 角色互斥：同一用户只能分配到一组互斥角色集合中的其中一个角色。该约束控制运用于责任分离的场景。
2. 基数约束：指一个角色关联的用户数量/一个用户可关联的角色数量/一个角色对应的访问权限数量受限制
3. 先决条件：指想要有某个上级角色的权限，需要先拥有下一级的角色的权限

RBAC3模型：统一模型，RBAC0、RBAC1和RBAC2模型的整合具体的RBAC权限设计思路可参考纷享销客、销售易，现成的产品体验，成熟、庞大的系统，易用性强，亲自实操记得更牢，这里就不再赘述~

3. 数据权限设计

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

实现方案：

（1）方案一

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

图源：《决胜B端》

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

（2）方案二

通过客户地区控制：根据该账号所在区域判断，方式简单，容易实现，但灵活性差

八、报表设计指南

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

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

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

1. 设计核心

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

2. 设计思路

（1）业务体系构建

1. 明确目的：明确报表分析目的，需要监控和分析什么问题，为什么要监控和分析这些问题，他们属于何种业务诉求？→通过一线业务人员、管理层访谈得出
2. 建立方法：采用何种方式、何种指标识别这些问题？→可以通过一线人员总结出的分析框架、思路分析、参考得出（或者已经有明确指标那就最好了）

（2）指标设计

这一步设计具有明确业务含义的指标，先设计大的指标，然后再考虑是否拆分成更小的指标，以便能从更精细的角度全面、深度衡量结果。粗细拆分的必要性主要取决于行业业务复杂度、公司业务成熟度、产品所处阶段等。

（3）设计呈现形式

呈现形式设计核心：考虑每种指标用哪种形式能够让用户最快速、准确地掌握指标信息柱形图？折线图？环形图？只需要表格呈现数字？

（4）报表交互设计产品参考

作为一个菜鸡小白，我们掌握的报表交互样式大概率少之又少，无论是在产品设计还是平常，都应该多看多积累成熟系统的优秀交互设计，下面是推荐的参考产品和专业文件。

1. 软件产品参考
2. Tableau–学习数据可视化
3. SmartBI/帆软FineReport–学习成熟表样、数据呈现形式
4. 商业文件/报告
5. 《华尔街日报》、上市公司财报

这些财报里面的形式都非常规范、讲究、专业，倘若可以参考这些报表，运用到报表设计当中，则能体现产品经理报表设计的专业性。以上是对报表设计思路的初次思考，它肯定还需要非常多次的迭代，且报表设计较为复杂，如有机会接触报表设计，希望自己积累到一定程度的时候，还能够出一个专题整合，系统讲述一番，分享给大家~

这份产品设计思路模板只是引导我们高效思考的工具，并不是每一点都必须完整思考，在实际工作中我们可能只需要用到其中部分指引辅助思考，或者超出该文档模板思考范围（这个就可能涉及模板的优化迭代了），具体运用还是要根据实际情况灵活变化。但能肯定的是，以上一步步的分析，使得我们可以在每个环节把问题聚焦、分解，对着文档一个个寻找自己对产品、项目梳理的漏洞，专注分析眼前的某一个问题，搞清楚弄明白后，继续专注于下一个问题，实现分阶段各个击破。

全文参考资料

1. 《决胜B端》——杨堃
2. 《SAAS产品经理从菜鸟到专家》——王戴明
3. 《B端产品新人的第一个项目》课程——王戴明