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

4 评论 1462 浏览 11 收藏 12 分钟

编辑导语: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协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 在坐地铁场景下, 小A希望公司在地铁站1公里以内;

    回复
    1. 对的,这也是个需求,可能在坐地铁场景下也有其他需求。
      我举例子的目的主要是为了说明:有需求一定会有场景,有场景不一定有需求。

      回复
  2. 准确的场景判断才能明确用户的需求,提供更多元的解决方案和降低风险

    回复
    1. 是的

      回复