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

如今，很多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端视角，才能真正平衡最终的运营行为。

四、设计原则总结图

​Read More