如今，很多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功能的页面，我们必须足够了解和熟悉用户实际使用案例，并在尊重“常规思路”的前提下设计功能。

分析提炼出功能的业务场景和流程，从中抽象出合理、统一的逻辑，作为众多功能点分类和排序划分的依据；反复对比业务实际操作路径与功能使用路径之间的不同点，然后针对性的调整；对于页面长的问题，在交互设计和UI设计层面尝试更多方案，例如“卡片”样式；整合清楚后，还可以针对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点效果。

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

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

第三步：直播中

像小鹅通一样，有一些SaaS是“帮助B端做toC生意”，其核心业务功能看似是提供给B端，其实最终会交付给C端。对于这类功能的产品设计，除了考虑“B端目标”外，还要非常重视从“C端视角”出发思考。

当我们做纯C端产品时，不可能忘记以“C端视角”思考。而一旦面对的是SaaS的“附属”C端功能，就容易陷入一种思维陷阱——过于关注B端的期望和目的，而不深入C端的价值和体验：

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

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端的“一条腿走路”式产品设计。

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