10个关键点
展示样式、排序规则、操作行为、跳转逻辑、运营操作、被删除/屏蔽后显示逻辑、防呆设计、快捷操作、富媒体支持、细节支持。
一、展示样式
目前市面上流行样式有：平铺式、主题式、盖楼式、对话式、混合式几种。
平铺式
指所有评论都在一个层级，包括原评论，和对评论的回复，并行显示。
平铺式强调的是回复内容直接的平等，把每一个评论都当做一个平等客体。由于各条评论处于同一级别相互之间没有层级关系，更加方便了互相的交流，所以在“微信朋友圈”这类熟人社交体系下效果非常理想，本身可见用户之间相对熟悉，这样的设计使得信息沟通更方便。
主题式
指把原评论作为一级评论，对原评论的回复，作为二级评论，排在一级评论下方。也就是说，将一级评论作为“主题”，允许针对某个“主题”展开讨论。
相比平铺式评论，主题式评论能让讨论主题更聚焦，让优质评论更能浮出水面，形成讨论氛围。对运营而言，还可以针对优质评论展开讨论，促进曝光，提高运营效果。市面上很多注重评论的内容平台均选用该样式，如贴吧、最右、简书、微博等。
盖楼式
指每次对原评论的回复，都把原评论内容露出，并带上自己的评论，以“圈层”样式呈现，久而久之就形成无限嵌套的方框样式，叫做“盖楼”。
将这一样式发扬光大的当属网易新闻，这也是它的特色之一，由此诞生出很多经典评论效果。但是，盖楼式评论在楼层多的情况下势必要进行多层隐藏，且不好对评论进行追踪，视觉效果也容易引起疲劳，
对话式
指每次对原评论的回复，就是和评论发布者的一次对话，这种对话本身也可分为一级、二级，乃至多级对话，分别是对评论者、评论回复者，回复评论回复者的人，以此类推。
知乎就是典型的对话式评论。对话式会让评论互动更鲜明，但其样式的设计却增加了理解成本，慎用。
平铺简版
指仅能用户评论仅有一级平铺展示，不能再次评论，这也是平铺的简单版
这种结构很简单，但是缺点在于评论区不会有任何互动，适用于要么不是很重视评论，有个简单的评论功能展示用户的观点和意见即可。例如微信公众号：
混合式
指以上几种样式的混合，有的是一级评论用主题式，二级评论用平铺式；有的是以及评论用主题式，二级评论用对话式；还有的是一级主题、二级对话、三级平铺。
具体用哪种，也是根据用户理解程度和内容运营倾向性来选择。
二、排序规则
主流排序规则有：按发布时间、按热门程度，再加上人工精选。
按发布时间
通常默认是按发布时间倒序，再进一步可支持用户可选正序、倒序排列。
值得注意的是，对主题式评论，通常一级评论默认倒序，目的是让用户看到最新评论，一级评论下的二级评论则是默认正序，目的是让用户理解讨论进展。还有一点，就是一级评论默认倒序的时间，建议取一级评论下，二级评论的最新发布时间，这样能保证一级评论的排序是按评论本身的讨论进展来更新的。
按热门程度
则需要计算所有评论的“热度值”，根据此来排序。
热度值一般取评论的点赞数、回复数2个维度，按权重进行线性求和计算，有的还支持“点踩数”、“举报数”等负面维度，此外，为了避免马太效应，还要考虑加入时间衰减因子，算法优化方案有很多。
三、操作行为
主流操作行为有：点赞、回复、复制、举报、删除、分享
点赞
要考虑点赞、取消点赞后的赞数变更逻辑，是否需要服务端同步更新，点击后的动效，点赞后的消息提醒机制等。
回复
要考虑回复弹窗的出现、收起时机，回复字符限制，回复是否支持换行符，是否支持键盘提交，是否允许空字符提交，回复页面弹窗大小，按钮布局等。
复制
要考虑可复制区域，复制交互（长按/点击），复制后的提示效果等
举报
要考虑是举报文字还是举报人，举报后的提示，举报后的数据审核等
删除
要考虑发布人支持删除功能，删除时是否出现弹窗提醒？删除后状态何时同步？删除是硬删除还是软删除？等等
分享
要考虑可分享平台，分享文案，分享后的打开样式，是分享成网页还是分享成图片等。
跳转逻辑
跳转逻辑，主要是考虑由于发布了评论，或回复了评论，哪些地方会产生相关入口，以及这些入口点击的跳转位置，包括:
- 我发布的：通常会在“我的”里面，或者“消息中心”，可查找自己发布过的评论，这些评论点击后可跳转到对应评论页面，如果是主题式评论，对应跳转到评论二级页。
- 回复我的：有人回复我的评论，在“我的”或“消息中心”会收到消息，该消息需要可点击跳转到评论页面。
- 个人动态：用户发布评论或回复评论，都属于个人行为，如果产品存在个人主页，那应该将该行为记录在个人主页，以“动态”形式出现，其他人可在查看用户动态时，找到该用户对哪个文章发表了哪些评论，并支持评论页跳转和文章页跳转。
四、运营操作
所谓运营操作，是指运营可以从后台干涉用户的评论行为和评论结果。正向干涉包括：评论加精、评论置顶；负向干涉包括：评论屏蔽、评论删除、评论人封禁、敏感词替换等。
评论加精
支持运营挑选优质评论，在前端给予“精华”的标记，有的App也叫“神评论”、“有用”等……
评论置顶
如字面意思，将某个评论，置顶到评论列表首位，给予公示
评论屏蔽
将某条评论暂时对他人不可见。体验更好的做法，还可以通知发布评论人其内容被屏蔽，要求其修改后申请解除屏蔽，经审核后评论可重新出现。
评论删除
直接从后台将评论删除，不可恢复。
评论人封禁
通常是和“举报”关联，对于频繁发布垃圾评论者予以封禁，令其不可再发评论。当然也应该允许其申请解封。
敏感词替换
通常做法是构建敏感词库，如果评论某些文字命中词库，则将敏感词替换为“*”。
被删除/屏蔽后显示逻辑
当某条评论被删除，或屏蔽后，可以有两种做法，要么是直接删除，要么是当前区块保留，被删除文字变成“评论已删除”。尤其是主题式评论，由于某条一级评论可能关联多条二级评论，如果一级评论被删除，其二级评论是否需要全部删除，需要产品经理根据评论价值来决策。建议这种情况还是保留二级评论。
五、防呆设计
所谓防呆设计，是指需要思考如何通过产品设计，防止用户误操作。包括：
评论草稿箱
也就是说评论框输入文字，未发送前，如果误点击了取消区域，自动替用户保存当前输入文字，而再次出现评论框时，还能将之前文字恢复。这个功能还有个降级方案，就是用户取消输入框时，弹出Alert告知用户是否要取消。
评论字数提醒
当字数输入过多时，通过红字提醒用户超限，“发送”按钮置灰。
六、快捷操作
输入文字对用户而言是个高成本的事，而评论本身是个表达态度的渠道，那我们是否可以设计一些简单的交互行为帮助用户迅速表态呢？所谓快捷操作，就是针对这点的解决方案。可以是：
快速表态
在评论区设计表态按钮，比如：踩、一般、赞、太棒了，用户直接点击即可，类似投票行为。典型案例如天天快报、橘子娱乐。
评论区直接输入表情/颜文字
用户可在发评论时，选择表情图发布，或快速选择颜文字发布。像搜狐新闻、凤凰新闻、网易新闻都可以直接发表情。
七、富媒体支持
对某些UGC向的内容产品，评论区甚至支持发静态图、发音频、发GIF动图、发视频，这时也就需要对应的发布流程设计和后台存储逻辑。
八、细节支持
这里就要从用户体验角度，考虑各种特殊情况的产品细节了，我能想到的比如：
评论支持识别超链接
这里需要考虑超链接的识别逻辑（需要头部是http或https，尾部是空格进行识别），超链接的字数计算（对于限制字数的输入框，超链接可以统一为10个字符），超链接发布后的显示样式（简单的可以直接显示链接地址；好一点的显示为“链接地址”四个字；再好一点的取链接地址对于网址的title显示，如知乎）
发评论时，键盘设置问题
评论框输入评论时，需要考虑是否将“发布”按钮设置在键盘上。如果需要考虑评论换行，那“完成”键应该作为换行键，否则点击“完成”应该是直接提交。
评论点击区域细节
评论区有很多元素，需要告知开发哪些区域可点，点击跳转到哪些地方。如下图所示：
后端产品设计
一、前端需求分析
1.为什么做评论功能？
用户评论可以打通用户与用户、用户与产品之间的界限，提供双向甚至多向的沟通手段，增强产品的关系留存。评论功能不再以用户发表意见为唯一目的，同时还营造出了一种隐藏在屏幕背后的社群关系。
2.评论分类
评论可以区分为一级评论及二级评论（回复）两种，详细定义如下：
3.从用户查看/发表评论两种行为出发分析用户的使用动机
用户对评论功能的使用可区分为查看及发表两种行为，总体说来，用户查看评论核心动机在于能够有所收获，这就要求评论内容必须具有价值；用户发表评论的核心动机在于表达并能够获得反馈及得到认同。产品类型不同，查看及发表评论动机差异较大，详见如下分析：
4.从自己产品出发，详述产品功能不同用户使用动机的差异
就我们自己的产品而言，作为国企背景运营商类工具型应用，存在如下特殊性：
功能模块的多样性，评论作用有差异
评论机制多与业务办理、客服服务相结合，同时随着产品中增加了资讯类内容， 评论功能也会出现在资讯内容下；对于以上三种不同功能（业务办理、客户服务及资讯），用户使用评论动机也有所不同：
5.评论功能产品设计详述
不同类型产品的评论功能的设计也应不同，产品的最终形态是为产品功能的核心作用服务的。以下从评论功能的页面元素来分析评论区的细节设计：
（1）页面整体设计：
评论功能大体上可分为内嵌评论页及独立评论页，内嵌评论页是指评论直接展现在内容/商品下方的页面的设计方式，如淘宝、今日头条、微博等；独立评论页是指需要跳转才能看到评论的页面设计方式，如知乎等。评论页面整体设计除了展现样式以外，还涉及到逻辑的设定，比如一级评论是按照时间顺序排列还是按照点赞数倒叙排列，当发表时间一致点赞数量一致时该如何排序，都需要产品经理根据自己产品的特性来决定。
就我们自己的产品而言，由于页面来源和性质不同，一部分页面为自有页面，可进行改造增加评论区，因此设计成嵌评论页；一部分页面为外部H5页面，由于无法修改页面内容，所以增加了留言浮窗，需要跳转后可以查看及发表评论。
（2）发表评论入口设计：
发表评论的入口可区分为发表一级评论和二级评论的入口。
发表一级评论的入口一般会存在于页面当中，位置可能是常驻页面某个位置，如常驻在页面底部，如网易云音乐、今日头条等，或者是以悬浮框形式常驻页面右下角，如百度知道，发表评论的引导性较强；也可能是在页面中央，如公众号及得到“写留言”入口，放置在页面中央，需要对内容有一定的了解后才可有发表评论；亦或需要完成某种行为才可发表评论，一般发表评论入口在其他页面，如淘宝，需要在我的-待评价中发表评论，一级评论的发表入口设计可根据自己产品需要自行决定；
发表二级评论的入口可跟随内容露出留言按钮，引导性较强；也可通过点击交互给出回复入口，引导性较弱。二级评论的发表入口设计也需要根据自己产品的需要自行决定。
（3）评论内容输入页面设计：
按照评论内容的长短可将评论内容区分为长评和短评两种，页面交互方式可分为当前页输入和跳转后输入两种方式：
针对较长评论输入框占位需要较大，甚至可以占用整页空间，可随时查看之前输入的内容，以便形成章节体系，如知乎的回答问题页面，长评输入一般需要跳转到新的页面，但需要在跳转后的页面中提示用户是针对何内容发表的评论，因此一般会展现出文章的主题或者商品名称等。
针对于短评，输入框给出一行空间即可，如今日头条的评论，由于用户发表的内容本身也不会很长，所以输入框无需很大。短评的输入框一般在当前页即可。
在豆瓣书评中，按照评论长短区分了短评和讨论两块区域，美妆类产品“闺蜜美妆”可针对产品发表长评或者短评，满足不同受众的不同需求。
除以上交互方式以外，输入框中可输入的内容可以是文字、图片、甚至是视频、音频等，对于电商类产品可以增加星级评分等元素。
（4）二级评论样式设计：
二级评论设计主要分为两种形式（具体须根据产品特性及二级评论数量决定采用何种展现方式）：
其一为折叠式，以一级评论为主，展示所有二级评论，优点是一级评论及对应的二级评论可以形成清晰地对应关系，上下文联系紧密；缺点为评论展示的位置受限，假设如果二级留言内容较多，用户发表的评论需要多次点击才能展现出来。同时二级评论的点赞限制较多，如下图从百度知道评论区可以看出二级评论难以给出点赞区域。
针对折叠式，一般优先露出n条二级评论，其他评论可在当前页面中无限展开或需要跳转到新的页面查看全部，如微博、百度贴吧等。如果二级评论和一级评论之间联系紧密，比如问答类产品建议采用该种方式，如果二级评论数量较多建议采用跳转到新的页面查看全部二级评论的交互方式。
其二为平铺式，打破一级及二级评论的差异，将所有评论平铺开，缺点是一级评论和二级评论之间的上线文联系较弱，优点为展示位置较灵活，不必须折叠在一级评论中，如网易新闻。
（5）互动机制（点赞、回复入口、认可、水等）设计：
互动机制可分为强互动和弱互动两种方式：
其中强互动为回复他人评论，弱互动为点赞、认可、水等。反馈机制是评论区必备设计，可增强用户之间的联系。用户可根据自身需要选择强弱互动方式。不同产品之间互动机制有所差异，一般评论区标配的互动机制包含回复（包括用户之间回复及用户与运营人员之间的回复）及点赞这两种。
对于垂直社区类产品，如PMCAFF中可对他人评论进行认可、水、分享等。其他的交互逻辑，比如是否支持用户回复自己评论、是否支持他人删除自己留言、是否可对二级评论进行点赞等逻辑可以根据产品需要自行设计。
（6）评论功能分区：
如网易新闻将评论区划分为热门跟帖和最新跟帖两个区域，豆瓣书评分为评论和讨论区两个模块，淘宝区分评论区和问大家区，产品经理可根据产品特性及评论数量决定是否需要分区。
（7）其他关联功能设计：
与评论功能紧密相关的功能为消息提醒功能，对于用户之间互动方式的不同，提醒方式也应做差别处理，如针对运营人员或者其他用户的的回复，这种强互动方式需要及时推送，以便活跃氛围，并且可在消息提醒中点击查看完整回复内容、可快捷回复、可跳转回发表评论页面等；而针对点赞、认可等其他弱互动方式，就无需进行推送，支持跳转回发表评论页面即可。
二、后台需求及设计
评论功能不仅涉及到前端交互也涉及到后台逻辑，以下为根据自己产品整理的后台设计思路（备注：我们的评论区名称为留言区）：
1、后台需求汇总
就我们自己产品而言，具有公司具有国企背景，产品具有平台属性，不仅to c，也要to b，因此在满足用户的需求的同时也要满足各省运营人员的需求，由该属性出发，后台需求汇总如下：
a.由于公司具有国企属性，又是运营商性质，因此用户评论内容倾向不确定（可能会有辱骂等内容），因此增设审核机制，以确保内容的健康性。审核机制包括机器审核和人工审核两种，其中人工审核需要在留言后台完成，具体说来，对于健康内容可审核通过展现在用户前端界面中，对于存在问题的内容可审核不通过，运营人员可通过私信方式回复用户，从而最大程度上满足用户个性化需求。而且对于不同功能模块审核需求不同，如业务办理模块可能发生用户辱骂等内容较多，需要审核，而资讯模块，由于不涉及到办理等与金钱挂钩的敏感问题，因此审核需求不大。
b.由于用户希望能够在产品中获得相关问题答案，需要运营人员可回复用户留言，因此在后台增设回复机制，其中回复功能的设计逻辑包括是否可以多次回复、回复后是否可以删除等，根据各自产品特性自行决定。
c.由于用户反馈问题较为集中，因此增设置顶功能，提高用户使用效率。在设计置顶功能时特别纠结以下两点：（1）是否需要像大众点评一样，将优质留言盖上“优质点评”的标签？（2）是否需要将置顶的内容永远置顶? 最后还是希望业务办理类模块能够更加公正客观（至少看起来是这样的），而非用“优质”标签来强迫用户阅读，而且不希望用户在多次进入留言页时看到相同的置顶内容，所以采用了通过后台调整点赞数的方式，使得置顶内容能够暂时排序第一位，至于能够排在第一位多久，还需要依靠其他用户的投票；
d.由于公司架构区分总部和各省分公司，因此需要划分角色权限，在留言后台可设置总管理员和分省运营人员两种角色，不同角色拥有的权限不同：总管理员可看到全国内容、可对留言进行复审、并且可看到分省运营人员的操作记录，实现整体上把控整个产品的运营的质量，分省管理员仅可审核、回复本省用户发表的留言。角色权限划分可使功能使用范围更加明确，有助于评论功能健康发展。
e.由于公司框架特性，带来的另一个问题是针对全国用户可见内容——业务办理也好，faq内容也好，由于不同省份之间规则差异，不同省份用户之间会形成比较，容易造成用户投诉，因此留言可见范围可勾选——实现用户留言及运营人员回复可针对用户自己可见、可对本省用户可见及全国可见。
f.其它常规后台需求包括时间筛选、功能模块筛选、省份筛选、审核类型筛选、回复类型筛选、置顶类型筛选、留言内容搜索等，能够满足运营人员精准化查找的需求。
2、前端与后台的关联
整理好产品前后台关联逻辑有助于后台产品的设计，如下流程图为我整理的自己产品的前后台逻辑：
3.后台设计最终原型
根据以上分析，输出留言后台最终产品产品原型，之后开发并优化迭代。
