编辑导语：B端产品设计时确定方向以及找准需求场景很重要，本篇文章作者分享了B端产品设计的具体流程，以及讲述了有关需求场景的内容，感兴趣的一起来看一下，希望对你有帮助。

注：本文所讲的B端产品，主要是指通用型B端产品 ，不涉及定制化开发的B端产品，两种类型的产品设计流程有着本质的差异，通用型B端产品以满足某个群体客户的通用需求为目标。

当我们计划做某个功能时，如何开展设计呢？是确定迭代任务后立刻思考解决方案？还是直接构思功能细节？

需要说明的是：有序的做事和无序的做事在效率和质量上是有很大差别，尤其是对于具有前置依赖特点的环节，若前置动作做不好，返工和走弯路是常事，而这些不必要的成本我们其实是可以避免的。

先说流程，再详细讲解：

1. 找准核心需求场景；
2. 明确此次设计要达到的目标；
3. 为目标达成找到最优方案；
4. 设计功能整体框架；
5. 基于整体框架，完成具体的设计；
6. 明确默认值、补充异常场景；
7. 模拟用户路径，验证功能设计的可行性；

本文主要讲解功能设计流程里的第一个环节：找核心场景。

假如我们要去旅行，那么我们首先要确定的就是方向（要去阳光沙滩还是草原骑马？），以此类比我们的功能设计，找核心需求场景就是明确方向，这是后续所有动作的前置条件。

做事情时，方向一定不能出问题。否则再努力，也是南辕北辙。

一、场景为什么重要

本文中，我们将不断地提及“场景”，场景是什么？为什么我们不直接分析需求，不直接去设计方案，而要在“场景”上投入这么多精力？

通过一个简单案例，了解一下场景的重要性。

案例：一个小超市，来了个客人想要买一些500ml“农夫山泉”，但是此时店里没有500ml的“农夫山泉”。如果不聊具体的场景，我们怎么知道客人是因为口渴了想买水，还是还想些水会议招待，亦或者是只是想给家里屯点水。

在没有具体的场景做支撑时，我们无法判断是该从其他店里调一些500ml“农夫山泉”过来，还是应该给客户推荐500ml的“怡宝”，亦或者350ml或5L的“农夫山泉”，甚至说推荐客户买几块雪糕。

明确了场景，我们才可以避免陷入“基于问题解决问题”的直线思维。

场景很重要：

• 场景是讨论价值和方案的前提，场景没有或者不对，一切休谈；
• 场景是不变的，方案是可变的，我们需要先明确场景，再分析可选方案。
• 场景是把需求从抽象到具象的过程，脱离场景去谈谈需求，是抽象的，每个人的理解可能都会不一样。

二、需求和场景的关系

人们通常会把需求和场景放到一起描述，称其为“需求场景”，然而场景和需求并非是一体的，它们是存在依赖关系的两个对象：

• 场景不是需求，而是需求发生的背景；
• 有需求一定有场景，有场景不一定有需求。

所以，“需求场景”指的是“场景+需求”，对场景和需求关系的理解，将影响我们后续寻找核心需求场景的流程。

通过一个案例，再加深一下理解：

案例：员工小A上班时的可选出行方式有：地铁、开车、骑电动车。这三种出现方式对应的就是三个场景，有些场景下有需求，有些场景下无需求。

1. （有场景有需求）在开车场景下， 小A的需求是期望公司能够提供一个停车场；
2. （有场景有需求）在骑电动车场景下，小A的需求时期望公司可以提供充电桩；
3. （有场景无需求）在坐地铁场景下， 小A没有什么需求；

三、合格需求场景的标准

我们想要找核心需求场景就需要对诸多需求场景进行分析，但是如果我们直接去阅读原始的描述，就像看故事一样，可读性够了，但是条理性不够，可分析性也比较差，并且很难看出这些场景描述里缺少哪些关键信息。

因此，我们需要对原始需求场景的描述进行提炼和整理，便于我们补充关键信息，以及为后续做归类和优先级评估建立良好的基础。

什么是合格的需求场景？

合格的需求场景指的是对客户原始需求场景进行有条理地提炼，合格的需求场景是一个标准，其与需求场景的属性、优先级无关。不管场景是哪一个层级、哪一个类别，其都要尽可能地符合这个标准。

基于以往工作中的沉淀、思考和讨论，我们明确了需求场景是用户发生的完整故事，包括：什么角色、为了达到什么目的、目前使用了什么样的方式、出现了什么问题、想要什么如何解决。

标准格式：

四、寻找核心需求场景

回到本文要解决的问题：做产品时首要步骤就是明确方向，明确方向指的即找到核心需求场景。

1. 什么是核心需求场景

在第一部分，我们提到“需求场景”实际上是场景+需求，而”核心需求场景“就是对场景是否为核心、需求的优先级综合分析得出的结果。

• 场景可以划分成：核心场景、次核心场景、非核心场景。
• 需求可以划分成：高优需求，一般需求，边缘需求。

场景没有优先级之分，但是有核心程度的区别，我们可以基于产品定位、市场价值、安全类场景等维度，评估场景是否为核心；

需求是依赖于场景的，我们评估需求时有一套标准（例如需求频次、阻塞程度、体验提升程度等），而场景是否核心会对需求评估的优先级增加权重。

价值排序：

核心场景的高优需求＞核心场景的一般需求/次核心场景的高优需求＞次核心场景的一般需求＞非核心场景的所有需求/所有场景的边缘需求。

我们理想的核心需求场景就是核心场景下的高优需求。接下来讲一下想要找到核心需求场景，具体可行的动作。

2. 对场景和需求进行归类和分析

流程如下：

1）场景归纳：基于各种渠道的需求，归纳出所有相关的场景；

2）场景分类：对场景划分层次；

3）核心场景评估：评估出核心场景、次核心场景、非核心场景；

4）需求优先级评估：评估出各个场景下的高优需求、一般需求、边缘需求；

如果场景的核心程度已经明确，则可以直接做第四步，如果场景是否核心不够明确（开发新产品、新模块时会不清楚哪些是核心场景），则需要从第一步开始做起，我们需要做到：评估需求时，其对应的场景是否为核心一定要是明确的。

避免错误地把成本投入到非核心场景上，或者在次核心场景上付出过高的成本。

上面提到的动作里，每一个动作其实都可以单独拎出来做单独的方法论总结，但是本文主要是讲整体的流程，所以不展开。

但是要说明的是，我们找核心场景时，有以下几点需要注意：

1）客户描述的需求未必是其内心的根本诉求，并且客户可能会将多个需求掺杂到一起描述，要挖掘客户最根本的诉求是什么，并合理拆分；

• 客户通常都会把想要某个功能当作自己的诉求，但是实际上我们满足客户的诉求可能是用其他方案；
• 举例子：客户想要一瓶”农夫山泉“，有可能我们给一瓶”怡宝“或者给一块”雪糕“也能满足需求，所以要挖根本诉求；

2）梳理时不要引入自己主观推测的需求场景，罗列出的场景要有支撑依据（来源于客户、竞品功能等）；

• 需求场景决定了我们的动作，如果引入主观推测的需求场景，这些推测出来的需求场景和真实的需求场景放在一起考虑，会干扰我们的分析和具体动作。
• 举例子：用户想要对业务指标进行监控通知的功能，如果我们推测可能还会有对系统异常情况进行监控通知的需求，那么我们分析时就需要考虑这一项，甚至可能会错误地把自己推测的需求列到要解决的需求场景里。

3）分析出的核心需求场景存在不够准确的风险，如果觉得判断不准，可以直接找客户沟通或找最接近客户的职能同事进行沟通，验证自己的判断。

• 如果发现判断的有问题，改就是了，通过分析判断+面向客户验证，可以保证大方向很难出错，这一步一定不要想着省事；
• 最终要达到的程度：自己对这个核心场景非常认可，不管谁有疑问，都可以解释清楚。

找核心需求场景方法今天就讲到这里，想要了解在B端产品设计流程中，后续环节的方法，可以关注我，会持续更新。

本文由 @维克先生 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。