【B端产品设计流程01】为设计确定方向:找核心需求场景

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

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

【B端产品设计流程01】为设计确定方向:找核心需求场景

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

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

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

先说流程,再详细讲解:


  1. 找准核心场景;
  2. 明确此次设计要达到的目标;
  3. 看行业内的竞品,看公司内的产品;
  4. 设计功能整体结构;
  5. 基于整体结构,开展具体的设计;
  6. 思考默认值、异常场景;
  7. 模拟用户路径,验证功能设计的可行性。

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

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

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

一、场景为什么重要

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

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

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

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

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

所以,场景很重要:

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

二、明确合格场景的标准

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

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

什么是合格的场景?

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

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

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

标准格式如下:

【B端产品设计流程01】为设计确定方向:找核心需求场景

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

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

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

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

三、寻找核心需求场景

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

1. 什么是核心需求场景

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

  • 场景可以划分成: 高优场景、一般场景、边缘场景。
  • 需求可以划分成: 高优需求,一般需求,边缘需求。

价值排序:

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

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

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

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

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

场景和需求的归类分析流程类似,如下:

  • 第一步:按照合格的需求场景标准,对需求场景进行罗列;
  • 第二步:归类;
  • 第三步:优先级评估。

【B端产品设计流程01】为设计确定方向:找核心需求场景

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

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

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

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

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

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

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

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

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

 

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

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

给作者打赏,鼓励TA抓紧创作!

随意打赏

提交建议
微信扫一扫,分享给好友吧。