产品设计|记一段数据可视化产品的迭代感受( 二 )

虽说数据应用型系统区别去其他 B 端系统，不涉及复杂的业务性场景流程和用户策略，但如果不是有过硬的数据产品经验或系统的产品思维，我们很容易会陷入只关注数据流问题的漩涡。
1. 除了数据流还要重视业务流虽然 BI 可视化系统没有复杂的业务场景，但不代表它没有任何场景。BI 可视化产品包括两类用户：作图者、看图者。

文章插图
2.0阶段在全公司推广后发现效果很差，我们开始反思产品设计，并在核心功能上对比 Tablaeu 到底还缺少什么？
后来发现面向“作图者”虽然了解完整制作一个仪表盘的流程，却可能忽视他们不显著但非常重要的场景：

相同图表会放在多个仪表盘里；西方人设计的 Tableau 在配置看板的过程并不友好；
分析师离职后数据集权限需要继承；
……

后来针对我们针对上述场景做了改造，解决了分析师遇到问题：支持图表的复制、粘贴功能，筛选器配置流程也做了符合分析师心智模型的操作（详见《5个关于“效率”的故事，带你搞懂数据可视化产品》一文“故事3：管理效率——由被动到主动，由抄袭到创新”中说明），并将数据权限由个人转变为分组……
【产品设计|记一段数据可视化产品的迭代感受】而在面向“看图者”我们之前关注只是普通用户，这也是在2.0阶段后期使用人数一直在一个天花板上不去的原因，后来我们采取了“领导包围团队”的模式，在2.0阶段“截图”功能的基础上，衍生出了自动发布截图的功能，最后带来了流量的第一次爆发（详见《5个关于“效率”的故事，带你搞懂数据可视化产品》一文“故事4：运营效率——从领导包围团队，用认真留住用户”中说明）。
2. 数据型系统也要重视产品团队这一段内容可能比较敏感也备受争议，但因为前公司（甲方）和现公司（乙方）都或多或少存在一些问题，所以还是决定拿出来说一下。
不少公司数据产品归属于数据部门下，数据部门本身又是重视数据资产、计算的部门，而前面也提到了数据系统本身也包含复杂的数据逻辑，这些都会给数据部门的决策者蒙上一层滤镜：更关注技术（数据）！
其实在《5个关于“效率”的故事，带你搞懂数据可视化产品》一文“故事3：管理效率——由被动到主动，由抄袭到创新”中提到我重新设计了筛选器流程提升了分析师制作仪表盘的效率，可是在这个流程设计之前有一版开发主导设计的流程，他们会按照属性相关性在功能操作上进行绑定，把数据思维带入了流程设计中，从而让整个操作变得很难用。
一个规范的产品设计流程，应该让产品主导设计并收口，最后用结果和数据作为奖惩产品经理的依据。
而在乙方公司内，如果产品团队在公司侧和客户侧都不受到重视，那最终的结果会更加的糟糕。
我们直接看一个糟糕的数据吧：现公司给客户公司设计的9张主题域仪表盘已经下架了6张，还有3张会有被下架的风险。
这个结果是如何导致的呢？
首先是客户侧的问题，虽说很多传统零售行业寻求数字化转型，但是其实深入合作后发现比数字化转型难的是工作流的转型。
需求必须等客户公司安排才能进行调研、做完方案就必须移交给客户执行……
这些都是导致“在调研阶段需求采集不全面”和“仪表盘上线后运营不完善”的因素。
而在公司侧，不放权给身处客户内部的产品，而是交给远离客户项目的人，由信息不对称导致的理解偏差，最终会导致项目落地结果比较糟糕，也会降低身在项目内真正干活的人的热情。