后台报表如何设计?(2)

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解一下

上次写了一篇文章,从用户需求、 报表设计这两个方面简单地介绍了一下管理系统的报表设计的大致框架。但其实关于报表,除了框架,填充框架的细节也很重要。所以在项目填坑的过程中,文章也来填坑了。这篇文章会着重于报表设计中的那些需要注意的细节点。

报表权限

报表是各类数据的汇总和可视化,展示着公司运营、财务、业绩、人员的重要数据。在一定程度上,报表是公司的“重要机密”。所以报表并不是谁都能看得到的,报表需要设置查看权限。

和业绩有关的运营报表一般只有老板或管理层才有权限查看;涉及到钱的财务报表更甚,大部分只有老板、经理、财务三个角色可以查看;而最普通的角色,比如:公寓管理系统的管家,有权限查看的报表应该只有个人的业绩了。

所以在设计报表的时候,首先应该确定好,系统里哪些角色/职位能查看这个报表。

在梳理PRD的时候,首先应该配置好该报表模块的查看权限。当然不同系统的权限配置方式会有不同,有些系统为了省事,直接让开发配置好,权限固定下来。

比如说:报表模块只能【经理】这个角色才能查看,那需要开发在逻辑上进行固定:只要系统角色是【经理】的就能查看报表。这样的话,使用系统的运营商就不用费心了。到时候需要改的时候,直接让开发修改。当然,在实际使用中,修改的频率并不是很高。

但是有的运营商想要权限配置更灵活一些,同时还希望自己能够配置权限。那这个时候,谁查看报表那就是运营商自己来配置了。当然一开始会根据业务给出一个默认配置,但是运营商能够自己进行编辑。

举个例子:如果运营商想让店长也能看报表,那他在店长的可查看模块下勾选【报表】就好了。配置灵活,也减少了软件开发商的维护成本。

数据类别

报表的数据主要分为:历史数据和实时数据。

历史数据主要是查询历史时间的数据,数据是静止的。系统的统计报表都是历史数据,数据大部分是不变的,但后台会有定时任务拉取更新数据,基本上是一天更新一次。

而实时数据不一样,实时数据是时刻都在变动的。大部分使用实时数据的表格是用来监控需要实时观察的数据,比如说:电量设备监控表、降雨量监控等等。当然,对于实时监控数据,用户会更习惯看监控图,因为监控图更直观明了。

但是如果关注具体数据的话,表格还是有必要的。实时数据表格一般没有时间选择,用户看到的数据就是当下的最新数据。但是实时更新的话,数据压力也很大,更多的会根据数据上报系统几分钟更新一次。

实时监控数据表

实时监控数据图

数据操作

考虑了数据本身,还需要考虑用户能对数据做哪些操作。最常见的操作当然是增、删、改、查。查询数据已经在上一篇文章中讲过了,剩下的新增、删除、修改,则需要根据用户需要和图表性质增加功能。

当然还有一些小功能,比如说数据的排序,除了默认的排序外,用户也有根据自己要求进行排序的需求。还有则就是分页和页面展示数据条数的选择等等,在设计的时候都要考虑到。

数据查询压力

在报表模块,最让人害怕的就是数据查询压力。有可能你辛辛苦苦设计好、测试完成、然后上线了,最后这个模块崩掉了,用不了,这就很让人绝望了。

一般来说,这有可能会是因为查询人数多、查询次数过于频繁,还有可能和数据的存储方式有关。如果查询人数多、查询次数过于频繁而导致的数据压力大,那么这时候就需要对数据查询进行限制。

如果是历史数据,则需要限制数据查询时间,在选择时间的逻辑上增加限制。比如说:时间选择最早只能选择两年前到当天的数据。这样的话,在数据上的数量上限制了可查询的数据,减小了查询压力。而实时数据的限制则会更甚,大多是【今天】、【昨天】、【最近3天】、【最近7天】,更远也只是【最近1个月】。

当然如果是数据存储方式所导致数据查询压力大,那可能需要改变数据的存储方式。历史数据当然是存在数据库里的,数据是比较稳定的。但实时数据则不是,实时数据则没办法存在数据库了,它是直接从数据上报系统中拉取数是实时更新的。

同时,从数据量上来比较,历史数据是一天上报一次,数据量比较少,而实时数据则是每隔几分钟上报一次,数据量十分巨大,对存储压力和查询压力来说,都是一个不小的挑战。

如果遇上实时数据表格上线后崩掉了的情况,可以尝试和后端沟通,能不能去掉一些增加数据查询压力的功能,比如:表格里的手动数据排序功能,或者改变一下数据的存储方式,采用更稳定的数据存储。那如果技术方便没办法解决,那可能需要产品自己思考改变方案,采用其他方案来满足需求。

导出报表

虽然上一篇文章也提到导出报表,但只是简单地带过。其实导出报表功能看起来虽小,但其实内里也是有点复杂。数据导出分为同步和异步两种。大部分我们导数据都是同步导出,点击导出,然后就直接下载到本地了。

但是如果数据量大,数据导出时间较长的话,在设计报表导出时还是需要选择异步导出。创建的导出任务会展示在【导出任务】里,用户可以查看导出进度,导出完成后即可下载到本地。

对于有些用户来说,同步导出会让人感觉到直接、“快”,而异步导出会让人感觉“慢”且麻烦。但是异步导出其实会更稳定。而且如果导出时间过长的话,同步导出会给人一种“卡死”了的感觉,而异步导出由于会展示进度,所以用户体验会更好。采取哪种导出方式,根据数据的实际情况来就好。

此外,在导出任务栏里的设计还有一个细节。例如:排序和历史任务。排序一般都是创建时间由近及远,但是我们系统反人类的一个点是由远及近(无奈摊手)。还有一个历史任务的查看,我们系统还有一个槽点是,只要是这个员工账号在系统中创建的导出任务都会展示在导出任务栏中。(What?难道不应该是我在这个页面创建的导出任务才会显示在这个页面的导出任务里么?)

我能在所有页面的导出任务里看到在所有页面的导出任务,非常大一统的感觉。希望大家在做设计的时候,记得避免这两个坑。

以上这些就是报表设计的第二篇,相对于简单地第一篇,这篇更注重于一些关于数据的细节。两篇结合起来,应该可以算是一篇较完整的报表设计了。

希望大家能够早点脱坑,设计出满意的报表。

相关阅读

后台统计报表如何设计?

#专栏作家#

异彩,微信公众号:一只蜗牛慢慢跑,人人都是产品经理专栏作家。从事房产管理系统的产品工作,关注To C产品的交互设计、运营、结构设计和商业模式。在成为一名优秀的产品人的路上努力前行。

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
6人打赏
评论
欢迎留言讨论~!
  1. 不错,讲得非常细致了

    回复
  2. 现在在做公司的报表,看了文章有些点还是很受用~谢谢啦~

    回复
    1. 希望能帮到你☺️

      回复
  3. 我怎么觉得能在统一的地方查看所有页面的导出记录是正确的设计呢?比如在页面A、B执行了导出,系统异步去处理,用户去其他页面做其他事,等到导出任务都执行完了,直接在一个地方下载所有导出结果不好吗?

    回复
    1. 你这个也是一个思路啦 :mrgreen: 但是我个人更偏向于只展示该页面的导出内容,这样的话,导出列表里的任务比较少、也比较统一。

      回复
  4. 有些细节写的很好。不过有个小建议:有个人信息的地方最好打上马赛克(如文中的图片)

    回复
    1. 抱歉抱歉,没有注意到。虽然是测试数据,但还是希望大家不要去打电话骚扰。 :arrow:

      回复