腾讯体验设计师告知！全民K歌房是如何设计出来的？【百科全说】

最近，全民K歌迎来了它的三周年庆，三年里，全民K歌一步步走来，承载了太多人的回忆和故事，用心的用户每年周年庆都会有一个定制MV送给全民K歌，作为这个产品最早期的设计师之一，常常感觉非常骄傲和幸运。

这篇文章，想通过最近完成的歌房项目，复盘整个K歌的设计历程，也作为一个回顾和小结。

关于设计

在我的理解，设计分三个层次，界面设计－体验设计－生活方式设计。

界面设计是最基础的功能布局、逻辑跳转，而体验设计是关于用户更立体的需求、动机、行为；生活方式设计则是需要在体验设计基础上，于生活的各个可被设计的触点去影响用户，培养使用习惯，最终构建行为习惯，成为一种生活方式。

我们在最近一年里，完成了全民K歌TV版，友唱团队合作推出了线下M-bar，和联想、迅途合作推出麦克风……这些其实都是在商业生态的层面不断拓展和用户在生活中的触点，通过这些触点不断影响用户，影响大家休闲娱乐的生活方式。

关于歌房

歌房是一个多人实时唱歌互动的虚拟空间，歌房的设计完整打造用户在这里唱歌互动的体验，是一个完整的体验设计的案例。

在我看来，体验设计的关键点在于回答三个问题：从何而来、到哪儿去、如何做到。从何而来，需要你深刻理解你的产品、你的用户，清楚需求的来源；到哪儿去，则是需要分析清楚具体需求，确定设计目标；如何做到则是在具体达成目标的过程中遇到问题、解决问题。

那么，歌房从何而来？

从何而来

1. 从全民K歌的体系来看

全民K歌是一款兴趣社交产品，一直以来在做两件大事，基础K歌和社交互动。

在基础K歌的维度，为了满足用户唱得好的需求，我们不断拓展内容类型的丰富度，从普通音频作品，到MV、说唱、以及最近正在做的短视频，都是为了帮助用户在这里产生丰富的内容。同时，为了帮助用户产生优质内容，我们提供海量曲库、HQ伴奏、练唱等能力。给会员用户提供教唱视频，帮助用户系统、全面地了解气息、发声等等知识。

在社交互动的维度，为了满足用户玩得嗨的社交需求，除了基础的评论、送礼、私信以外，我们不断打造特色的互动玩法，比如打擂、合唱、家族、pk等等。

基础K歌和社交互动这两个维度是相互促进的良性循环过程。社交互动的原始需求要求基础K歌能力不断完善，基础K歌能力的完善，帮助用户不断产生优质内容，而用户围绕优质内容又有了更强的社交互动需求，在这个过程中，用户粘性也就不断提高。

事实上我认为所有的兴趣社交应用都可以从这个思路去设计，打磨围绕兴趣的基础能力的同时，打造社交互动玩法，两者良性循环粘住用户。

2. 从社交连接的维度来看

社交是关于人与人建立连接的，在K歌前两年的时间里，我们所有的社交连接都需要依赖发表异步作品，一个用户发表作品，其他用户来听歌，然后用户之间产生评论、送礼等社交连接，这种连接是间接的、相对慢的。为了帮助用户更直接更快地连接起来，去年我们开始打造直播这样的能力，给用户提供了一个人与人实时连接的虚拟空间，在这个空间，有人唱歌，其他人立刻就可以听歌，信息流通速度和效率都得到了提高，社交连接也更快速、通畅。

直播也有一定局限，在唱歌-听歌的维度，直播是1对多的单向传播关系，一个人需要撑起全部的表演，这对于表演者的要求是非常高的，所以一般而言，主播会玩得比较溜，对于普通用户来说，直播会有点尴尬、玩不起来。

那如何更好地去满足普通用户的表演欲让大家也实时玩起来呢？我们想到了群体的力量，就是如果不是用户一个人上去唱，而是有表演欲的大家一起去唱，大家都来唱歌的场景下，一来一个人表演的尴尬感和压力感都小很多，二来大家一起玩互动性更强了，普通用户也就会更愿意在这里玩起来。

3. 从K歌用户的社交关系来看

说到歌房，大家最容易想到的就是线下ktv，线下ktv是纯熟人、小圈子的玩法。

K歌并不是一个纯熟人的社区，在平台里活跃的更多人，一直在不断向陌生人展示自我，寻求。我们会看到用户不断在私信里给各种人发自己的作品求互粉求，在评论里不断地刷说来听听我的歌，然后特别喜欢跟一些粉丝多的人合唱，因为一旦被收录他就可以获得更多。

所以，歌房，其实是给到这样的一群人一个虚拟空间，帮助他们突破地理限制、以歌会友；充分地展示自我、实时地社交互动，更快速更广泛地获得，建立社交连接。

事实上，我们最大的竞品唱吧，很早就做了歌房类似的能力，但他们实现的，仅仅是简单的轮流独唱，我们认为其互动性还远远不够。

到哪儿去

了解清楚歌房的来龙去脉之后，我们开始回答第二个问题，到哪儿去。

我们K歌用户大致能分为这样六类，如刚才所说，粉色标记的这类用户，他们希望展示自我，渴望一夜成名，但他们不是头部的主播用户，他们在直播里没办法真的吸引那么多用户来围观，所以他们很有可能来歌房里唱歌，满足他们展示自我和获得的需求；而蓝色这几类有社交行为、喜欢追随他人的人，则可能会在歌房里扮演听歌互动的角色。

接下来我们就去细化场景、挖掘动机、提炼需求。

最终得到我们的设计目标。

如何做到

带着设计目标，我们开始回答最后一个问题，如何做到。

分两大块来看——歌房的空间布局、歌房的核心亮点。

歌房的空间布局

打造一个多人实时唱歌互动空间。思路上有两种，思路一是强调每个人、平等参与；思路二是突出表演者，给表演足够大的空间，在唱歌人数和整体参与人数的维度里，思路一强调每个人平等参与，可以唱歌的人多，但整体参与人数没办法很多；思路二整体参与人数可以很多，但同一时间唱歌的人少。我们希望是唱歌人数和整体参与人数都尽可能多。

我们的解决方案是，分区展示，平衡展示自我和社交互动。

具体来看。

1. 舞台区

舞台区的目标是让唱歌者获得陪伴、展示自我、获得，除了一个人一个人轮流唱以外，我们还可以满足用户和别人一起唱的需求；同时，就像演唱会或者livehouse那种，唱歌和唱歌之间都会有一些dj或者主持人起到一定串场的作用，让整个show不至于干。

所以我们设定了三种状态，独唱、合唱、语音席。语音席就是dj或者主持人的能力。区域上给最大的空间去展示表演者的视频画面，底部一行区域展示表演者的头像，吸引。语音席的观众同样也给到头像展示，让大家知道是谁在串场说话，他也可以获得一定的。

表演结束后，动画展示成绩并突出按钮，如果用户觉得她唱得好，就可以直接，帮助表演者快速直接地获得。

2. 观众区

这里的目标是让用户听歌互动得爽，土豪用户能炫耀。从需求上来说和观众在直播间围观唱歌是非常类似的，所以我们基本沿用了直播的设计。底部普通消息在互动区尽可能多地滚动展示；为了满足土豪炫耀的心里，就像我们在演唱会送花上台一样，送礼的消息会跨界进入舞台区被所有人看到；也支持土豪付费让信息跨界到舞台区让更多人到。

3. 房间信息区

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

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

接下来看他们的操作。

4.操作项布局

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

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

唱歌相关操作，是用户表演的入口以及表演时的相关设置，所以将它放在舞台区的位置呈现，方便用户想要上台以及在台上表演时操作。唱歌前会点歌、查看已点，唱歌过程中，专注于唱歌，调音相关的设置一般不会频繁设置，所以把人声伴奏调节滤镜混响等操作收到控制台里替换点歌的入口。

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

听众状态是最基础的，评论、分享、其他放在左边，送礼突出放大到右下角引导听众送礼。当听众被邀请上语音席后，在普通操作基础上，增加语音操作。房主相对比较特殊，有一系列管理能力的操作，但并不是那么频繁，所以都收起来放到管理里替换更多的入口；同样，语音操作也放在最后面，保持和语音席一致。

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

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

歌房的核心亮点——合唱

接下来是歌房最核心的亮点能力：合唱。这是用户在歌房能够互动玩起来的一个很关键的点，也是业界首创，同时也是一大难点。

1.流程问题

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

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

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

我们会发现，在这个过程中，发起方需要等待上麦、上麦后等待别人申请、确认跟谁合唱后等待加入，最后等待加载伴奏；而合唱方，需要等待确认申请、等待加载伴奏；观众方则需要等待他俩完成这一系列的过程。需要等待的地方太多时间太长。

怎么办呢？我们回过头来仔细审查了一下这些等待时间，其实有一些是可以合并的。

我们在用户必须要等的排麦阶段去完成一些操作。首先是预加载，在点歌的阶段去完成伴奏加载，将等待加载伴奏的时间合并到等待排麦中。其次是提前申请合唱的时机，其实最理想的是在排麦阶段就完成整个申请确认的过程，就像线下我们俩说好了我们合唱，我们就一起上台合唱。但线上的情况，考虑到用户如果反复在排麦列表进出去确认申请体验不好，而且中途如果加入合唱的用户离开房间还需要考虑是否告知发起人重新选择等等，就更复杂，所以目前是支持用户在排麦列表发起合唱申请，那发起人一上麦就可以从申请人里选择一个加入合唱，申请人等待确认的时间也就相应缩短。

2.技术限制时设计决策

合唱我们还遇到了另一个非常大的问题：实时唱歌涉及到人声伴奏的同步，声音在物理传输过程中会有延迟，合唱双方有一轮延迟，两端传到观众又是一轮延迟，如何解决呢？技术给到的方案是，演唱者A把人声伴奏传给演唱者B，演唱者B这边合成好两个人的声音后，一起传给观众。这样演唱者A始终无法听到演唱者B的声音，但至少演唱者B和观众是能完整听到合唱的。

这里就遇到决策，到底哪一方来做有损的一方呢？我们考虑了三个因素，首先，是可控性，我们可以在发起前给到一定的说明和提醒，其次是一致性，异步合唱的体验里，发起方发出时也是不知道最后会合唱成什么样的，最后是参与合唱的愉悦感，我们认为加入合唱应该是愉悦的，要不然我就自己去独唱了，为什么要加入合唱呢。所以综合考虑，我们最后选择让发起方来做有损的一方。

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

至此，整个歌房的主界面设计、核心的唱歌互动体验就设计完成；核心的设计目标达成。歌房里特殊身份还有一些特殊能力，例如房主，他可以邀请观众上语音、控制麦序等；土豪型用户除了已经涉及到的炫耀相关需求以外，还会有例如他不想等排麦，我们支持他去付费置顶等等的歌房增值相关的需求。满足完歌房里所有人的需求之后，歌房内的体验就完成。后续也将持续在基础K歌和社交互动两个维度不断升级歌房的能力。

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