本篇文章中，作者整理了数据可视化产品需求的必备要素，以及经常会被忽略和遗漏的点，从数据产品需求文档的常规结构开始讲起，到易漏细节自查清单，让你的数据产品需求文档更加无可挑剔，成为别人眼中靠谱的产品经理。

最近做的项目主要是负责数据可视化分析模块的产品，找了外包团队进行开发变现。

如果是公司内自己的研发，需求不完善，临时变需求最多会被开发吐槽或者打一顿，刷个脸陪个笑，喝个咖啡吃个饭，最终还是会帮忙解决问题。但是外包生意就是生意，没有那么多人情，需求范围签合同时基本确定。

为了减少沟通成本和避免后期扯皮，所以在需求方面，做了充分的澄清。顺带整理分享下数据可视化产品需求的必备要素，以及经常会被忽略和遗漏的点，让你的数据产品需求文档更加无可挑剔，成为别人眼中靠谱的产品经理。

一、数据产品需求文档的常规结构

一般来说，对于一个数据产品需求来说，PRD文档主要会包含以下几个部分：

1.需求背景及目标

这个部分的作用一方面可以让开发团队更加清楚的知道自己做这个需求的业务背景和价值是什么，否则就只是被动地执行完成需求，对于为什么做却一知半解。知道了这个事情是公司重点战略，做好了会被老板关注，可能开发自己就愿意花心思把事情做好，否则就是做完产品交代的工作，其他荣辱与我无关。此外，PRD的作用之一还是资产沉淀，健全准确的背景目标描述，后期工作交接也会非常方便。

2.用户及权限

C端产品面向的是普罗大众，B端尤其是数据产品，一个报表可能是服务的特定用户群体，所以做数据产品时，需要厘清核心用户和覆盖用户分别是谁。

而用户权限方面，主要是不同用户对页面、数据指标以及维度（区域、品类等）的具体权限清单，从而保证数据安全。

3.数据需求说明

常见数据需求模板可参考如下：

数据需求是数据可视化产品的核心模块，准确描述数据统计逻辑可以节省很多开发沟通成本。为什么说数据产品最好要具备SQL能力，主要是因为可以做一些基础的数据探查工作，这样做产品设计的时候才能数据是怎样的，否则辛辛苦苦设计出来的产品，最后没数据或者数据做不了，就白费时间

4.产品功能说明

上图是一个最常规的可视化报表的功能页面，产品需求描述时，需要针对各个模块做详细的说明，比如筛选器的默认值设定，联动逻辑，指标展示内容，图表类型及图表信息设置等等。

二、易漏细节自查清单

1.无数据提示页

数据产品不同的维度组合往往会存在无数据的情况，比如某些区域就是这一天没数据，如果直接展示一个空白页面，用户会分不清到底是没数据还是系统问题。

2.无权限提示及引导流程

有数据权限限制，当用户访问页面无权限时，需要友好地进行提示，并且加以引导，直接提供申请权限入口或者申请方法（比如给XX发邮件）

3.性能要求

数据产品对海量大数据的ETL处理同步到前端页面查询时，一般要求图表的加载和响应时长不能过长，比如3S，太长时间用户焦躁。如果不提前写清楚性能要求，技术实现上可能是完全不同的数据存储和查询方案。上线之前性能老板不满意，再去改方案就非常麻烦。

4.数据异常提醒

数据ETL到最终展示需要经过很长的数据链路，经常因为集群、服务、数据开发问题导致数据异常，如果因为任务延迟导致数据缺失，给业务带来错误的决策，后果非常严重。所以需要有一些异常的提醒和容错机制，比如展示数据前先判断任务状态以及数据质量监控的结果，发现问题时，展示数据异常提醒页面。

5.数据格式说明

不同数据指标展示上需要明确对应格式，比如是整数，单位用什么，是否需要千位分隔符展示，小数保留几位小数，有些指标需要百分比展示等。

6.tooltips细节

鼠标悬浮在不同图表、不同位置时，展示什么指标或者维度信息，数据的格式如何等等

7.筛选器层级联动

对于层级维度，如区域、省份、城市等，需要前后级联的要求

8.默认值及排序

筛选器的默认值，如默认展示昨日或者最近7天的数据，表格数据排序按数据大小降序，按照数据日期降序等。曾经见过一个表格，新增数据每次排到最后一页，用户添加了数据保存后没反应，还以为没加上，又加了一次。最后发现，表格排序是把最新更新的加到了最后一行。

9.异常数值处理，枚举值数量过多

有些维度比如城市、细分三级品类等，一般来说数据量非常大，饼图、折线图、柱状图等如果超过了5个以上，图表基本上没法看，所以需要定义好展示多少个，其他的数据是直接舍弃还是说归到其他一类当中。

10.文字对齐方式，比如指标右对齐

一般来说，维度的文字左对齐，数据指标右对齐，这样可以更加方便的看出数据的差异。