企鹅FM的场景挖掘盛宴

小产编说

在成熟产品的每一句话里，我们都能看出非常多的东西。

今天我们以企鹅FM的断网操作为案例，带你领略一次场景挖掘的全貌。

文/SNG高级产品经理

问题起于此场景：用户A开车时，使用企鹅FM收听节目。途径一长距离隧道，隧道内无数据信号，缓存播放完成后仍然未能驶出隧道。

出于保护流量，避免损耗自动停止播放，同时给出对应的提示，如下：

由于正在开车，用户无法操作。没过多久，开出隧道后，手机信号恢复。但播放状态仍然处在停止状态。

因为用户A无法快速恢复收听。所以APP就这么一直停在这个弹窗处。

这种体验非常闭塞，由于处在驾驶状态中。在意外场景结束时，用户无法便捷且安全地恢复播放。

基于这个常见的背景，一次场景功能挖掘大战开始了。

为了修改这个方案，我们先去找了几家竞品。

对比观察

观察下同类产品在处理网络切换时的处理逻辑。

 1.保守稳妥派：QQ音乐与酷狗音乐的方案

>文案描述：非Wifi网络概述了2G/3G/4G网络以及无网络的情况，确认行为操作使用了“在线试听”的概念。

>qq音乐有回到网络状态时自动回复播放的逻辑。

>wifi网络播放中切换到移动数据网络时给出tips提示，继续播放，提示会消耗流量。

可以看到，在环境中断后，QQ音乐的体验相对较好。

2.前卫派：虾米

>全部网络变化都通过toast提示，不提供可操作选项（断网继续）。

>wifi收听切换到移动数据网络时不会暂停播放，有如上提示。

>播放状态切换到无网络，同样有toast提示。

>播放状态切换到无网络，缓存播放完毕后，直接暂停。

>恢复到wifi后自动播放，恢复到数据网络也自动播放。

可以想象，一个小白用户在虾米里很有可能因流量消耗过猛而卸载此产品。

 3.设置开关派：网易云音乐

>在合适的场景主推免流量服务。

>网络切换到数据网络仅使用开关控制。

>播放状态切换到无网络时或其他情况导致当前音乐无法播放，自动跳转到本地音乐播放。

>无缓存情况下暂停播放，回到wifi未自动回复播放。  

网易云的方案也不够优秀，文案上的字句相当晦涩，用户在流量面前不敢轻易尝试。

看了一圈竞品后，我们发现一个都不能抄……

解决方案

思路：我们基于WIFI、移动、无网络三个场景的更替，设计了如下方案。

移动数据下的流量提示窗

1.提供本次允许，点击后在单次进程内，开启移动数据网络下播放的设置项。

2.提供总是允许，点击后，始终开启移动数据网络下播放的设置。

网络切换场景续播逻辑网络场景拆分，按照网络降级后升级作为组合条件。

因为只有在降级后导致播放暂停的情况下，出现网络升级才有可能出现自动暂停后是否需要自动续播的诉求。同时需要注意网络场景需要继承历史设置。共有以下五种情况

1.播放状态下：Wifi->移动（自动暂停）->Wifi网络的情况，5min内自动续播，续播后自动隐藏流量提醒窗口。

2.播放状态下：Wifi->无网络-（自动暂停）>Wifi网络的情况，5min内自动续播，续播后自动隐藏无网络提醒窗口。

3.播放状态下：Wifi->无网络（自动暂停）->移动数据网络，根据用户是否开启移动数据网络下播放的设置决定。

a)开启：5min内自动续播，续播后自动个隐藏无网络提示窗口。

b)关闭：不续播，网络切回移动数据网络后隐藏无网络提醒，弹出流量提醒窗。（风险点：之后的网络切换，是否隐藏流量提示窗？）

4.播放状态下：移动网络->无网络（自动暂停）->Wifi网络的情况，5min内自动续播，续播后自动隐藏网络提醒窗口。

5.播放状态下：移动网络->无网络（自动暂停）->移动网络的情况，根据用户是否开启移动数据网络下播放的设置决定。

a)开启：5min内自动续播，续播后自动隐藏无网络提示窗口。

b)关闭：不续播，网络切回移动数据网络后隐藏无网络提醒，弹出流量提醒窗。（风险点同上）

风险点：

1.实际描述兼容性差：弹出时机表述不完整，防止流量损耗的时候弹出的提示窗，用户当时没有观看，等到用户在wifi环境下进入app，网络环境描述有误。（所以描述时机要慎用：“当前”二字）

2.信息传递不够及时不够到位：如果切换环境自动隐藏提示窗，则会让用户不解，为什么自动停下播放，属于对问题原因没有传递到位。

3.“本次”的概念不可控。

4.信息传递模糊不准确：本次允许 的逻辑用户难理解，“本次”究竟指的是什么？

5.自动播放逻辑不透明：5min自动续播的逻辑用户不可见，对于部分场景下5min自动续播是很体贴的方案，但是5min也可能会出现走到会议室手机突然播放：《五环之歌》的尴尬情况。

使用场景过于复杂，逻辑一旦设定，应该告知用户，保证透明且可控。

同时我们还发现了下面两大问题：

1.信息传递不及时：可以通过语音提示，老保证状态信息传递到位。音乐类软件声音中断，及时告知用户即可。

2.控制条件不可控：“本次允许”依赖进程的存活周期，不可控，可以采用客观条件控制暂时收听。

例如采用时间纬度控制，时间定为半小时或由用户自己制定。交互方式与文案可以优化，这里仅给出示意 

3.续播逻辑不透明：断网暂停时给出语音提示，告知用户5min内恢复wifi会自动续播。

挖掘根源

i.从起源说起

App的持续状态、处理逻辑、功能逻辑、引导逻辑以及其他状态发生非常规变化时需要提示。主要场景：

1.需要用户知会的必要的信息，同步给用户。

2.需要用户决策的必要的信息，同步给用户并交由用户决策。

3.特定场景下的、运营需要的活能改善体验的信息，同步给用户。

例1：持续状态：音乐播放器由于网络变化播放停止，提示移动网络流量消耗。

例2：处理逻辑：复制内容到空间已满的U盘，会导致复制不完全。

例3：功能逻辑：手机切换至省电模式，提示您已进入省电模式。

例4：引导逻辑：app新增功能，进入app后提供箭头引导。

ii. 提示、通知的类型

按提示、通知的存活周期划分：

1.常驻型：阻断其他操作，选择或确认后方能去除提示的提示窗。

2.非常驻型：不阻断其他操作，自动消失。

iii.处理逻辑类型以及选择标准

选择标准：按照处理逻辑影响划分。

1.有损型：

a)定义：损失指的是对于用户而言，处理逻辑有造成用户的损失或体验的破坏。

b)处理逻辑选择准则：

>触发条件可感知：触发时告知用户触发原因，同时要用户感知到有提示（或强或弱）出现。

>结束条件能控制：自动结束的条件需要客观可控，有明确的结束点。

使用客观条件控制，避免采用人为触发作为结束的条件。客观条件受到人为条件干预的，需做叠加逻辑保护用户权益。

例1采用客观条件控制结束更可靠。如依靠时间(xx分钟后)、依靠节目收听完成。（需叠加进程保护逻辑：如未收听完进程就被关闭，则节目收听完成判断逻辑清空。）

例2 反例，采用人为或不可控因素。如需要用户手动杀进程的、用户手动关闭的或依赖程序后台自动清理进程等隐形操作的。

>场景切换做适配：因场景变化导致的提示，需要在场景变化之后做适配逻辑。通过文案适配或者通过提示自动消隐作为适配。

例1如上文中提到的播放由于无网络停止播放，5分钟内重连wifi则自动消隐续播。

>平行操作先引导：操作走入死角是提供更多平行操作的引导，浏览内容无效则引导更多内容。

例1：因版权屏蔽内容，提示无版权后引导收听更多内容。

>取消止损易触达：有损型操作的确认提示，需要优先引导取消与返回，避免用户误操作。

c)  窗口选择标准：

>强提示：不可抗力导致需提示，选用常驻提示。

>弱提示：用户确认信息后的状态变更通知，且不可改变的提示，建议非常驻。例1删除重要数据文件时,提示数据无法恢复，是否确认删除。常驻提示。

例2：用户确认后，文件删除完成，通知用户，非常驻提示。

d)消失逻辑：

>自动消失：可以“无感知”将状态转为无损或恢复体验时自动消失。

>手动消失：无法“无感知”转换时则保持提示，用户确认后消失。

e)操作优先级标准：

>标准：

1.优先保证顺畅体验的操作。

2.优先引导无损处理的操作。

3.优先用户习惯性的操作。

例1删除重要数据文件时,提示数据无法恢复，是否确认删除。常驻提示。

例2用户确认后，文件删除完成，通知用户，非常驻提示。

>什么是优先引导的位置？--根据操作选项排版以及用户习惯引导。

 --根据操作选项外观样式以及操作难易程度引导。

 f)文案Tips：

>状态描述文案：文案需表述清楚弹窗时机。慎用“当前”、“现在”、“本次”或“此时”等类似的状态描述字眼。避免出现客观环境变化时状态描述不准确，产生误会。

>操作提示文案：字数尽量精简，陈述弹出理由以及操作影响，慎用疑问句，需同操作处理按钮的文案呼应。

>操作处理按钮文案：需同提示文案呼应，慎用：“确认”或“是的“等指代不清楚的字眼描述，建议直接使用操作名称的动词，如“删除”或“开启”等词。

例1：删除操作确认，优先引导取消，描述操作结果以及信息。确认删除后给出轻提示，表明状态，显示一段时间后自动消失。

例2：此处案例为错误案例，上文中有提到过的移动数据网络提示。

2.无损型：通常作为信息通知，处理逻辑无损失。推荐自动处理。

因为对用户利益没有太大的影响，所以自动即可，不进行过度论述。

>推荐原则：非必要知会的信息，自动处理。

>提示场景：轻提示通知时机一定为用户触发后，确保用户能够看到。否则自动消隐后，信息无到达，相当于废弃逻辑。这里也就不再多展开了。 

至此，该场景就算挖掘到底了。

只有每一个场景都已经被充分考虑，你的产品才能获得正真的特性。

这里是贤辈所留的每一步

试着把这步分享给伙伴吧

▼