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

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

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

先说流程，再详细讲解：

1、找准核心场景；

2、明确此次设计要达到的目标；

3、看行业内的竞品，看公司内的产品；

4、设计功能整体结构；

5、基于整体结构，开展具体的设计；

6、思考默认值、异常场景；

7、模拟用户路径，验证功能设计的可行性。

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

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

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

一、场景为什么重要

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

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

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

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

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

所以，场景很重要：

1、场景是讨论价值和方案的前提，场景没有或者不对，一切休谈；

2、场景是不变的，方案是可变的，我们需要先明确场景，再分析可选方案。

3、场景是把需求从抽象到具象的过程，脱离场景去谈谈需求，是抽象的，每个人的理解可能都会不一样。

二、明确合格场景的标准

场景很重要，但是如果我们直接去阅读原始的场景描述，就像看故事一样，它们可读性够了，但是条理性不够，可分析性也比较差，很难看出这些场景描述里缺少哪些关键信息。

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

什么是合格的场景？

合格的场景指的是对客户原始场景描述进行有条理地提炼，合格的场景是一个标准，其与场景的属性、优先级无关。

不管场景是哪一类，其都要尽可能地符合这个标准，通过对原始需求场景进行提炼，可以让我们更好地做需求场景分析。

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

标准格式如下：

注意，我们常说的“需求场景”，实际上是场景+需求，虽然场景和需求经常放在一起描述，但是我们要明白：场景不是需求。有需求一定有场景，有场景不一定有需求。

对场景和需求关系的理解，将影响我们后续寻找核心场景和核心需求的流程。

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

1、（有场景有需求）在开车场景下， 小A的需求是期望公司能够提供一个停车场；

2、（有场景有需求）在骑电动车场景下，小A的需求时期望公司可以提供充电桩；

3、（有场景无需求）在坐地铁场景下， 小A没有什么需求；

三、寻找核心需求场景

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

1. 什么是核心需求场景

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

场景可以划分成：高优场景、一般场景、边缘场景。

需求可以划分成：高优需求，一般需求，边缘需求。

价值排序：

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

注：通常情况下，我们评估场景的优先级主要是看场景频次，但是实际上场景的优先级不只局限于频次，还会有市场价值的考量、安全类场景权重较高等考量，所以评估场景的重要性时不能只看频次，而要综合考量。

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

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

对于大型的功能，场景和需求可以拆开分析，先分析场景，再分析需求。对于中小型的功能，场景和需求其实可以放在一起分析。

场景和需求的归类分析流程类似，如下：

第一步：按照合格的需求场景标准，对需求场景进行罗列；

第二步：归类；

第三步：优先级评估。

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

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

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

客户通常都会把想要某个功能当作自己的诉求，但是实际上我们满足客户的诉求可能是用其他方案；

举例子：客户想要一瓶”农夫山泉“，有可能我们给一瓶”怡宝“或者给一块”雪糕“也能满足需求，所以要挖根本诉求；

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

需求场景决定了我们的动作，如果引入主观推测的需求场景，这些推测出来的需求场景和真实的需求场景放在一起考虑，会干扰我们的分析和具体动作。

举例子：用户想要对业务指标进行监控通知的功能，如果我们推测可能还会有对系统异常情况进行监控通知的需求，那么我们分析时就需要考虑这一项，甚至可能会错误地把自己推测的需求列到要解决的需求场景里。

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

如果发现判断的有问题，改就是了，通过分析判断+面向客户验证，可以保证大方向很难出错，这一步一定不要想着省事；

最终要达到的程度：自己对这个核心场景非常认可，不管谁有疑问，都可以解释清楚。

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