在商业智能和数据分析的世界里，为高层决策者设计的数据看板是一项至关重要的任务。这不仅仅是关于数据的展示，更是关于如何通过数据驱动决策和行动。

B端产品除了提供支持业务运转的功能外，往往还需要提供描述业务和系统价值的“数据功能”。

对于基础的一线使用者和一线管理者，往往只需要提供基础的数据表单、数据看板功能，以满足他们“汇总个人价值/业务价值/系统价值”的需求。

然而对于整个团队的高层决策者而言，他们并不需要详细描述业务情况的数据报表，他们需要在他们有限的时间内，快速掌握业务现状，然后得出结论并付诸行动。

这类数据报表往往又有一个称呼——数据大屏。数据大屏往往具有信息量大、多数据源整合、实时性、直观易懂等特点，以满足辅助“高层决策者快速感知、决策、行动”的需求。

最近刚好有一项业务需要设计面向高层决策者的看板，因此特地回溯下之前的一些经验和思考，总结一二。

一、前置调研：了解用户与业务

个人理解的数据大屏核心解决的是“信息传递”的问题，也就是如何把业务的情况传递给高层决策者，这里需要我们从繁琐的信息中拆解出“有用的信息”，然后选择合适的方式传递给高层决策者。

那怎么选择有用的信息呢？首先我们先了解用户与业务，从中提炼需要呈现的“信息”。

1. 了解你的用户

无论做什么需求，首先第一步需要了解你的用户。就算他是你的领导，在这个功能上也是你的用户。

B端的产品相比起C端产品来说，更容易接触到你的用户，因此可以直接与用户发起“一对一”的访谈交流，通过交流的过程中挖掘到用户的需求和使用习惯。

但是高层决策者往往是比我们高级的存在，甚至是我们的直系领导，一般情况下很难接触到，也不会配合我们。有的同学可能运气比较好，会遇到愿意交流和沟通的上级，但是并非所有人都有这种运气的，他们的管理位置决定了他们的待人态度是“高效”且“理性”的，也就是缺乏人性的。高层决策者往往不懂产品设计相关的内容，不太容易表述清楚他们的需求，有时候他们直接描述的需求，并不代表着他们的“真需求”。有些高层决策者会提出一些大而全的数据指标看板，但是实际做出来又会觉得信息太多了、信息不对，得不出有效的结论。而且，他们往往不愿意花太多时间交流，因为他们负责的业务非常多，时间有限。

但这并不意味着我们可以不去了解我们的用户，否则最终产品的效果不行，会被归咎于我们的能力问题。

所以，了解我们的高层决策者用户，是一件“难”但“不得不做”的事情。

那怎么做到了解高层决策者用户呢？小的能想到的主要有三个方向：

1）通过有限的接触中了解

虽然前面说了很多高层决策者不好接触的话，但是我们也还是能接触到他们的，只不过机会比较珍贵。比如需求对接时的接触、业务汇报时候的接触、例会时候的接触、群聊上的沟通等等。这是我们难得的直接对话的机会，所以要提前做好准备，把一系列想要探究的问题凝练成短短几个，以便找机会进行咨询。而且问题的设置不能太“弱智”，不能显得我们的专业性不够，所以通过这种途径进行用户了解，是一件有一定风险的事情。

2）通过侧面的观察与了解

我们能够从公开会议时他人的汇报情况、群聊上他人的交流情况、小道消息中观察与了解到相关的信息。这里非常考验我们的人脉关系网的建设能力，往往一些可靠性较高的小道消息，能成为救命的关键。比如，领导刚刚怼了隔壁部门的小A，小A的汇报由于呈现了XX数据被高层决策者否定了，领导并不认可XX数据这种方案。得知此消息的我们，可以比较在数据看板上呈现XX指标，以逃避血光之灾。

3）通过其他系统操作行为观察

如果我们有其他被高层决策者使用的系统，我们可以通过系统上的埋点观察他们的使用习惯和偏好，看看他们平时更关注什么指标，看看他们是否只看大盘指标 还是 会下钻深挖，看看他们看系统的频次，看看他们看系统的时间点（定时数据任务的时间点最好避开用户高频操作的时间点）。

通过这些有限的机会，我们需要挖掘到以下内容：

1）用户画像

我们需要了解高层决策者是个怎么样的人？他平时做事的风格是怎么样的？是否只关注“好看的”数据，还是喜欢看到“真实的”问题。是否喜欢先钻到各种维度进行数据分析和挖掘，还是只喜欢摆到脸上的直观数据。

这些特质决定了我们功能设置时候的方向，如果领导喜欢“好看的”数据，我们则要呈现正向指标，反之要多挖掘和涉及反向的指标。如果领导喜欢进行功能下钻分析，我们则要提供多维度的数据展示或者切换功能，以满足领导的需求。

2）对数据的需求

高层决策者往往也会提出一定的指标需求，指出他们想要观察到什么样的业务数据情况。这里的指标是我们设计功能时候的关键，意味着他们对某一模块的重点关注，这也往往代表着业务的重点。所以我们要围绕这些指标进行拓展，挖掘其中的关联指标、多维度拓展相关的看板，以更好满足高层决策者的需求。

3）使用习惯

使用习惯决定着用户会在什么场景下怎么样操作系统，这也一定程度影响了我们的功能设计倾向。比如系统是否需要提供足够多的下钻内容支持，以满足高层决策者的需求。比如他们的常用设备是怎么样的，这影响了我们的界面布局和前端兼容性能力支持，有的高层决策者会习惯使用手机看数据 或者 使用低分辨率的笔记本，这就意味着系统可视化的布局不能够太满，需要能够在他们的设备上较好地呈现数据指标。

这些挖掘到的内容对于我们设计数据看板往往是很关键的，这决定了我们的最终成品能否满足到用户需求。这非常考验我们的向上管理能力的过程，也比较吃我们在职场中人脉关系信息网络。

好笑的是，我原本以为互联网行业是一个能脱离人情世故的行业，大家都可以专注于业务之上。但是做中台产品越久，反而越觉得这是一件靠人情世故的工作内容。我们需要向上管理和同事人脉来了解用户、挖掘需求，做不好还会被质疑专业能力。

哈哈，难顶……

2. 了解你的业务

了解用户是完成高层决策者数据看板设计的第一步，下一步就是了解业务了。

了解用户往往只能知道“怎么样呈现数据信息”相关的信息，所以我们需要通过了解业务的过程，挖掘到我们要“呈现什么信息”。

很多情况下，高层决策者并不一定知道业务的具体细节的，他们往往只能给到一些他们对大方向 或者 战略层面的关注点，但是对于业务执行相关的一些细节和指标，他们是一概不知的。因此，我们需要从业务中挖掘到有价值的指标，并融入到我们的看板中，最后呈现给高层决策者。

这个过程其实等同于我们去进行业务汇报，因此对我们的业务了解有一定要求。

如何了解业务这个可以不多赘述。因为我们面对的是B端用户，可以直接开启“一对一”式访谈，可以进行业务调研，可以进行业务轮岗，可以通过业务数据观察。总之无所不用其极，我们需要通过这些方式挖掘到：

1）业务对于公司的定位与价值

这项业务在公司的核心业务流程中属于哪一模块，主要提供什么样的帮助，是提供支撑性质的服务？还是提供盈利上的支持？

我们需要了解到业务团队如何与公司进行价值交换？也就是他们凭什么让老板给他们发工资。这也是高层决策者往往最关注的内容。

就比如就好像客服业务的定位是“用户服务部门”、“不赚钱的成本部门”，对公司来说，他们的价值是“在一定人力的前提下，保证能消化掉客诉量，且用户满意度在一定水平”。简而言之，核心价值是“低成本”和“不出事”。

2）业务当前的阶段和发展

不同阶段的业务往往侧重点也会有所不同，这会影响我们的指标的设计。

一般MVP阶段（用最小代价能把核心问题闭环跑通）、PMF阶段（验证具有商业价值&合理的收入模型）的业务，业务更想从指标中验证“可行性”，探索“未来是否有可能对公司有效”。

而到了GTM阶段（追求规模化&边际成本递减），往往更关注实际产出的价值与贡献。不能在这个阶段产生价值的业务，有可能面临“降本增效”的命运。

3）业务关注的核心指标

了解业务的过程中，我们需要重点了解业务关注的核心指标，这很大程度影响了我们的看板设计。业务关注的核心指标代表着业务当前关注的重点方向，代表着他们为了达到目标的策略与方案。

此外，我们还需要了解这些指标的下钻维度，比如业务重点关心营收，但是营收是会有涨跌的，如果发现涨了或者跌了的时候，业务是按什么去下钻分析的，比如按渠道分析、按销售分析、按地区分析，这代表着这项业务需要什么样的维度进行辅助说明。

4）业务的汇报情况

业务成员一定是会定期进行向上的业务汇报的，这个过程就是业务梳理出的“核心指标”与高层决策者交互的过程。如果我们有机会，一定要参与其中。

我们从中能够观察到：高层决策者对业务这边呈报的指标是否满意？高层决策者是否对当前业务满意？高层决策者还关注什么？……

这些信息能够辅助我们更正确地设计看板的指标，而不是一昧地听信任何一方直接提出的需求，往往在实际的对接过程中，我们才能关注到“他们自己也没意识到的真需求”。

如果我们没有资格参与，则要通过向业务方询问相关的汇报情况。不过这非常考验我们和业务的关系了，因为有些汇报结果不体面，他们是不愿意透露细节的。

二、指标提炼：拆解看板内容

基于前面对于用户和业务的调研，我们就可以开始设计我们数据看板的指标了。

但是我们不能完全相信某一方的片面之词。他们所描述的指标，不一定是用户（高层决策者）真实需要的指标。

仅从业务中调研，业务可能出于“自保”，只给一些好看但无用的指标。

仅从用户（高层决策者）中调研，用户可能由于负责的事情比较多，不一定对业务很了解，给不到能够基于业务的指标需求，只会给到基于公司收益的指标需求。比如有些处于MVP验证阶段的业务，高层不清楚其现状，要求业务给到公司提供收益。那么如果我们直接呈报相关数据，高层一看收益为“0”，业务可能就会被当场砍掉了。

我们需要基于对用户需求的了解和业务的了解，挖掘出真实有效的指标体系，从而拆解出我们看板的内容。

主要步骤分为：

1. 当前阶段的北极星指标确立

所谓北极星指标，也就是为业务指明方向的指标，是当前阶段战略层的指标，这个指标有且只有一个。我们要基于对业务和用户的调研和了解，从中提炼出能代表着业务当前目标和价值的“北极星指标”。

比如客服团队的核心指标就可以设置为“服务质量”，可以是一个由客服平均评分、评价率、投诉案例数、投诉损失综合计算而得的分值。

2. 北极星辅助指标确立

北极星指标有且只有一个，但是北极星辅助指标可以有多个。为此，我们需要基于业务的北极星指标，拆解出北极星辅助指标，方便对业务进行补充描述，或者是描述业务的衍生目标。

比如销售团队的北极星指标是“销售收入”，但是也需要考虑对用户的服务质量，因为其北极星衍生指标可以包含“服务质量”。

3. 指标拆解

数据看板除了呈现“数值”外，还要辅助决策者进行“感知、决策、行动”。因此需要对指标进行“对比、“下钻维度”的拆解。

1）对比

指标的是需要通过对比才能感知好坏的，比如我告诉你本月收入是1000w时，你能知道团队做得好还是不好吗？有的人会说1000w那么多，肯定很好呀。这是因为你下意识和自己拥有的财物进行了对比，而对高层决策者来说，需要使用这个1000w与团队历史、团队目标、竞争团队、行业标杆对比，这时候才能知道数据的好坏，基于数据的好坏才能进行下一步的“原因分析”和“应对策略构思”。

所以，我们需要了解“某个指标”是需要和什么进行对比以辨别好坏的。一般对比的对象可以是“历史数据”（例如环比/同比）、“目标”、“其他团队”、“行业数据”。

2）下钻维度

当我们感知到数据的变好或变坏时，就需要分析数据为何好，或为何坏。这时候需要我们拆解数据的“下钻维度”，从而下钻到颗粒度更细的维度进行分析，挖掘到数据波动的原因。

一般分析的维度是“指标的构成元素属性”。比如“收入”这个指标，其下钻维度可以是“付费渠道”、“付费用户性别”、“付费用户地区”，从而对收入进行补充说明。当“收入”上涨或者下降时，我们可以通过下钻维度进行了解，看看到底是哪个性别/地区/渠道的收入下降了，从而定位出问题的所在。

因此，我们要结合业务上的复盘经验，从“指标的构成元素属性”拆解出业务常用的下钻维度，以用于看板的设计，让用户更容易一下子发现业务的问题。

三、MVP验证：方案与用户的磨合

通过前面的“用户调研”和“业务调研”，我们能很快得出我们高层决策者数据看板的“核心指标”。但是这时我们可以先不急着进行后续步骤的推进，因为后续步骤中的原型设计、数据加工处理、UI设计、前端开发、QA测试等环节是一个周期很长、成本很大的过程。

对于这些高成本的内容，我们可以先进行MVP验证。所谓的MVP验证，其实就是我们可以尝试基于我们拆解出来的看板内容，填充进业务上的真实数据，并对高层决策者进行一次汇报。

因为我所理解的数据看板，本质上就是一个可交互的PPT。所以我们可以在PPT上基于已经拆解出来的“北极星指标”、“北极星辅助指标”，填充进真实的数据，并补充上“对比、“下钻维度”的数据。这时，这份PPT已经构成了数据看板的“最小可行性版本。只不过这个MVP版本的交互没那么好，用户看起来可能有点费劲。我们可以尝试以原型的形式进行数据呈现，更真实地模拟功能的上线状态。

在这个汇报的过程中，我们能够发现我们最终提炼的出来的“看板内容”是否符合用户的需求，并且收集到用户的反馈和修改意见，从而辅助我们打磨我们的方案。

不过这个MVP验证方式存在弊端，因为高层管理者不好约，他们可能不会配合我们进行MVP验证，他们可能会说“先做出来看看啊~”。这时候我们也可以退而求其次，用以下方法：

1.让技术做一个简化版本的功能。不过这个方法可能会被怼，因为他们会以为这是成品，从而觉得我们能力不行。

2.改成模拟向业务一线管理者报告，从而让其尝试进行报告，然后收集汇报反馈。这个方案缺陷在于“信息经过了多层中间商”，可能存在信息失真的风险。

这些次要方案效果都不会很好，所以我们看板能否做得比较好，也有一部分运气的成分。

四、方案执行：把功能做出来

基于前面的步骤，我们就可以推动数据看板系统的建设了，这里步骤主要分为以下几步。

1. 原型方案设计

在指标提炼环节，基于梳理的“北极星指标”、“北极星辅助指标”、“对比、“下钻维度”，我们就能够在脑海中有一个大概的原型了。在通过了MVP验证之后，我们就可以出具具体的原型方案了。

原型方案的设计需要能满足辅助“高层决策者快速感知、决策、行动”的需求。所以需要做到以下几点：

1）围绕炼指标设计原型：这一点不赘述，因为前面的流失中我们找到了能够辅助用户决策的关键指标。

2）先总体后细节：因为整体数据看板承载的数据量是非常大的，为了避免给用户过多无效信息，我们需要分清主次，优先展示重点指标，其次才是各指标的对比数据、维度数据，最后是数据的详细明细显示。优先展示整体数据，有助于帮助用户先了解事情的全貌，带着这个认知去看下钻的数据分析，这样他们才能从“一堆数据”中感知到有效信息，然后进行决策、行动。

3）数据需要能传达有效信息：如果用户无法从数据中获取到“有效信息”，那么看了数据看板等于没看。因此我们需要通过对核心指标的“对比”或“下钻维度”中提炼出“当前业务的问题”。比如，我们可以给一些指标设置目标值，在业务不满足业务目标的时候，对用户标红警告出来。当用户看到这个警告的时候，就会得出“XXX做得不好”的决策，并推动“需要让业务整改”的行动。

2. 数据加工处理

这一步需要交由技术进行处理，产品需要提供每个指标和看板所引用数据的计算公式，并确认好数据源。如果数据来自于上游/下游系统，则需要提前与相关的部门进行沟通，提前规划好数据的获取形式，并安排相关的排期，以保证业务的顺利推进和上线。

3. UI与图表可视化设计

很大程度上，B端系统好看 等于 好用。因为好看的系统能遮盖一定的使用上的不良体验，而且能够更好地传达数据信息，辅助用户感知、决策、行动。

关于UI设计和图表可视化的原则，此处就不展开了。UI设计相关的要点有“布局分布”、“区域分配”、“用色技巧”、“图标应用”等。而图表的使用，则需要根据数据“对比、“下钻维度”的需要，采用以下的图表之一。

1）随时间变化的图形：折线图、柱状图、堆积柱状图、面积图、蜡烛图（K线图）、瀑布图；

2）类别对比图形：柱状图、分组柱状、气泡图、平行坐标图、多条折现图、子弹图；

3）排名图形：有序条形图、有序柱状图、平行坐标图；

4）占比图形：饼图、环形图、堆积面积图、矩形树图、旭日图、

5）关联图形：散点图、气泡图、柱状图+折线图、热力图；

6）分布图形：直方图（一般表示数据的频次和分布情况）、箱形图、小提琴图；

7）关系图形：桑基图、和弦图、韦恩图；

4. 开发验收上线

原型和UI确定后，就可以推动开发了。这个过程重要的是做好排期管理，因为我们的用户是能一定程度决定我们职场生死的高层。所以我们一方面我们要紧跟项目开发进度，另一方面要做好用户的预期管理，要周知好开发的周期和节点，酌情申请额外的开发资源。

当系统提测后，我们要和业务方一块进行数据准确性的验证，避免呈报错误的数据，否则，数据错误导致的决策错误时，我们可是会背P0级别的黑锅。小结

以上便是我最近关于高层决策者看板的一些思考与总结了，欢迎各位大佬指点~