复盘 | 听全民K歌体验设计师聊聊歌房项目完整设计历程(5)

3、房间信息区

头部房间信息区就比较简单，清晰地呈现谁的房间、有多少人、有多热闹即可满足需求。

这样，多人实时空间里各类人群就都有了满足他们需求对应的位置。

接下来看他们的操作

4、操作项布局

如前面所说，我们有 4 种角色，唱歌的、听歌的、语音席的、房主的，而这四种角色还会相互切换，所以一共有 19 种操作，如何能够清晰地呈现这么多操作，并且保证用户在不同身份状态切换时不迷失呢？

我的方案是，首先，依据核心行为分类整理；唱歌相关操作、听歌互动操作以及管理和其他。然后还原用户进行操作的场景，分类展示。

唱歌相关操作，是用户表演的入口以及表演时的相关设置，所以将它放在舞台区的位置呈现，方便用户想要上台以及在台上表演时操作。

唱歌前会点歌、查看已点，唱歌过程中，专注于唱歌，调音相关的设置一般不会频繁设置，所以把人声伴奏调节滤镜混响等操作收到控制台里替换点歌的入口。

听歌互动以及其他的操作是用户一进入房间就可以做的，所以放到房间底部稳定呈现，并且根据用户身份和状态切换去做变化。

听众状态是最基础的，评论、分享、其他放在左边，送礼突出放大到右下角引导听众送礼。当听众被邀请上语音席后，在普通操作基础上，增加语音操作。

房主相对比较特殊，有一系列管理能力的操作，但并不是那么频繁，所以都收起来放到管理里替换更多的入口；同样，语音操作也放在最后面，保持和语音席一致。

这样保证整体操作相对稳定，用户在各种角色切换过程中，就不会迷失了。

到这里，多人实时唱歌互动的空间就搭建完成。唱歌和听歌就都有了各自展示和操作的地方。

歌房的核心亮点——合唱

接下来是歌房最核心的亮点能力：合唱。这是用户在歌房能够互动玩起来的一个很关

键的点，也是业界首创，同时也是一大难点。

1、流程问题

如果是一个人唱歌，流程其实很简单，点歌、选歌、上麦然后就可以加载伴奏唱歌。

但在歌房合唱的情况，就比较复杂了。首先，合唱双方需要有序地完成一系列操作，点歌选歌、申请合唱、确认合唱、上麦唱歌；观众侧需要同步实时接收两端声音听到合唱。所以这其实需要完整考虑三端的体验。

从流程来看，有序很简单。一个人发起合唱、选歌、排麦、上麦，这时候观众们看到了，就可以发起合唱申请，发起人从申请人里选择一个来合唱、被选中的人上麦、然后加载伴奏合唱，观众侧即可听到合唱。

（编辑：ASP站长网）