案例分析：3种用户场景对APP评论模块设计的影响

2018-05-08 17:19:00

平时我们刷微博、刷朋友圈，浏览新闻等场景，都离不开评论功能，大多数情况下都有让用户积极参与讨论的功能；而这些评论和回复的展现方式都各不相同，用户场景对功能的设计到底有怎样的影响呢？本文将通过对时下常见APP评论模块的分析，去探索不同场景下评论模块的设计。

一、动态发布场景——QQ/微信/微博

1.QQ/微信

使用聊天软件时，会在发布动态和朋友圈的时候有评论和回复的操作，QQ和微信在这一块的设计是采用按照时间顺序平铺式，且没有单独的评论详情，评论和回复直接展示在动态下方。
如下图所示：
超级产品经理

优点：在评论数量不是特别多的时候，这样的功能设计，逻辑结构简洁清晰，容易理解，并且按照时间顺序排列，内容方便追溯。
缺点：如果评论内容非常多的情况下，没有在别人评论时立即回复，则回复的内容和评论的内容可能就相距较远，而且还可能出现漏掉回复的可能性。

2.微博

微博是一个以发布内容为核心的平台，所以一条动态的下方评论非常多，一条热门微博下面可能有好几十万的评论以及数不清的回复。
微博面对这样大量的信息给出了两个设计：

在动态下方显示所以有评论以及部分优质回复；
点进单条评论，还有一个回复的详情页面；把内容分流，然后分别用按照时间/按照热度排序，去方便用户查看内容。

如下图所示：
超级产品经理

优点：

把内容分流，方便展示，不会显得混乱；
按照热度/按照时间的自定义排序，很契合用户的使用习惯，有的内容需要看热门的，有的需要看最新发表的；
这样的设计逻辑结构也非常清晰，容易理解。
缺点：由于一条评论的回复非常多，同时在回复详情里还有互相回复的情况，这样的情况下按照时间顺序排列，很难追溯到回复对应的内容，只有回复内容的本人能够轻易的从消息列表点击跳转，直接定位到所回复的内容。
二、问答场景——知乎
知乎上很多问题都是很久之前提出的，并一直保持着热度，这样的场景下评论的内容都不是即时的，很有可能一个评论会在很久以后才会收到回复。
基于这样的用户场景，知乎设计了一个对话列表二级页，方便追溯用户的讨论过程，评论列表页只有评论没有该评论相关回复的展示（区别于微博的评论列表）。
如下图所示：

优点：对于一些时间比较久远的评论，这样的设计能够快速点击查看相关的回复，容易追溯，且设计上很简洁，逻辑清晰。
缺点：由于回复了的内容，也会显示在评论列表，如果这样的操作较多的话，重复性较高，对于同一个对话列表里面的东西，同时也显示在评论列表，会显得有一些冗余。
三、新闻评论场景——网易新闻
新闻类的APP都有着极强的讨论性，许多用户会就一条新闻发表自己的观点，同时也有许多人反驳/支持这些观点，因此在新闻评论的场景下讨论的氛围更加浓厚。所以网易采用了盖楼的设计，方便用户在评论中讨论。
如下图所示：

优点：盖楼的形式一目了然的显示出讨论的内容，为防止楼层太多，将中间的楼层都折叠起来，只留下了前两层楼和最后一层楼的内容；并且不会出现只能看到我回复的上一条评论，可以追溯之前所有的评论。
缺点：每增加一条回复（没盖一层楼），就会显示所有的跟帖，从某种程度上说也有着一定重复性，比如在楼层较多的情况下，重复率就较高。
四、总结
因为前段时间在设计一个评论模块的功能，于是整理和分析了相关的评论设计。
市面上还有很多APP没有来得及去探索，但其实归根结底：每一个设计都是根据自身的用户场景来的，整理文章的初衷是希望能够通过分析各大APP的用户场景，来探索其设计背后的意义。

作者 @ 落浅。