BILIBILI LIVE STUDIO · EXPERIENCE SYSTEM
高压直播场景下的信息秩序与控制感
围绕实时信息、互动状态与开播资产，重建主播在高压场景中的判断、操作和复用路径。
背景
桌面开播工具 | 主播实时工作台
01
内容生产内容与播出
把直播内容稳定地搭起来
02
实时处理互动与活动
在直播过程中持续判断与响应
03
经营复盘经营与管理
连接平台经营与长期复用
我的角色
从视觉升级，逐步走向复杂工具的系统性体验工作
01
视觉升级
统一界面语言
重建信息层级
02
组件与规范
窗口 / 控件
基础可用性
03
系统体验工作
主播反馈 / 线上异常
业务迭代与体验治理
核心矛盾
工具系统正在失去可控感
01
功能增长方式反馈什么，就继续加什么
产品长期沿用主流推流工具的功能框架，并以响应反馈的方式持续叠加能力。局部问题被解决，但入口、规则与状态越来越分散。
02
目标衡量方式满意度无法指导单次设计
业务未绑定单一商业化 KPI，核心目标是主播满意度与稳定开播；但满意度由多重因素共同影响，难以直接归因到一次设计改动。
把“提升满意度”转译为可观察、可判断、可治理的体验问题
设计目标不再是继续补功能，而是先识别影响核心工作流的问题发生在哪个层级。
设计挑战
如何让复杂工具从“功能集合”升级为“可控的工作系统”
01
完整工作流走查
全局把控关键体验节点
02
收集问题池
了解产品体验现状
03
判断影响层级
避免单点修补或过度改版
体验走查
从关键工作流建立问题池
开播前
重启后需重新调整美颜参数，效率低下
体验洞察未评估素材类型增多，查找效率下降
竞品分析未评估素材区右键功能增多，筛选效率低
用户反馈中低布置场景时无法复用已添加素材
用户反馈中直播中
弹幕区容易错过高价值礼物
用户反馈高高人气直播间弹幕延迟，无法即时互动
用户反馈高弹幕滚动过快，难以定位需处理的用户
用户反馈高礼物屏蔽仅在弹幕区生效，礼物区不同步
用户反馈高设计策略
从功能堆叠，走向有序协同的直播环境
稳定互动
保障弹幕阅读稳定流畅
让互动玩法更好地服务直播
高效开播
提升开播准备效率
让每次开播更轻松省心
性能支撑
保障直播环境稳定流畅
兼顾高级用户的性能与自定义需求
01 稳定互动 · 02 高效开播
03 性能支撑 · 设置扩展 · 基础 UI
案例拆解 01 · 冲突
几千条小礼物，挤掉了主播真正需要回应的信息
- 01
高频小礼物持续涌入，挤掉高价值礼物
- 02
弹幕滚动有延时，主播无法即时互动
- 03
弹幕滚动过快时无法快速禁言/拉黑用户
- 04
筛选功能无法实时显示结果
- 05
设置没有即时预览与回溯
- 06
弹幕消息和礼物消息不在同一个位置展示
- 07
主播想看发SC的用户信息
公开直播
今天18:00
5
案例拆解 01 · 还原场景
人气决定信息压力，赛道决定注意力位置
直播间规模
访谈
成熟型 · 高 ACU
弹幕、礼物与活动信息同时涌入，关键消息容易被挤占，延迟与用户治理成本上升
聚合 · 优先级 · 快速处置走查
成长型 · 低 ACU
单次进场和互动价值更高；复杂设置会增加开播门槛，更依赖清晰默认和即时反馈
低门槛 · 明确反馈 · 关系识别内容专注度
访谈
游戏 / 才艺直播
注意力主要停留在游戏画面或长时间离开弹幕，对弹幕及时性更敏感
低打断 · 可回溯访谈
聊天 / 互动直播
互动本身就是内容，需要持续阅读和回应醒目留言、礼物、连麦与用户身份
实时阅读 · 快速回应共性问题
统一规则下，支持不同的信息优先级与操作强度。
注意力竞争
关键任务与次要信息同时争夺注意力
低成本试错
弹幕设置项有预期，减少犯错
规则一致性
筛选、状态与反馈结果难以预测。
案例拆解 01 · 策略桥梁
互动区不应只是消息列表，而应成为主播的实时处理入口。
01
顺应主播工作流
01悬浮弹幕：强实时性+弱管理
02副屏弹幕：强实时性+强管理
02
让信息服务行动
01重定信息层级控制注意力
02保证信息可读性
03
让操作可以预期
01筛选功能支持预览
02筛选规则全局统一
何同学1:主播晚上好！
奶油小方:今天播到几点呀
春日限定:这个操作太丝滑了
白河愁:刚来，请问打到第几局了
小狗储蓄罐:前方高能哈哈哈哈
月亮邮递员:画质好清楚
元气八梅君:主播下次什么时候开播
冰可乐不加冰:这波配合可以的
柚子茶半糖:已经关注啦
大车田宝火:从首页推荐进来的
星河入梦:今天状态拉满
薄荷汽水:这个转场好顺
大车田宝火进入直播间
1个月舰长
198030000
冰可乐x3300
何同学1:主播晚上好！
奶油小方:今天播到几点呀
春日限定:这个操作太丝滑了
白河愁:刚来，请问打到第几局了
小狗储蓄罐:前方高能哈哈哈哈
月亮邮递员:画质好清楚
元气八梅君:主播下次什么时候开播
冰可乐不加冰:这波配合可以的
柚子茶半糖:已经关注啦
大车田宝火:从首页推荐进来的
星河入梦:今天状态拉满
薄荷汽水:这个转场好顺
晚风邮局:声音很清楚
白桃乌龙:刚进来就高能
夏日航线:操作细节学到了
大车田宝火进入直播间
案例拆解 01 · 让操作可以预期
让筛选结果在开播前可预览、开播后可追溯
Before
筛选项无实时结果反馈
- 开播前无数据
- 历史内容不生效
- 筛选内容认知不足
- 主播必须逐区验证
After
筛选结果即时预览，所见即所得
- 外观与布局预览
- 弹幕类型可预览
- 筛选结果可查看
- 不同区域独立筛选
案例拆解 01 · 让操作可以预期
简化筛选逻辑，保持简单
Before
所有功能统一命名为筛选，列表冗长
- 礼物金额筛选
- 弹幕消息类型筛选
- 弹幕携带内容筛选
- 粉丝/荣誉等级筛选
After
按类型和条件区分，按需求场景分类
- 按类型和条件划分
- 礼物类型、弹幕类型
- 按金额、按等级
案例拆解 02 · 体验走查发现
一次体验走查，暴露出互动卡片正在失去边界
- 01状态入口分散，关键反馈无法及时到达
部分互动功能被收在“全部工具”中，状态又依附各自入口、红点或临时面板呈现。主播需要主动寻找，无法第一时间感知正在发生的互动。
- 02卡片信息各自生长，关键状态被过量信息稀释
不同业务在卡片中叠加状态、数据、结果与操作，信息密度和主次关系各不相同。主播必须重新判断每张卡片此刻最需要关注什么。
- 03临时事件与常驻曝光混用，区域缺少占用规则
进行中的互动、主播任务和营销曝光共同争抢卡片区，系统没有统一的准入、优先级、让位和退出规则。
案例拆解 02 · 问题分析
同一区域承载四种任务，问题不是数量，而是缺少统一规则
走查后，我把卡片区里的内容按主播当下任务拆成四类
01
临时状态
连麦中 / 表演中
02
过程数据
申请人数 / 投票结果
03
操作入口
处理申请 / 结束活动
04
业务曝光
心愿礼物 / 本场任务
案例拆解 02 · 初步判断
初步判断：只有需要主播即时响应的事件，才进入卡片区
这能保护实时事件的处理空间，但也把持续曝光对转化和收益的影响留在了规则之外。
案例拆解 02 · 价值验证
业务诉求不能直接决定入口，我用两个具体功能验证真实用户价值
业务方认为曝光消失会影响转化与收益；我不直接接受结论，而是回到心愿礼物和本场任务逐项判断
案例拆解 02 · 重新制定规则
以用户价值为优先，我重新定义卡片的优先级、占用与退出
实时事件高优先；持续状态限额保留；只承担曝光、不能影响主播行为的内容退出卡片区。
案例拆解 02 · 最终设计方案
两类卡片、四种状态模型，覆盖完整的进入—进行—退出过程
案例拆解 02 · 设计展示
互动卡片完整状态设计
案例拆解 03 · 直播提效
开播前的效率来自复用，而不是少点一次
访谈记录（节选）
“直播姬无法复制场景和素材。”风｜游戏主播
访谈记录（节选）
“每次用户重启直播姬后都需要重新调整美颜参数。”凉哈皮｜娱乐主播
访谈记录（节选）
“素材功能找不到。”风｜游戏主播
问题洞察
相似直播场景仍需重新搭建
主播需要两个相似配置的场景，只有个别内容不同，但需要从零配置
有些常用参数会重复使用，但系统只能记住上次的配置
配置关系依赖主播记忆
- 主播需要记住位置、层级和参数，遗漏常在开播后才暴露。
把一次配置，沉淀为下一次可直接使用的工作资产。