图表|5个关于“效率”的故事，带你搞懂数据可视化产品( 二 )_

而对作图者而言，“高效”意味着能够快速搭建一张 Dashboard。
使用过 BI 可视化工具的同学应该清楚，配置仪表盘的主要流程分为三步：连接数据源 → 配置数据集 → 制作报表。
其实绝大多数的 BI 工具在“连接数据源 → 配置数据集”环节的操纵基本都差不多（有一种特殊的方式，后面有机会将会用整张篇幅介绍），而在“制作报表”环节上， unicorn 却经历过一次由低效到快捷的变革。
在接手 unicorn 时，“制作报表”是参考一个开源的 BI 工具的制作流程：创建画布后，需要添加已经创建好的图表，全局筛选器可以在画布区域添加，而针对单表的是筛选器是创建图表时添加（Dashboard 包含三个主要元素：画布、图表、筛选器）：

文章插图
其实，上述过程我们可以看到是一个工程化思维的过程，图表和图表筛选器是一一对应的关系，画布与全局筛选器也是一一对应的关系，图表之间是存放在一起的组合关系，而画布则是包含这些图表的关系。
如果用这种方式向他人介绍 BI 可视化工具，那是非常棒的，但是交给用户去操作不难发现仪表盘的创建是不连贯的。为了保证用户的操作连贯性，我们把 unicorn的操作方式做了修改，让用户创建画布、图表、筛选器都是在同一个视窗下完成的：
除了整体流程的优化，各个功能模块的优化也满足用户的心智模型，在“故事3”中我会继续讲述相关的内容。
三、故事3：管理效率——由被动到主动，由抄袭到创新2018年时，虽然我已经有了几年的产品经验，但是数据产品的经验却是0。且数据产品会涉及技术性的工作，所以一开始我更多是跟着开发的思路去走。
在接手 unicorn 时，用户全为本部门的几个数仓同学，基本上他们提什么需求方案就跟着做什么需求方案，实现方式也被动接受后端开发的设计思路，作为一个产品人把大脑交给别人是一件非常痛苦的事情。
一个多月的时间里，我开始一方面记录 unicorn 的迭代路径，发现产品的迭代基本上是东一榔头西一棒槌，缺乏方向性的规划；另一方面从零开始学习基础的 SQL 查询语句，学习每个功能背后数据流转，了解了现存功能亟待改善的功能点。
“你可以跟我提需求，但是你必须得跟我讲背景……”看过我之前文章的朋友应该知道，这句话是我对数仓同学说的与一开始发生180°反转的话，这也是我做数据产品发生改变的起点。
随后我开始重新制定了新的需求提报标准（需求录入表），增加“讲背景、说问题”的环节，而不是直接说解决方案。为了避免过分改革带来潜在的影响（感兴趣的朋友可以了解一下王莽改革），我保留了数仓同学爱直接提方案的行为，只是在备注了其为“建议方案”，即最终实现以产品设计为准。
同时，需求的优先级、排期等设定的归属权归为我们项目组讨论处理，参考如下（仅白色填充的表头所在列，支持需求提出人编辑填写）：
伴随着需求池的规范化整理、分类，整体方向性的迭代规划也有了蓝图。
此外， unicorn 的设计也不是完全抄袭着 Tableau、网易有数等之类的商业化 BI 工具功能流程，就以筛选器作用图表的功能为例吧，Tableau 支持如下图所示的应用范围选项：

文章插图
其实，Tableau 是以数据视角而非图表视角设计这项功能的，“仅此工作表”还容易理解，但前面两个选项（选项1是跨数据源筛选的功能，选项2是针对同一数据源的所有图表）的名称就是要让用户更关注数据而非图表本身，让用户用不同视角去理解并列关系的选项，这种设计本身就很反人性。