B端报表设计三板斧
作为B端产品经理，报表设计是日常工作中占比很大的一块内容，随着接触的报表逐渐增多，慢慢地有了些心得，今晚终于得空，早早地打开电脑，将B端报表设计的一些心得记录，如有错漏之处，欢迎大家指正。
由于本人目前主要负责的产品为企业园区消费系统，园区人员通过刷卡、二维码在园区食堂进行消费，目前也支持更高级的人脸消费，所以本文的列举的报表也来自我的日常工作。
拿一个日常工作中接触的报表为例：商户餐次统计表，顾名思义为统计园区所有商户在每个餐次的消费情况以及汇总数据。在接到此报表需求后，将要如何进行设计，我将B端报表设计总结为如下三板斧：
第一板斧：业务场景
要满足业务方的需求，首要弄清楚报表使用的用户角色有哪些？不同的用户角色需要干什么？
通过与园区管理方接触了解，在经过一天的营业之后，食堂老板会问管理方在哪里可以看到今天食堂进账多少？有多少人在食堂吃饭？
或一个自然月中，食堂老板也需要知道食堂进账多少，有多少人在食堂吃饭。
而作为园区管理方， 需要了解哪几家食堂的营业额最高，吃饭的人数最多，如果哪家食堂数据不好看，则要去看下是哪里出了问题。是饭菜质量还是服务？来决策是否需要更换食堂服务，提升园区人员的满意度。
弄清楚了业务场景，接下来就到了报表的设计阶段了，这个时候需要弄清具体的业务规则，按照什么规则来设计。
第二板斧：业务规则
基本的业务规则不再进行赘述，这边主要讲下报表的特殊业务规则。
常见的为实时查看数据，在此报表中食堂老板需要实时查看当天的营业数据，主要是干什么呢？
因为食堂老板需要根据每餐的吃饭人数和进账来进行第二天的备菜，如报表不能实时，则无法为第二天该备多少菜提供数据支撑。
报表要实现实时，如果为小数据量则开发在实现时可直接查询所有数据进行统计。
但如果是大数据量，像园区一般都是为上万人，一日三餐，每日三万用餐记录数据，一个月就是90万用餐记录数据，对于非当天的数据则需根据基本业务逻辑每日对前一天的数据进行统计，这样在查询非当天的数据时系统便不需要进行大量的运算，直接从统计好的历史数据进行查询，至于当天的数据，则进行实时运算，最后将两部分数据拼接在一起在报表展示，从而实现大数据量的报表实时查询的业务。
在业务规则都定好了之后，接下来最后一板斧就主要体现在用户使用方面，如何给用户呈现更好的体验。
第三板斧：交互规则
基本的交互规则不再进行赘述，特别要注意的是特殊交互规则——导出，主要是大数据量导出问题，这边主要有几个方式进行处理：
- 限定导出区间：通过控制时间范围，从而减少导出数据量。
- 下载队列处理：当导出Excel后，将要导出的Excel加入到一个下载队列中，服务器根据导出时间的先后顺序进行逐个进行下载，具体前端呈现为一个下载列表，显示文件大小、当前下载速度、文件下载进度、让用户等待下载完成便可以打开Excel查看数据。
- 即使通过以上两点来限定，也有可能由于数据量过大而导致服务崩溃的出现，技术处理为增加独立的文件服务器，单独处理导出Excel等文件服务，即使下载异常而导致文件服务器崩溃，也不影响业务系统。
不知不觉花了3个小时，要想写一篇文章还是需要下点功夫的，更别提要写一篇好文章了。B端报表设计中想必还有不少的问题，欢迎各位指正交流。
本文作者 @目土土
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
