B端产品设计 | 如何写好一份详细方案设计？

在B端产品设计阶段我们可以拆分成两个步骤分别是产品策划设计阶段和产品开发设计阶段，在以往的文章中我们讲述了在产品策划阶段我们通过行业调研与分析确定我们产品的灵魂-产品定位，在产品开发阶段我们通过对业务调研与分析去完成产品的骨架设计-产品架构。

接下来我们这篇文章我们围绕产品开发阶段中的详细设计阶段。详细方案设计解决了具体功能是什么样的问题，详细方案设计解决了从业务到技术如何落地的问题，详细方案设计也解决了客户如何操作的问题。产品的定位与产品架构设计分别对应了产品的灵魂与骨架，详细方案设计则对应了产品的血肉，最终产出PRD文档，确保产品落地。

一、详细方案设计的流程

详细方案设计本质是功能模块设计，是距离产品方案落地的最近的一步。

对于从0到1的产品的功能模块设计来说，一般我们可以有两个维度：

第一个是以模块为单位，汇聚该功能模块的功能点，所以模块为单位的设计是一个功能点全集；

第二个是以需求为单位，按照要完成整个需求所需要的功能，再把整个模块串联起来，因此以需求为单位是将不同功能模块的子集或者全集进行聚合。这两者只是不同的聚合方式本质没有特别大的区别。

在进行功能模块设计时的路径可以分为五步，分别是需求的背景及价值分析、多方需求的均衡、解决方案功能模块设计、功能模块的原型及逻辑设计、功能模块间交互设计。

1. 求的背景及价值分析

在进行产品功能模块设计时，核心第一步需要对需求进行筛选分析和价值判断。对需求的提出者/使用者的目标及期望进行分析，不断清晰要做什么，为什么做，给谁做，明确产品的核心价值。

那如何去分析需求的背景及价值，分析需求背景及价值主要考虑清楚几个关键的问题：

1. 这个需求要达成的目标是什么？
2. 这个需求的提出者是谁，使用者是谁，这个需求是个谁做的？
3. 需求的提出者，使用者，对这个需求的期望是什么？
4. 这个需求做了，解决他们什么痛点？
5. 这个需求不做，他们如何处理当前的痛点？
6. 这个需求是在什么条件下提出来的，有哪些依赖条件？

2. 多方需求的均衡

第二步则需要对多方角色提出的需求进行均衡，需要从商业价值和需求的合理性进行判断，判断角色提出的需求是否合理，识别出伪需求进行剔除，并对真需求进行优先级排序，最终明确做哪些功能，先做什么，后做什么，在这个阶段我们对应产出物包含了功能模块设计思路和需求的MVP。

而多方需求的均衡我们主要会从两个维度去考虑一个是企业角度，另一个则是客户的角度，在企业的维度主要考虑需求的商业价值，因为企业是需要赚钱的，而赚钱的方式就是需要去从成就我们的客户，节约我的成本。

成就客户体现在帮助客户解决问题，越是客户需要的问题，在进行过合理性判断之后，越是我需要去做的事情。而节约成本主要是考虑企业的投入产出比，综合考虑产品落地成本、开发成本、实施成本、人力成本、时间成本等等。

当然企业所处的阶段不同对于成就客户和节约成本的考虑点也就不同，有时候为了抢占市场，也是可以做一些投入产出比没那么高的需求，但有时需要考虑落地的成本。这里很大程度会取决于企业所处的局势来决定和判断的。

而客户维度，我们主要考虑客户诉求的合理性。客户的诉求是否合理的，能够给客户带来业绩的提升、效率的提升、成本的降低、管理的便捷，这样的需求我们觉得都是合理的，但是合理并不代表我就应该立马去做，我们还需要考虑这个诉求应该放在哪个模块，而这个模块我们放在哪个阶段去落地。

只有当客户的诉求纳入到实现这个诉求的模块，我们才认为这个诉求是一个需求。所以多方需求的均衡是为了明确做哪些功能，先做什么，后做什么。

在客户角度这里我们还需要深入，因为TOB产品的客户是企业，而企业有不同的角色比如我们按照职能进行划分，有业务人员、管理人员、销售人员、运营人员、财务人员等等。

不同角色对服务该角色的产品诉求都是不一样的，我们设计SaaS产品的时候，需要考虑不同角色的诉求，考虑不同角色所占的角度，在根据这些角度去考虑合理性：

• 业务角度：是否解决了业务痛点、是否遵从业务流程、是否匹配业务职能划分、为业务带来哪些提升；
• 数据角度：沉淀了哪些业务数据、沉淀了哪些主数据；
• 管理角度：客户使用此功能满足的管理诉求。

每家企业都是不一样的，所以观察问题和深入问题的角度都是不一样的，这方面没有百分百的标准，与此同时我们不单单只考虑诉求合理性，我们还需要考虑最佳的实现路径，因为客户不同角色对系统的认知都是不一样的，在调研中我们都知道被调研人往往想一个功能模块能够解决他们的所有问题。

所以产品经理需要考虑一个最佳实现的路径，在考虑最佳实现路径时，需要考虑功能点的划分，到底哪个模块为客户实现比较合适，要考虑功能一旦实现对其他模块或者其他客户角色的影响，要考虑不同角色之间的矛盾点如何调和，要考虑是否有被发现的漏洞。

只有我们产品设计本身需要充分考虑，才能实现真正意义上的需求均衡。

在企业角度我们说过，企业是要赚钱的，我们的产品需要适配更多的客户，我们要尽量节约研发、运营的成本，企业都想快速的把产品推向市场。

所以在产品设计中我们不可能去极致的追求客户满意的，而是在满足企业商业角度基础上去追求客户满意的，解决客户最痛的点，而不是完全满足客户所有的诉求了，如果全设想满足了，那产品也演变成定制化了，所以在产品设计时我们站在企业角度需要去考虑：

培养客户心智：设计是否符合使用心智、是否可以满足保留客户对产品粘性、功能点是否满足客户付费心智、是否可作为向客户收费盈利点；

保持合理的适应性：在客户定制化诉求与产品的抽象能力和扩展性之间寻找平衡点。节约落地成本：是否可以快速落地、研发交付成本是否较低；

但整体均衡时我们优先考虑的是核心痛点的业务闭环，只有产品有了整个基础才会有客户使用，之后我们再考虑落地成本及商业诉求最后在考虑客户满意度。我们再进行需求梳理时，我们可以借助四象限法和kano模型，最后我们产出功能模块的设计思路和MVP版本的功能清单。

3. 解决方案的功能模块设计

第三步对多方需求进行抽象，首先需要拉通多需求方认知，然后基于场景及诉求给出解决方案，最后确定解决方案设计模型所属领域，通过抽象多方需求，我们将产出关键场景的流程图，状态流转图，页面跳转图，核心数据结构。

在第二步我们均衡了多方的诉求，我们输出了功能模块的设计思路和MVP功能清单，知道了我们先做什么后做什么，那么接下来我们根据设计思路和具体的场景结合多需求方的诉求进行产品方案的设计与抽象。

产品方案的抽象是基于具体场景和诉求的，属于战术层面的策略抽象。通俗来讲就是实现方式，是在完成产品背景与价值分析，多方需求均衡之后启动的。

在进行多方需求的抽象时，首先我们需要拉通需求方的认知，明确概念和名称，比如SaaS产品中的租户与客户概念。

在拉通认知之后我们就需要基于场景及诉求给出解决方案了，需要有明确的输入输出边界，之后根据我们的解决方案归属到对应的领域中，核心是该解决方案需要遵循该领域的规则。最终在这个阶段我们产出关键场景的流程图、状态流转图、页面跳转图、核心数据结构图。

4. 功能模块的原型及逻辑设计

第四步则是进行原型及逻辑设计了，这个阶段基本就是把客户如何操作讲述清楚，也就是我们画原型的阶段了，原型设计又涉及到另外一个比较大的知识板块，在这里也不做具体阐述了。

以SaaS产品举例，SaaS产品在原型与逻辑设计中纪要考虑租户角度，也要考虑企业角度，租户的角度要考虑方案的差异性，因为租户业务诉求是多种多样的，哪怕我们抽象了大部分相同的能力，也会有一定的个性化定制在里面，而在企业角度我们需要考虑我们提供的能力或服务具备通用性，租户可以在云平台上完成服务的定制、续订、退订等功能。

5. 功能模块间交互设计

第五步也是最后一步这时候更多考虑的是功能模块间的交互，他包含了对内交互以及对外交互。同时我们也要考虑到多个系统的耦合，既需要通过API提供对外服务，也需要考虑外部系统获取相关信息，多系统间的交互，需要考虑信任机制和全新啊；对内交互需要考虑期抽象能力和扩展能力。

同样我们以SaaS产品跟大家举例，SaaS产品对外交互我们主要考虑我的客户的信息化系统现状，客户肯定不会只使用其中一家的信息化产品，对于企业客户来说他们需要一个能够支撑起管理运营大而全的产品，但这类系统往往是属于企业的PaaS层产品。

但实际现状是现有企业都会存在多个业务系统交互去满足他的业务支撑，所以这类情况SaaS产品既要考虑对外通过API提供服务，也需要考虑从外部系统获取相关信息。所以我们需要考虑多系统之间的交互，需要考虑信任机制和权限；

二、结尾

通过上述五个步骤之后，我们详细设计阶段就基本算完成了百分之八十了，最终我们需要整理输出我们这个阶段需要输出的核心产出物PRD文档。

而如何去写好一份PRD在这里就不拆开讲了，相关性的文章或资料都有很多，PRD并非是完全统一的，可能每家公司写的都不一样，但是PRD核心需要包含的一些信息或内容，在这里跟大家分享一份概要，如下图所示：

本文作者 @张二十三

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！