数据分析报表设计开发要素.docx

数据分析报表设计开发要素.docx

《数据分析报表设计开发要素.docx》由会员分享，可在线阅读，更多相关《数据分析报表设计开发要素.docx（11页珍藏版）》请在冰豆网上搜索。

数据分析报表设计开发要素

数据分析报表设计开发要素

1.背景

随着企业对数据价值的认识越来越高，数据分析类项目也随之增加，尤其是近一段时间大数据时代的到来，数据分析已经是必不可少的内容。

其中数据分析结果以报表形式呈现给用户，是各项目的重要组成部分。

但是这些报表的用户的使用情况如何，用户是否满意？

2.报表的重要性

作为数据分析项目，包括了原始数据获取及处理，数据分析整理，报表展现等多个部分组成，但是从用户角度来讲，他只能看到报表展现，他看不到项目的后台处理过程。

即使你后台做的再好，数据再怎么稳定，处理速度再怎么快，数据分析再怎么有价值，但是不能通过报表展现呈现给用户，还是没有用。

所以报表的设计就在数据分析项目中显得非常重要。

3.报表的价值

报表的价值并不是实现报表的过程花了很多的时间，也不是实施的过程中用了多么先进的技术。

所以不要过分的强调你做了什么，而是要关注你为客户带来了什么。

其实报表给用户带来的价值最多的体现在如下两个方面：

3.1.节省人力成本

节省人力成本非常好理解，那我们要做的就是通过报表节省更多的人力成本。

做用户需要的内容，那么如何才能知道我设计的内容用户喜不喜欢了，主要从两个方面来衡量，一个是用户的粘性，一个是用户的数量，只要用户愿意经常使用说明我们做的东西对他有帮助，既然有帮助可能就能节省人力成本，而用户的数量越大说明节约的人力成本越多，自然而然的我们的报表价值越大。

3.2.辅助分析决策

通过我们的报表分析能够使用户发现以前很难发现的问题，并且发现问题后，不再凭感觉拍头脑决策，而可以根据报表中的数据来支持决策。

决策避免了感官，更加注重数据支持和理性决策。

一个正确的决策到底能够该用户创造多大的价值这个还真不好衡量，但是我们可以粗略的认为用户级别越高决策的价值越大，所以我们努力的方向就是不仅仅一线的用户愿意使用我们的报表，中层领导干部甚至是高层领导也愿意使用我们的报表分析。

使我们的报表分析价值最大化。

4.报表的设计要素

4.1.以人为本

报表可以认为是我们的一种服务手段，我们的目标就是用户觉得有价值，愿意用。

所以有时候不是我们设计以及开发人员觉得好就好，而是要从用户角度出发，让用户觉得好才是最重要的。

ü高层领导：

简洁明了，少操作，直接出结果。

作为高层领导，没有太多的时间去深入研究报表的细节，因此报表要直接把结果以最简单的方式呈现，并且尽量减少操作，能滚动页面的就不要另外加页标签。

ü中层领导：

重点突出，分析深入

中层领导，一般起到承上启下的作用，既要向领导汇报，又要向下安排具体工作。

因此高层领导知道的内容中层领导必须知道，当然必须是权限范围内的信息，要不然高层都了解的问题中层领导不知道肯定是工作不到位的体现，并且还要对问题有深入的分析，一方面向领导汇报问题的解决方案，一方面要先下安排工作，解决具体问题。

ü一线人员：

解决具体问题，注重实用性

作为一线人员，不需要太多的分析思想，也不需要重大的辅助决策，他们更关心的是帮组他们提高工作效率，解决实际具体的问题，所以要求使用简单，有针对性，这才是最重要的。

4.2.目标明确，

做一张表每一个图，都要考虑这个图主要起到什么作用，能为用户了解哪些信息，发现哪些问题，目前的指标选择是否合理，往往目标明确以后才能选择最好的指标（这里的指标说的是衍生指标，例如由用户数衍生的用户增长率等等）

结合报表的上下文，每一部分在整体的报表系统中又是起到了什么作用。

4.3.重点突出

我们通过表格或者图形向用户传达的信息一定要明了，千万不要让用户去找，事实上一般我们的分析系统很多的功能都不需要用户每天进行访问的，所以报表的使用者对于报表的结构不一定非常熟悉，特别的系统刚上线的时候，如何能够让陌生的用户很快的了解报表中有价值的信息，方便用户理解就变得非常重要。

例如表格中重点的指标尽量靠左，如果是排名或者预警要以特别的颜色或者标志进行区分等等。

4.4.业务划分为主，指标划分为辅

我们服务的客户也有他们的工作，他们的工作内容也往往是围绕业务展开的，因此一个用户往往需要的指标是多方面的，例如即需要用户信息，有需要销售金额信息，这些信息都和他的工作密切相关，因此设计的时候应该以业务为主，这样共更容易满足用户的需求，而以指标划分为辅能够使指标归类更加明确特别是权限控制更加合理，并且可以把指标划分作为分析的中间层数据，以备后续功能拓展使用。

以业务划分为，产品，运营，销售，客服，市场，财务，高层领导等进行划分

以指标划分，用户类指标，金额指标，流量类指标等等。

5.项目实施要点

5.1.确认使用对象

使用人员的不同决定了报表的设计风格的不同，同时也是报表项目实施前项目价值的有效评估，知己知彼百战不殆，因此这一块是非常重要的。

特别是有些项目客户安排了具体项目接口人，他是所有需求的接口，但是他本人并不一定是报表的直接使用者，所以要尽量获取报表直接使用人的具体信息，甚至想办法获取第一手的报表使用者的直接需求。

5.2.挖掘业务需求

为什么是挖掘需求而不是确认需求？

一般来讲做其他的项目，客户提出的需求我们只要针对可行性进行需求确认即可，尽管可能要确认多次，但是我们的重点确实是确认。

而数据分析报表类需求，也可能是项目的特殊性，一方面用户有想要的东西，但是提不出需求，另一方面用户提出的需求与其实际想要的东西有差距，为了能更明确的知道用户原始的目的，我们必须要挖掘用户的需求，利用我们的专业知识进行引导，帮助用户完善需求，而不是简单的确认需求。

5.3.缩短开发人员和用户之间的距离

报表的设计对用户体验有很大的影响，同样的开发也有很多细节也影响用户的体验，毕竟开发人员才能实际接触数据，由于数据的多样性，有很多问题在设计上是没办法完全想到的，因此需要开发人员也要了解用户的原始需求，根据用户的原始需求对于设计上的不足提出自己的开发意见，毕竟作为项目组成员考虑问题的角度不同，有很多时候这些意见还是非常重要的。

一般项目团队不大的时候，可以适当的让开发参与各阶段的项目设计评审，以及一些直接或者间接的用户交流（比如用户交流会议纪要）；其次提交给开发需求详细设计的同时，最好能提供用户的原始需求，以及相关的原始需求资料，帮助开发在碰到设计上的问题的时候可以提出自己的意见。

5.4.提高开发人员的报表设计水平

开发人员不仅能够按照产品设计的要求完成产品的开发，同时也能根据开发自身的优势（了解底层数据），参与到报表的设计和完善，只有开发人员具有较强的报表设计能力，才能保证提出的设计意见是客观的，对满足用户需求有帮助的。

5.5.加大评审力度

报表项目的需求变更几乎是其他项目的2.5倍，这是由项目本身的特点决定的，因此在需求设计的时候要不断的进行评审，拷问每一个图，每一个表，每一个字段到底能帮助用户做什么，评审通过的设计才能全力开发。

可以用固定时间节点评审和临时性评审相结合的方式进行。

5.6.建立报表使用监控，加大回访

监控包括两个方面：

报表管理的监控，使用情况的监控

报表的管理监控可以第一时间发现报表系统的运行过程中出现的问题，并且及时跟进解决，保证用户的友好体验。

用户使用情况监控可以使我们对用户的报表使用情况更加的了解，发现用户应用和我们的预期是否存在较大的差别，更好的发现我们报表设计的不足，及时的对报表进行改进。

了解用户使用过程中的问题，主动询问，已达到修改的目的（实际上可能成为项目的二期需求）

5.7.不断修改使报表不断完善

样式和内容：

用户很多情况下是看到报表以后才会有进一步的想法，可能是发现原有功能的问题或者不足，也可能是想到了新的功能，我们要做的就是逐渐的摸索用户的使用习惯，不断丰富用户的内容需求。

数据质量：

报表的数据质量受多方面因数影响，原始数据的因素，需求定义的因素，程序开发的因素，业务系统变更的因素等等。

一开始就要求报表数据质量百分百正确是不可能的，尤其是报表相对比较多的时候，因此要想达到非常完美的数据质量，需要不断修改和完善，查找问题原因，并设计修改方案，开发和测试，这将花费比较多的时间。

5.8.保证用户粘性

报表的价值体现有时是连续性的，有时是间歇性的，有时是一次性的。

尽量提高报表中体现连续价值，或者间歇性价值的功能模块的比例，适当的做一些价值非常高的一次性分析内容。

连续性价值：

例如异常预警监控，一线人员的服务支持系统

间歇性价值：

例如月度考核相关分析

一次性价值：

例如某次营销效果的分析

6.报表设计常见问题

6.1.内容丰富重点不突出

一张报表中涵盖的信息很丰富，字段很多，记录数也很多甚至可以进行翻页，但是这样的一个报表，用户的着眼点在哪里，哪些才是整张报表的核心内容必须突显出来。

尽量不要让用户自己去分析，自己去查找需要的内容。

把用户最需要的东西放在最显著的位置，并且进行突出显示。

有必要的话也可以把报表进行拆分。

6.2.指标与衍生指标取舍不合理

很多指标都有一些衍生指标，并不是只有后台数据库里面存在的指标才能展现，也不是一定要展现绝对量，有时指标稍微变换一下就能得到意想不到的效果，实际上有时候相对量更能反映事物的本质。

不要为了页面的效果简单的罗列指标。

最常用的衍生指标：

同比，环比，占比，累计占比等等

6.3.指标设计与业务不符

在做报表分析的过程中，不少指标单纯从指标的合理性角度看是没有问题的，但是结合业务逻辑，有些就是不合理的。

例如最近一年用户量的日趋势图，每天的用户变化可能是波动比较大的，一年的趋势变化根本看不出什么；我们更关注的是最近几天用户量的变化情况从而起到预警的作用，对于长时间的趋势（一年），我们更应该采用的是月去趋势或者是周趋势，而不应该是日趋势图。

6.4.数据自相矛盾

随着报表的不断增加，很多指标会出现关联交叉等等，有时会出现同一个指标在不同的地方值不相同，或者出现逻辑矛盾。

例如：

1.一年内12个月的每个月流量的和全国每个省一年流量的和

2.当期的用户数上期用户数+新增用户–流失用户

解决办法：

1.模型设计上相同指标统一规则，尽量统一出处，减少出错概率。

构建数据中间层，实现指标复用。

2.加强维表完备性监控和缺失值处理，因为绝大部分数据逻辑问题是由于维表或者缺失值引起的。

3.加强开发人员与业务系统人员的沟通，避免业务逻辑理解错误，提高开发人员的谨慎处理数据的能力，时刻检查数据的完备性。

6.5.把报表做成一个查询系统

功能很全面，用户想要什么数据都可以自己来查询，实际上这就说明我们的报表没有做到位，什么都可以查意味着查完以后要用户自己进行二次组织，二次分析用户真正想要的东西，我们还有很大的分析空间没有给用户做完，还没有把我们的专业性体现出来。

6.6.按照客户的要求做，却不能满足客户的需求。

前文实际上已经提到，用户有时提的要求就不能满足用户自己的实际需求，这是经常有的事情，虽然我们完全按照用户的要求做了，甚至有时候还超出了用户所想，可是最终还是没人用。

要想解决这个问题，一方面我们要从源头出发，挖掘用户的需求，做用户想要的，从而避免这种现象的出现；另一方面我们要加强监控，并及时发现用户不适用报表的原因，和用户沟通和用户反馈，及时修改。

7.总结

报表设计一门非常复杂的学问，很多问题没有完全正确的答案，因使用场景的变化，原来合理的设计换了一个场景也许就不适用了，但只要让用户认可，用户习惯使用，并且依赖我们的报表，那么我们就是成功的。

本文中的一些想法与设计，都是针对于如何把报表产品向着尽善尽美的方向发展而提出的，实际上由于受到开发成本，以及一些项目运营策略的考虑，实施的过程也可以灵活变通，做到产品利益服从与公司整体利益才是最可取的。