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

　　最近工作中刚设计完一版后台评论管理功能，趁着热乎，笔者就把整理了一下整个产品设计过程，形成了这篇文章。enjoy
　　文章描述了通过分析目标用户以及目标用户的使用场景，从而挖掘用户需求；再将需求转化为功能实现的过程。
　　第一步
　　通过分析目标用户以及目标用户使用场景，发现产品需求。
　　（1）目标用户
　　评论管理功能目标用户是运营人员；
　　（2）目标用户操作场景
　　管理线上不当言论：评论作为UGC内容，即使系统有对其做敏感词自动过滤，但也会有技术灰点，所以后台提供启用禁用功能，供运营灵活人工管理评论内容；
　　便于统计和引导运营方针：通过统计，方便运营发现有舆论性的内容和领袖用户，从而为运营方针提供帮助；
　　便于热点制造：后台提供评论点赞等操作，方便运营与用户发生互动，进而调动用户活跃度和积极性；
　　为责任追踪提供有力证据：作为UGC内容区，评论后台记录用户每一条评论，以便为激烈讨论而产生的矛盾，提供责任追踪证据，保证社区的良好秩序。
　　第二步
　　从定义字段、设置查询条件以及操作行为方面，分析如何将已发现的需求整合为产品功能。
　　1。定义后台表格字段：包含内容列表展示字段和详情页字段定义
　　（1）内容列表展示字段定义
　　设计原理
　　为方便运营浏览和操作，从评论信息角度分析出最重要特性作为列表字段。
　　设计步骤
　　步骤1：列举全部评论信息字段，如图：
　　步骤2：以关联强弱为基准对字段做优先级排序：
　　评论内容所属资源、评论回复内容等字段属于评论本身外的第三方内容，与之关联较弱，所以优先级降低。其他直接关系关联性最高，优先级也随之最高，因此最终排序如上图。
　　（2）详情页展示字段定义
　　设计原理：对评论信息相关的全部字段做优先级和逻辑层次划分，并展示字段的详细描述评论信息。
　　最终页面呈样式如下：
　　2。设置查询条件
　　从评论者、所属资源、评论内容本身三方面做查询条件设置。
　　设计原理
　　从运营操作全场景分析，设置查询条件。
　　设计步骤
　　步骤1：从评论操作、评论属性、评论者三方面列举出相关字段，如下图：
　　步骤2：本着简化运营操作和聚集同属性内容的原则做查询条件排布：
　　排布规则1：可以直接选择的就不要用户输入，如所属资源类型和资源频道以及评论信息状态；
　　排布规则2：能形成互斥条件的组建互斥组，如评论信息状态。
　　最终排布如下：
　　3。操作：包含对单条数据和多条数据操作行为分析
　　（1）单条数据：支持对单条数据进行禁用和启用、查看详情以及手动加赞的操作。
　　设计原理：从增、删、改、查方面列举出运营使用的场景，再对各个场景的使用成本做减法，保证以最少步骤完成常用功能操作。
　　这里有亮点需要特别说明：
　　在操作中，我省去了编辑页面，原因是我发现运营对评论信息的修改操作除了禁用和启用，只剩下查看和手动点赞，而恰好这些字段在列表字段中，所以直接在列表页完成操作即可，从而运营省去必须进入编辑页修改的流程，提高了运营效率。
　　本期未实现删除评论信息功能，一是由于目前客户端刚上线，评论内容很少，正是聚集评论，营造社区氛围的阶段；二是目前线上的评论大多数都来源于运营手动评论，删除使用场景少；三是删除功能实现成本也较低，便于后期增加。
　　所以本期没有实现的必要性。
　　（2）多条数据：支持对多条数据批量禁用和启用的操作者；支持列表从用户点赞、运营点赞、被评论数、评论时间三个维度单独排序。
　　这里说明一下为什么要对运营点赞做排序？便于区分评论的真实性，防止运营为提升运营指标，在后台大量自加赞，而埋没了用户点赞功能，导致真正受用户热捧的评论下沉现象。
　　4。所以最终页面如下：
　　完结！欢迎大家沟通交流