后台功能设计之评论资源管理

~M~
17 评论 25946 浏览 170 收藏 7 分钟

最近工作中刚设计完一版后台评论管理功能,趁着热乎,笔者就把整理了一下整个产品设计过程,形成了这篇文章。enjoy~

文章描述了通过分析目标用户以及目标用户的使用场景,从而挖掘用户需求;再将需求转化为功能实现的过程。

第一步

通过分析目标用户以及目标用户使用场景,发现产品需求。

(1)目标用户

评论管理功能目标用户是运营人员;

(2)目标用户操作场景

  • 管理线上不当言论:评论作为UGC内容,即使系统有对其做敏感词自动过滤,但也会有技术灰点,所以后台提供启用/禁用功能,供运营灵活人工管理评论内容;
  • 便于统计和引导运营方针:通过统计,方便运营发现有舆论性的内容和领袖用户,从而为运营方针提供帮助;
  • 便于热点制造:后台提供评论点赞等操作,方便运营与用户发生互动,进而调动用户活跃度和积极性;
  • 为责任追踪提供有力证据:作为UGC内容区,评论后台记录用户每一条评论,以便为激烈讨论而产生的矛盾,提供责任追踪证据,保证社区的良好秩序。

第二步

从定义字段、设置查询条件以及操作行为方面,分析如何将已发现的需求整合为产品功能。

1. 定义后台表格字段:包含内容列表展示字段和详情页字段定义

(1)内容列表展示字段定义

① 设计原理

为方便运营浏览和操作,从评论信息角度分析出最重要特性作为列表字段。

② 设计步骤

步骤1:列举全部评论信息字段,如图:

步骤2:以关联强弱为基准对字段做优先级排序:

评论内容所属资源、评论回复内容等字段属于评论本身外的第三方内容,与之关联较弱,所以优先级降低。其他直接关系关联性最高,优先级也随之最高,因此最终排序如上图。

(2)详情页展示字段定义 

设计原理:对评论信息相关的全部字段做优先级和逻辑层次划分,并展示字段的详细描述评论信息。

最终页面呈样式如下:

2. 设置查询条件

从评论者、所属资源、评论内容本身三方面做查询条件设置。

① 设计原理

从运营操作全场景分析,设置查询条件。

② 设计步骤

步骤1:从评论操作、评论属性、评论者三方面列举出相关字段,如下图:

步骤2:本着简化运营操作和聚集同属性内容的原则做查询条件排布:

  • 排布规则1:可以直接选择的就不要用户输入,如所属资源类型和资源频道以及评论信息状态;
  • 排布规则2:能形成互斥条件的组建互斥组,如评论信息状态。

最终排布如下:

3. 操作:包含对单条数据和多条数据操作行为分析

(1)单条数据:支持对单条数据进行禁用和启用、查看详情以及手动加赞的操作。

设计原理:从增、删、改、查方面列举出运营使用的场景,再对各个场景的使用成本做减法,保证以最少步骤完成常用功能操作。

这里有亮点需要特别说明:

  • 在操作中,我省去了编辑页面,原因是我发现运营对评论信息的修改操作除了禁用和启用,只剩下查看和手动点赞,而恰好这些字段在列表字段中,所以直接在列表页完成操作即可,从而运营省去必须进入编辑页修改的流程,提高了运营效率。
  • 本期未实现删除评论信息功能,一是由于目前客户端刚上线,评论内容很少,正是聚集评论,营造社区氛围的阶段 ;二是目前线上的评论大多数都来源于运营手动评论,删除使用场景少;三是删除功能实现成本也较低,便于后期增加。

所以本期没有实现的必要性。

(2)多条数据:支持对多条数据批量禁用和启用的操作者;支持列表从用户点赞、运营点赞、被评论数、评论时间三个维度单独排序。

这里说明一下为什么要对运营点赞做排序?便于区分评论的真实性,防止运营为提升运营指标,在后台大量自加赞,而埋没了用户点赞功能,导致真正受用户热捧的评论下沉现象。

4. 所以最终页面如下:

完结!欢迎大家沟通交流~

 

本文由 @pangTT 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Pexels ,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 123123

    来自江苏 回复
  2. 运营点赞其实就是手动调整数字吧。不过和运营打交道多日,他们不会通过输入所属资源ID去搜索的。而且也不太可能去下功夫记。列表直接显示评论所属资源标题会比较便捷。

    来自广东 回复
  3. 运营点赞是给运营人员留的修改点赞数的入口吗?

    来自陕西 回复
    1. 是针对运营侧编辑的点赞数入口,用户侧实际点赞数不能编辑。

      来自北京 回复
  4. 您好!请问启用和禁用按钮是可以随时切换的吗?这样会不会页面造成逻辑太多,如果启用后不准再变成禁用,会不会不合理?最近我也在做评论管理,产品小白,实在是理不清了 😥

    来自江苏 回复
    1. 这个功能是运营做评论管理的,应该以方便运营操作为核心。除了考虑评论管理过程中,运营的误操作外,也需要考虑可能会遇到一些时下政策风险,遇到对部分评论做暂时关闭,所以建议是启用和禁用相互切换的。同时针对单列数据的管理,只做单列数据刷新,不用整体页面刷新。

      来自北京 回复
    2. 您好,有两个疑问请教下您:
      1.如果禁用用户某条评论,前端用户是否需要提醒?您的评论涉及**以被禁用?还是直接不显示的?
      2.主评论被禁用,关于 这条评论的回复是否全部隐藏删除?是否全部通知用户并隐藏,还是默认隐藏合理?

      来自广东 回复
    3. 你好!一个评论功能可以做得复杂,也可以简单。没有唯一答案,建议根据自身产品用户规模以及产品调性做选择。
      问题1:禁用某条评论,是否提醒用户?
      答:现在市面上更多的解决方案是不提醒,只有评论者可见。但个人觉得还是需要根据全局做判断。如果评论涉及积分等奖励机制,为了维护整个系统健康,建议可以根据评论危险性做等级判断,评论危险性较弱,用户可能不是故意为之,则可以做提醒修改;
      问题2. 主评论被禁用,关于 这条评论的回复是否全部隐藏删除?是否全部通知用户并隐藏,还是默

      来自北京 回复
    4. 2323

      来自湖南 回复
    5. 9090

      来自湖南 回复
    6. 这是在测试吗

      来自吉林 回复
    7. 回复信息看看

      来自吉林 回复
  5. 觉得有点简单,评论的层级应该会有很多,可以对每一条评论都回复,这里只显示一级评论吗?二级 三级评论那些呢?

    来自广东 回复
    1. 评论不区分二级和三级,只针对上级和下级。文章中有说明~

      来自北京 回复
    2. 您好,咨询个问题:
      针对主评论下的回复,后台这边是直接在列表展开/收起的展示方式还是点击查看评论详情的方式好些。

      来自北京 回复
  6. 果断收藏!

    回复
  7. 新技能get 原来数据库库字段设计可以用思维导图

    来自山东 回复