产品设计思考：评论VS弹幕差异.pdfVIP

产品设计思考 ：评论VS弹幕的差异 最近有朋友在我的公众号提了个问题 ：为什 有的音乐app做评论功能 ，有的做弹幕功能 ，评论弹幕 有什 区别 ，以及优缺点 ？……嗯 ，话说 ，这难道不是三个问题吗 ？ 好吧 ，我来做个简单的解析。 这个问题其实很经典 ，对比到实际工作中 ，会有很多类似问题 ，比如为什 A可以做第三方登录 B 没有第三方登录 ， 为什 A做的是卡片信息流 ，B做的是瀑布信息流 ？ 这次 ，我们用网易云音乐和Q Q音乐来做对比分析 ，网易云音乐采用的是评论功能 ，Q Q音乐采用的 是弹幕功能 评论和弹幕的区别 共同点 ： 评论和弹幕 都是工具迈向社区一个特征 ， 本质上是属于同一个缺陷的不同解决方案。 音乐类产品对于用户而言 ，满足的基础需求是听歌曲 ， 超出部分则是找到喜欢相同歌曲的人 ，并展 开社交或社区的动作。 人们在兴趣偏好上 ，往往是孤独的 ，这一点 ，即使是我们身边有朋友与我们喜欢相同的朋友也不 例外 ，因为他们不可能时时刻刻响应我们 ，同时 ，也是因为我们始终会将自己处于“孤独”姿态。 是的 ，人们总是不满足的 ，即使身边的朋友都和我们有相同的兴趣 ，一旦我们接触了更为广阔的人 群时 ，就希望更多的人 ，站在和自己相同的地方 ，喜欢相同的事情 ，否则就会认为自己不合群 ， 这 是一种不安全感 ，也是一种无归属感。 不如设想这样一个场景 我们听到一首歌曲 ，非常非常喜欢 ，在满足一些孤独和时间条件的基础下 ，我们会开始想象 ，有多 少人也喜欢这首歌曲 ，并且我们也想要将自己的感情抒发出来 ，把“我喜欢xxx”释放出来。 （大部分 场景是阅读后再发布 ，跟随效应 ），一旦我们发现 ，原来有这 多人都喜欢这首歌曲 ，我们会感觉 找到了自己的组织 ，就形成了一个微型社区。 这里顺带简单提及一下 ，工具类型产品要走到社区的阶段 ，一定是需要基于用户模型的细分 ，如同 音乐类app ，100%的用户属于听的部分 ，60%属于兴趣偏好部分 ，4 0%属于寻找组织 ，20%属于发 言者 ，因此 ，做工具类产品的朋友 ，如果希望介入社区 ，那就仔细分析一下你的用户群体 ，寻找已 经有兴趣偏好的这部分用户 ，来做社区的切入点。 评论与弹幕 ，其本质都是在于如何基于音乐打造音乐社区的初衷。那他们的优缺点是什 样的呢 ？ 关于评论 ： 优点 ： 阅读价值更高 ，更正式 ，更具备信息的延续性 （内容-评论-人- 内容 ） 评论本身由于篇幅充裕 ，更多的是内容的衍生 ，包括对音乐的点评 ，信息的补充 ，更具备信息的承 载性 ，如同我们在看新闻时 ，往往评论比新闻更吸引人 ，所以就有了所谓的神回复 ，神评论。 我们来看这样一个场景 ： 我正在听一首印度歌曲 ，歌名叫Raabt a ，我非常喜欢这首歌 ，想要知道这首歌更多的信息 ，比如来 自于那部电影 （国内印度音乐大部分都是电影音乐 ），于是我查看了他的评论 ，在评论里我看到了 有一位达人写的很长的评论 ，我点击他的头像去看了他的个人资料 ，发现他的歌单有很多印度歌曲 ，（当然 ，如果没有找到我想要的答案 ，我也会发起一条求助的评论 ）。 缺点 ： 很难形成对话 ，频率低 ，会“看完”无法形成社区本身的粘性。 评论系统最大的缺点在于回复不及时 ，以及信息不连续 ，在弹幕出来之前 ，其实屏幕的类比对象 是IM系统 ，透过暴露出来的日期 ，我们很容易发现其实评论区域很冷清 ，即便他已经拥有上千条 评论 ，如果没有很强大的信息通知系统 ，我们基本可以默认评论是没有回复的能力的。 同时另一个缺点也在于 ，评论的内容属于有尽头的信息 ，你会产生“看完”这种体验感觉 ，因此 ，我 们查看评论 往往需要很强的动机 ，要 是抒发感情的 ，要 是查找补充信息的。很难形成社区本身 的粘性 ，只能加强内容的粘性。 关于弹幕 ： 优点 ： 具备IM的特质 ，容易产生对话感 ，热闹氛围强 ，更容易互动和产生信息。 弹幕本身的操作空间比评论大很多 ，其实我们所谓的弹幕存在很大的灰色逻辑 ，也就是不那 正直 的逻辑 ，更多的是一种小聪明 ，比如时间的错误嫁接 ，通过这样的方法我们很容易产生哇塞 ，这 多人和我“同时”在听的错觉 ，我们会看到“过去的”但又是“同时的”信息 ，因此 ，弹幕的信息数量往往 会比评论大很多 ，并且更容易产生对话场景。 列 一个场景吧 A 昨天上午11:00 听了一首 《蓝色土耳其》 ，并在歌曲播放到1分钟时 ，发了一条弹幕 ，“我在火车 站听” B昨天半夜20:00 也听了同一首歌 ，并且在歌曲播放到1分钟时 ，看到了A发的弹幕 ，于是他也发了 一条弹幕“我