为什么你总被批评“没有考虑实际场景”?

产品经理只有对场景有了清晰的认识,才能结合场景设计出好的产品。

与其说,产品经理创造产品,不如说,产品经理创造场景。

产品经理,本质上与编剧、小说家没什么区别。我们都在写一个故事,而场景就是故事中的每一个片段。

场景是什么?

场景与需qiú相伴相生,需qiú从来无fǎ拖离于场景存在,而新的需qiú又会创造出新的场景。

简单来说,场景就是“一个画面、一个片段”,描述了谁在什么什么时间什么地点做了什么。但要以产品经理的角度来理解场景是什么,首先要考虑产品经理会在什么时候考虑场景。

在产品经理的工作中围绕场景的思考,我们可以主要分为两个阶段:

  • 观察“客观场景”——我们观察客观X情况,用户在什么样场景下产生了需qiú。
  • 设计“目标场景”——我们设计出新的场景,用户在什么样场景下满足了需qiú。

而我们产品经理在做的事,其实也可以理解为,我们创造一个目标场景,以期替代原有的客观场景,让用户需qiú得以满足,让产品生长。

下面具体来说。

1. 客观场景

要理解什么是客观场景,我们先回到需qiú。

需qiú在最底层,产生于“我们X内部出现的一种不平衡的状态(或是生理的、或是心理的)——而我们每个个人天生倾向回到平衡态”。

那到底是什么导致了这种不平衡的状态出现呢?——这种不平衡的状态其实就是特定用户对特定场景的反应。(同一场景,不同用户的反应可能不同;同一用户,不同场景自然可能不同,所以是特定)。

我们反过来说,就可以理解为“场景是用户需qiú产生的外在条件”,描述了需qiú是如何产生的

这里的所说的场景指的就是“客观场景”,我们分析客观场景,可以更好的理解需qiú,我们会重点关注:旧的解决方案是什么,需qiú是什么、需qiú是怎么产生的、受哪些条件影响、不同条件下会有什么差异,等等。

2. 目标场景

当理解了需qiú之后,产品经理会设想一个虚拟的目标场景,用来替代客观场景,我们期待着用户在这个场景下满足了需qiú。

所以,类似于客观场景,我们可以将目标场景定义为“需qiú实现的外在条件”,描述了需qiú是如何实现的

我们分析目标场景,可以X更好的产品解决方案,我们会重点关注:产品使用的外在条件是什么、以及用户会如何使用我们的产品来解决问题,等等。

这样来思考,我们就会发现,我们要做的重点的事,其实就是去发现和理解这些外在条件有哪些、以及它们都会产生什么影响。

当我们知道了“场景是条件”这个概念后,我们就很容易知道我们为什么需要重视场景了。

抽象来说,因为我们设计产品本质其实是在做逻辑推理,而逻辑推理的本质就是“基于前提条件和正确的推理规则得出有效结论的过程”。若对于前提条件的认知缺失,就有可能影响我们的推理结果——未充分场景(前提条件)的需qiú分析就很有可能有误或不全了。

如何结合场景设计出好产品?

上面说了定义,接下来我们讲方fǎ。但讲方fǎ之前,我们不妨先来看看我们平时出现的问题都是怎样的。

1. 反面教材

(1)HR的“在家办公统计表格”

疫情期间为了统计X同事在家办公时长,HR发来了如下内容。大家可以先自行思考下这个“小产品”存在什么问题。

问题其实显而易见:

这个产品对于“部门负责人”这类用户来说可能是个X。个人填写的表格是竖向的,而部门负责人汇总的表格是横向的——这意味着部门负责人汇总时需要做个横竖的修改、工作量无形中增大了很多。负责人的时间反而是珍贵的,这无疑是对X资源的浪费。

虽说Excel功能强大,有“转置功能”可以进行横竖转换,但且不论用户是否知道这个功能,即便知道,cāo作过程中也多了很多不必要的麻烦。

于是,我帮她用“部门表”稍微调整了一下,作为个人表。

这样“部门负责人”仅仅是从每个表格简单的复制粘贴“工作时长”就好。

出现这个问题的原因就是对于目标场景考虑不够全面。“统计员工时长”这个需qiú的实现需要细分为员工、部门负责人、HR三类用户分别不同的使用场景。

但显然,设计者并没有深入思考部门负责人这类用户是如何解决的。

这是一个X内部的小产品,X是它的核心竞争力,体验可能并不会太大程度影响它是否被使用。

但如果我们是面向市场的,且竞争产品充分,那用户很有可能就跑了。

这是工作中的一个小例子,大家有没有类似的经历和X?可以回想一下生活工作中的情形。不jú限于我们设计的产品,万物皆产品,小到一封邮件、一次需qiú评估会、一封简历、一次面试等等,这些都是我们可以观察的产品对象。

(2)一次不太成功的产品设计

我们X的X是平台模式,X赋能医院医护人员管理能力,获取来到医院的C端用户。

X对于医护人员的观察和调研,我们发现医护人员有“给本院C端用户发送内容”的需qiú。所以我们立即着手为医院设计了一套XX——医生可以X电脑端登录X,编辑出一篇排版精美的内容,然后X给本院的C端用户。

上线后虽然使用率绝对值不高,但是医护人员反馈整体不错,再加上新X要发展,大家又快速投入到新的工作中了。

X反馈有时候并不会很快浮现。随着后来零星听医生提及“这个功能太麻烦”,再加上线下zhēn对医院回访和线上zhēn对已有X的分析,我们发现了问题严重所在:

  • 不少医院的电脑还是只能连接内网,无fǎ登陆我们的X。
  • 很多医护人员年龄偏大,再加上电脑端整体cāo作起来比较复杂,导致医护人员虽然X,但是没有能力做。
  • 不少医院使用这个X功能,X的只是很短的通知,根本不需要太精美的排版。

这时候才深刻意识到之前犯的错,才理解什么叫“到现场去”的重要程度。后来我们zhēn对以上问题,上线了X端快速X的功能、且简化了功能,医院使用率几乎翻倍。

这也是“场景考虑不全面”,其实我们是可以X对场景分析解决其中一部分问题的。

2. 如何结合场景设计出好产品

绝大多数产品同学们设计产品都知道要考虑场景,且会努力去思考,但常常仍被指责“你得考虑实际场景”、或是到产品上线后才事后诸葛亮。——其实大家的问题是“场景考虑不全或考虑错了”。

方fǎ其实是简单而朴素的——尽可能的收集和理解场景信息。大家会觉得,这不是废话吗?是的,X说得多了,就容易觉得是废话。可难点就在于我们能不能将这废话“十年如一曰”地践行。

(1)收集和理解客观场景是第一步

收集信息最直接有效的方fǎ,自然是“到现场去”、“去观察和了解用户”。这点太重要了。

例如,要是你没有在午休时认真观察过同事们千奇百怪的睡姿,你怎么设计出受众广泛、体验优秀的午睡枕?

但可能对于多数产品同学,需qiú的直接来源可能是用户反馈、运营反馈、老板意见等。大家往往没有足够的时间和精力去现场获取到足够清晰、完整的场景信息。但即便如此,哪怕我们去访谈10个用户,也会收获颇多。

收集到信息之后,如何更好的理解场景呢?我们需要做的就是尽可能的描述清晰、完整。

1)例举核心场景(用户行为liú程)

用户达成目标常常需要经过多个liú程——即,一个大场景下可以chāi分成连续的小场景。我们列出所有的场景,这有助于我们足够重视每个环节的体验(先列举我们认识到的最核心的,不断再完善分支)。

比如上文中的统计考勤,我们可以chāi分为以下几个liú程:

2)zhēn对每个场景详细描述

详细描述有助于我们帮我们发现更多信息,这些信息通常可以用来帮我们提升用户体验以及发现一些新的机会。

那具体如何描述每个场景?这不是一个标准X,但我们可以使用以下几个信息来作为线索:

  • 时间
  • 地点
  • 人物
  • X(起因、经过、结果)

当然并不是每个信息都是每次必须考虑的,而且还有更多信息要结合自身产品去发现。

我们还使用上文中提到的统计考勤的案例。我们假设这个事情本次已经按照HR的方fǎ执行,那让我们作为设计者,将其作为“客观场景”来描述,来看看能发现那些对于我们有价值的信息,进行liú程优化(说明一下,这里画了个图是为了方便理解。不用jú限于形式,关键在于完整模拟——用纯X、甚至就是头脑中的快速演练也是可以的):

当我们把每一个环节都理解和描述的足够清楚的时候,我们发现问题是显而易见的。

这个产品的目标用户我们可以理解为“X”,X的需qiú是以尽可能低成本、高效率的方式完成任务。那显然,我们发现了很多低效的情况出现了。

例如:

  • 上文已经提到过的个人填写表格、部门负责人表格不一致——导致部门负责人需要huā费较多时间。
  • 未明确表格收集方式,导致部门负责人、HR在整理阶段都需要关注两个收集来源,不利于核对是否交齐,下载也不方便。
  • 未明确记录时长的类型——到底是纯工作时长还是包hán了午休吃饭时长——这会导致一部分人填写与预期不符合,后续需要打回重做。
  • 发送表格的时候,是否可以HR直接发送通知给全体X员工,没必要让部门负责人做一遍转述。

X详细描述场景,我们很容易地发现了这些问题。

3)完善分支场景

上文我们只是描述出了较为核心的场景,实际我们工作中会发现分支场景也会有很多,这里不详细描述了。去发现更多分支场景的方fǎ,可以X多问自己“还有吗?”来发散思考—— 还有哪些不同的用户?还会发生在什么不同的时间、地点?还有什么不同的X……

(2)设计目标场景

zhēn对发现的问题,我们会很快有一些解决方案(即产品)。但是这些解决方案很可能是不连贯的、不详细的。但很多产品同学就基于这种程度的想fǎ开始设计详细产品了。

我们稍微耐心一点,和客观场景类似,依然进行3个步骤:

  1. 例举核心场景(用户行为liú程)
  2. zhēn对我们这些设想出场景详细描述。
  3. 完善分支场景。

这次我们以一个运营场景为例。

先说明背景, 我们zhēn对B端用户的需qiú,设计了一个新功能。为了达到让用户尽快初次体验的目的(我们认为这个功能很有利于用户对平台的粘性),会X微信X的方式向用户进行X,引导医生使用该功能(功能在微信的X号菜单中)。

运营同学首先给出的方案如下:

X发布X内容,引导医生搜索X号、找到菜单进行使用。

在这个方案下的设计出来的核心场景就是:

找到微信搜索——搜索X号——找到菜单——体验功能。

(篇幅原因,再此不详细描述了。)

但若是基于想让更多用户体验的目的,我们会发现这就还不够好,在用户使用之前就无形增加了很多成本,会打击用户的积极性。

我们完全可以继续优化这个场景:

我们可以将功能页面链接稍作改造、直接X微信X发给医生体验(当然要考虑改造成本,在此项目成本极低)。

这样用户体验功能只需一步——X链接。

我们可以把这个“体验liú程”看做一个产品,我们X对目标场景的思考优化了最终的产品方案,让更多用户进行了体验。

这是简单、但却十分有效的方fǎ。做产品,很多时候需要的就是再用心一点,用心了解你的用户、用心关注他们到底发生了什么。

结语

产品经理,本质上与编剧、小说家没什么区别。我们都在写一个故事,而场景就是故事中的每一个片段。让我们把故事写得更完整些、更动听些吧。

本篇到此结束。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 为什么你总被批评“没有考虑实际场景”? https://www.xiongfawang.com/2347.html

常见问题

相关文章

为什么你总被批评“没有考虑实际场景”?-海报

分享本文封面