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

我们在用户必须要等的排麦阶段去完成一些操作。

首先是预加载，在点歌的阶段去完成伴奏加载，将等待加载伴奏的时间合并到等待排麦中。其次是提前申请合唱的时机，其实最理想的是在排麦阶段就完成整个申请确认的过程，就像线下我们俩说好了我们合唱，我们就一起上台合唱。

但线上的情况，考虑到用户如果反复在排麦列表进出去确认申请体验不好，而且中途如果加入合唱的用户离开房间还需要考虑是否告知发起人重新选择等等，就更复杂，所以目前是支持用户在排麦列表发起合唱申请，那发起人一上麦就可以从申请人里选择一个加入合唱，申请人等待确认的时间也就相应缩短。

2、技术限制时设计决策

合唱我们还遇到了另一个非常大的问题：实时唱歌涉及到人声伴奏的同步，声音在物理传输过程中会有延迟，合唱双方有一轮延迟，两端传到观众又是一轮延迟，如何解决呢？

技术侧给到的方案是，演唱者A把人声伴奏传给演唱者B，演唱者B这边合成好两个人的声音后，一起传给观众。这样演唱者A始终无法听到演唱者B的声音，但至少演唱者B和观众是能完整听到合唱的。

这里就遇到决策，到底哪一方来做有损的一方呢？我们考虑了三个因素，首先，是可控性，我们可以在发起前给到一定的说明和提醒，其次是一致性，异步合唱的体验里，发起方发出时也是不知道最后会合唱成什么样的。

最后是参与合唱的愉悦感，我们认为加入合唱应该是愉悦的，要不然我就自己去独唱了，为什么要加入合唱呢。所以综合考虑，我们最后选择让发起方来做有损的一方。

在发起方点歌时，提前告知合唱会有这样的情况，唱歌过程中解释清楚为什么会有这样的情况，然后在唱歌结束后提供保存作品的能力，后续他可以去听歌、发布。

至此，整个歌房的主界面设计、核心的唱歌互动体验就设计完成；核心的设计目标达成。歌房里特殊身份还有一些特殊能力，例如房主，他可以邀请观众上语音、控制麦序等；土豪型用户除了已经涉及到的炫耀相关需求以外，还会有例如他不想等排麦，我们支持他去付费置顶等等的歌房增值相关的需求。

满足完歌房里所有人的需求之后，歌房内的体验就完成。后续也将持续在基础K歌和社交互动两个维度不断升级歌房的能力。

回到歌房在整个K歌的体验闭环里，关于如何产生，即创建入口和创建流程的设计；关于如何触达，关系链外我们在热门、附近去曝光，并且提供主题歌房吸引用户；关系链内，我们在用户日常会产生关联的地方去曝光，例如动态feed、个人主页、家族歌房等等；最后跟异步作品这里，也做了一个串联，歌房可以产生作品、作品也可以引流回歌房。

至此，歌房完整的体验设计完成。

设计结果

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!