以小鹅通直播为例,探讨SaaS对复杂B2C功能的产品设计原则

0 评论 8182 浏览 36 收藏 21 分钟

如今,很多SaaS厂商开始瞄准“企业服务”赛道,其中重要的一环就是为企业元B2C业务提供标准化功能,以增值原业务。然而这类业务抽象为标准化功能时,会面临3大设计难点,如何解决这些难题呢?本文作者以小鹅通直播为例,探究SaaS对复杂B2C功能的产品设计原则,一起来看一下吧。

在众多企业全面尝试业务线上化、经营数字化的今天,很多SaaS厂商开始瞄准“企业服务”赛道,其中很重要的一环就是为企业原B2C业务提供标准化功能,以增值原业务。但是这类业务抽象为标准化功能时,一定会面临3大产品设计难点。

但是,如何解决这些难题呢?笔者作为B端产品经理,希望通过对个例的分析,探究SaaS对复杂B2C功能的产品设计原则。

一、开篇概述

在输出《以小鹅通为例,探讨SaaS产品如何解决“上手难、效率低”的用户体验问题》时,笔者发现小鹅通直播非常切合这3种情况,本篇文章就以小鹅通直播为例,代入【运营管理者、第三方讲师、观众】3类用户的视角,体验一场直播【直播前准备、开播、直播中】的完整组织、落地、交付过程,观察用户体验问题,分析得出复杂B2C业务的标准化功能的产品设计难的根本原因和通用原则。

二、体验功能介绍

直播业务的复杂性很高:初期需要B端多角色协作、多运营环节逐步准备,后期在一个界面+限定时间范围内,将所有内容和运营动作一次性呈现给C端用户。

但平时我们更多接触到的是C端公域带货类直播,如淘宝直播、抖音直播;而对小鹅通直播这种SaaS私域直播功能了解较少,所以在这里做一些补充介绍。

三、体验情况

第一步:直播前准备

复杂B2C业务有2大特点,B端运营重、流程环节多,导致将其抽象为标准化功能时,产品设计一定会面临一个问题——该功能的B端管理界面必然承载了大量功能,此时如何降低用户负担与使用成本?

1)第一眼感受:事情看着好多心好累

在很多SaaS中,复杂功能的创建和详情页面都非常长,人还没开始操作,大略看到内容后,心就有点累了,更不用说在第一次使用时不了解它的情况下。

小鹅通案例:

① 创建直播:需要滚动6屏(普通笔记本电脑),并且第1个分类板块【基本信息】就占了约4屏;

② 直播详情-直播间设置-互动设置:需要滚动3至N屏;

③ 直播详情-运营设置:需要滚动6屏,并且与这场直播关系更紧密的【开课提醒】、【直播间信息设置】被放在最后。

2)操作过程中感受:旋转跳跃我闭着眼

SaaS的功能总在不断增多,但由于功能总是单个单个上线,长期下来,功能的核心页面内就散落了很多未经整体设计的功能点,导致页面内功能点放置的位置(tab分类、tab下顺序),缺少合理、统一的标准,既不是按业务流程定、也不是按运营场景定。

这导致,用户日常使用时体验会非常混乱。以小鹅通为例,当我按常规逻辑(业务流程/运营场景等)逐步设置业务所需功能时,出现了4种混乱体验导致的问题。

小鹅通案例:

①我想编辑用户进入直播间后看到的内容:创建页:简介、详情、暖场图;详情-直播间设置-直播间装修:皮肤、背景图、菜单;详情-运营设置:最下面的直播间公告、观看人数/在线人数/直播间热度是否展示。

②我想编辑直播内容来源和该直播内容都展示在哪些地方,需要经历3个tab:开播设置、转播设置、拉流设置。

③详情-运营设置:功能的位置顺序和实际业务流程顺序差异很大。

小节总结:

对于复杂B2C功能的页面,我们必须足够了解和熟悉用户实际使用案例,并在尊重“常规思路”的前提下设计功能。

  1. 分析提炼出功能的业务场景和流程,从中抽象出合理、统一的逻辑,作为众多功能点分类和排序划分的依据;
  2. 反复对比业务实际操作路径与功能使用路径之间的不同点,然后针对性的调整;
  3. 对于页面长的问题,在交互设计和UI设计层面尝试更多方案,例如“卡片”样式;
  4. 整合清楚后,还可以针对B端操作效率场景,提供功能编辑时的“模板”功能,类似淘宝/千牛的商品信息模板功能。

第二步:开播

B2C功能中有一类很特殊——平台类/场域类功能,因为它们的用户最少存在供需两方,有时还有第三方。所以,必须通过平台/场域的产品功能,表达出平台/场域的规则,并且必须让参与的几方角色都清晰感知到这个规则,才能让用户在平台/场域下顺利见面互动、才能让这个功能在C端成功运转起来。

如上图所示,公域是规则主导方,而SaaS不是。因此,SaaS对平台类/场域类功能的设计思路难度是非常高的,极容易出现歧义、造成用户体验问题,并最终可能导致供方对平台/场域运营不顺畅,业务增值效果差。

1)我(B端运营者)辅导外部讲师开播:双方都难受

第一个设计原则:一定要向供方(即SaaS直接用户、即平台规则制定方)清晰、完整地表达出全部流程、各方操作视角,尤其是与需方和第三方首次衔接的环节,切不可产生“将C端收到链接后的路径设计好就行,不用告诉供方太多,减少他的负担”这种想法。

这是因为:

① 是供方与需方、第三方直接接触联系,只能由供方通过自己的方式传达清楚规则,其他方才能轻松,进而供方才能轻松;

② 供方是主导方、责任方,他需要掌控感;

③ 供方本身就有引导的运营意图,这些信息能帮助他完成初期运营引流。

小鹅通案例:

没有充分理解到B端有辅导外部讲师开播的作用和责任,因此没有充分且清晰地提供相关信息给B端:

①B端运营者对“讲师开播流程”的了解受限于“开播信息”,既不知道讲师开播路径、也不知道讲师其实可以自己选终端开播,导致B端运营者无法尽到引导作用,例如提前告诉讲师最好选择哪种开播方式,结果直播中途才发现需要换终端,踩过一次坑后才知道得提前提醒新来的讲师。

② 当运营者让外部讲师开播,用了4个以上页面来说明,但互相之间指引冲突,含义冲突,或又其他产品表达问题,导致讲师用不明白、供方也解答不了,最终成了卡点。(注:该案例也属于“编辑设置时要来回跳转”的体验问题,并且是一个存在逻辑关系的功能流程内仍要跳转多个页面完成,与上方案例的纯功能间分类/顺序问题不同)

③ 点击讲师列表右侧短信通知,会直接发送短信,而并没有告诉B端运营者通知内容。

2)我(外部讲师/学员):我是谁?这个界面是给我用的吗?我现在要做什么?

第二个设计原则:SaaS在设计供方提供给第三方/需方的入口和使用路径时,一定要立足实际使用者(第三方/需方)的视角进行设计,不是供方的视角、也不是SaaS视角。否则会影响实际使用者对功能的心理预期、使用路径,最终导致第三方/需方使用功能时自我混淆。

小鹅通案例:

① 短信通知时,讲师很可能通过手机自带浏览器打开H5,此时讲师很可能经历两次登录流程。

② 小程序(微信打开H5链接):讲师通过供方提供的开播链接开播时,他看到的使用路径是清晰的(红色页面1、2、3);但一旦讲师是通过鹅直播主页开播,就很难以清楚找到自身的定位和使用路径了(绿色页面1、2、3),最少形成2个“阻碍”。

③ 客户端/小程序(下图红色内容):下图红色内容-开播路径的交互逻辑不符合B端私域:小鹅通直播是B2C业务,开播行为是B端商业行为而非C端即兴行为,B端对“开始直播”环节,并不会过度追求“立刻感”,反而需要一定基础准备所带来的“安心感”。

④ 客户端(下图绿色内容):快速直播按钮的交互不符合可预知性原则、统一性原则。

⑤ 客户端(上图主界面列表):不显示每场直播的所属店铺,对讲师和学员来说都是很大的干扰。

⑥ 客户端/小程序:可以在选择店铺的菜单中放“没有找到店铺?点此了解”,给讲师讲解如何解决,从讲师视角反向引导B端,解决讲师开播环节的引导问题。

3)我(外部讲师)在鹅直播上无法开播,必须等运营者登录后台修改信息

第三个设计原则:当业务需要分角色完成时,每个功能的位置/定位,除了考虑业务流程之外,还需要考虑角色分工(以此分析出会使用到该功能的角色),综合确认该功能应该放在哪一个角色处管理,即功能位置放到哪一端。
同时,不同供方的角色分工情况可能是不同的,因此如果准备将某敏感功能放置到第三方管理,应该同时给供方提供对应权限管理功能。

小鹅通案例:

① 运营者创建时随意选择了结束时间,等讲师准备开播时才发现“直播已结束,无法开播”,此时讲师端无法修改结束时间,必须由供方的运营者登录后台修改后,讲师再开播

② 小程序/APP:讲师无法看到本场直播的数据情况,需要靠运营者在后台截图发给讲师;客户端中提供了讲师数据海报,可以提供基础数据情况,并且满足分享场景

小节总结:

对于平台类/场域类功能,SaaS必须先保证自己梳理清楚完整业务流程、角色分工、角色协作环节,才能将抽象出来的业务用产品设计表达出来,让功能达到以下3点效果。

  1. 向供方提供灵活可“自定义”的平台类/场域类功能的同时,全业务流程的功能逻辑清晰明了
  2. 在连接需方/第三方的环节上,为供方提供清楚的说明与帮助
  3. 在需方、第三方使用的端口产品上,功能界面和使用路径符合实际使用者的期望

最终才能将平台/场域的规则定义权掌握在自己手上,才能向直接和间接用户提供既便捷简单又灵活丰富的产品功能。

第三步:直播中

像小鹅通一样,有一些SaaS是“帮助B端做toC生意”,其核心业务功能看似是提供给B端,其实最终会交付给C端。对于这类功能的产品设计,除了考虑“B端目标”外,还要非常重视从“C端视角”出发思考
当我们做纯C端产品时,不可能忘记以“C端视角”思考。而一旦面对的是SaaS的“附属”C端功能,就容易陷入一种思维陷阱——过于关注B端的期望和目的,而不深入C端的价值和体验:

  1. C端对这个功能会有什么心理和反应
  2. 是否能达成商家使用这个功能的运营目的等

1)我(C端用户)过五关斩六将才进了直播间, 结果看着五花八门的东西迷失了方向

B端的运营需求是没有尽头的,最终很可能会搞出一堆花里胡哨却没什么效果的功能,并且还会加剧B端的错误运营思路。这一点在直播功能上体现的尤其明显。

直播与C端的接触会被限定在一段时间内的,B端之前设置的各式各样的运营手段,会在一段时间内集中、轮番地呈现给C端用户。因此,在直播下B端的运营行为是非常快速且紧凑的,C端用户的情绪心理也会被不断冲击,在此情况下,如果功能因忽略C端心理而设计得过于粗糙或复杂,价值传递的效果就会大打折扣,还可能让用户产生抵触感,很容易导致用户流失。

2)我(B端运营者)不知道C端会看到一个什么样的界面、会经过什么样的路径

SaaS的toC功能与纯toC产品不同:

  • 纯toC产品:产品设计者可以清楚知道并控制产品的最后结果;
  • SaaS的toC功能:产品设计者给B端在每个业务环节、每个场景上都提供了丰富的运营功能,B端根据自己的目的自由组合功能点,形成最终的toC功能和界面。

因此,对于多个功能点需要在一个界面中展示时、需要在一个流程中依次出现时,纯toC产品很容易平衡考虑,而SaaS的toC功能则要复杂很多,若产品设计者都没有考虑,或没有可视化给B端的话,B端运营者就无法知道“C端用户在某个流程、某个界面中会走的路、会感受到的信息价值”,导致B端无法自我平衡运营行为和内容。

小鹅通案例:

① 当该直播有很多针对“用户进入直播间”环节的功能,如付费售卖+直播预约+信息采集+购买前后私域引流+……,会导致引流环节的跳转多→门槛高→流失率增高。

②该直播有很多针对“促进分享裂变”场景的运营功能,如邀请达人榜+分享有礼+招募推广员,会导致B端运营没有核心目标或运营行为过多,对应的C端会看到太多信息+太多路径而迷茫。更不用说一个直播间界面上还要展示“引流、气氛互动、营销带货”等等场景的运营功能。

小节总结:

避免只关注B端不关注C端的“一条腿走路”式产品设计。

  1. 设计每一个toC功能,都应该从C端视角出发思考和设计,尤其着重C端的①场景和价值点、②功能使用路径与体验;
  2. 产品设计者需要梳理清楚C端在该业务功能下会遇到的所有功能、界面、路径、岔路口,不光是某个静态页面内多个功能如何呈现,还有该功能完整流程的动态过程中多个功能如何呈现。这样才能在设计toC功能时,意识到单个功能点对C端在整个业务下感受的影响;
  3. 产品设计者观察到的全面的C端视角,应该通过B端对toC功能的管理界面,通过可视化等设计手段,将这种视角信息传递给B端运营者,让他们拥有C端视角,才能真正平衡最终的运营行为。

四、设计原则总结图

本文由 @B端编外产品 原创发布于人人都是产品经理,未经许可,禁止转载

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!