此内容由人工智能翻译，尚未经过人工编辑审核。图像和图表保持其原始语言。
关键要点
- 良好的数据可视化 Visual 能帮助人们快速理解信息并采取行动。 遵循设计规则并不能保证 Report 会很有用。 你需要先弄清楚哪些问题需要解答，并设计能够清晰、毫不含糊地给出这些答案的 Report。
- 做图表很容易，收集需求和理解用户很难。 工具让你可以轻松将字段拖放到 Visual 中，但要做出有效的 Report，必须慎重决定：展示什么、如何展示，以及展示给谁。
- 可视化质量从语义模型开始。 一致的命名、清晰的定义和稳健的模型设计，能让 Report 值得信赖、易于维护，并可随规模扩展。
本摘要由作者撰写，并非由 AI 生成。
<！--more-->用简单的话解释什么是好的数据可视化
好的数据可视化能让信息一眼就看懂。 你可以盯着电子表格费力找趋势，也可以在折线图里立刻看到趋势。 数据可视化能帮助人们更快、更有把握地回答问题。 在 Power BI Report 中，好的可视化意味着用户看一眼页面，就能迅速明白：“这里的关键信息是什么？ 这算好还是坏？ 需要我采取行动吗？”
最好的 Report 不需要用户去“解码”眼前的内容；设计本身就不言自明。
这个“Orders MTD Report”试图回答的问题是：“与一月订单目标相比，我们的表现如何？我们应该把注意力放在哪里？”。 如果我们把这份 Report 放到 3-30-300 规则 的语境中(对 可视信息检索箴言 的转述)：
- 在 3 秒内，我们就能看出当前表现超过目标。
- 接下来的 30 秒内，我们还能看到：
- 我们刚经历了一段未达标期，且每日表现波动很大。
- 关键客户账户对超额完成贡献最大。
- 东南地区表现不如西北地区。
- 再接下来的 300 秒内，我们可以在散点图中下钻到具体的异常客户，或在表格里定位具体产品与类型；表格中的迷你图 sparklines 能帮助快速把握产品趋势和下滑点的大致情况。
一些可遵循的最佳实践
要做出好的 Report，一个不错的起点是遵循一些“最佳实践”：
- 采用合乎逻辑的图表布局，将最重要的信息放在左上角，最细节的信息放在右下角。 这就是用于 Report 布局的 3-30-300 规则，Orders MTD Report 就是一个示例。 你还应确保图表与各元素之间的间距保持一致。 Power BI Report 的网格与对齐功能会很有帮助。
- 针对问题选择合适的图表。 一个常见的错误是用饼图来比较不同类别的量级；饼图更适合用于展示整体中各部分的占比关系。
- 有目的地使用颜色来引导注意力。 例如，用更亮的颜色突出需要采取行动的信息；或利用隐含联想（在西方区域设置中，红色通常表示负面且需要处理）来标记可操作的负面信息。
- 在页面与容器样式上保持克制。 例如，使用浅灰背景、白色图表背景形成对比，并采用圆角。 使用一些标准的 Power BI Report 主题 就能轻松做到这一点。 避免怪异或过度装饰的风格，优先尊重用户的偏好，而不是你自己的。
- 图表样式应追求简洁与极简。 这有助于避免用户认知负荷过高。 这意味着使用更柔和、更浅的颜色，并思考为了让图表更简单，你可以删掉什么，而不是为了让它“更好看”你能加上什么。 一个非常常见的例子是：表格使用又粗又黑的字体，并加上黑色边框。
以上只是几个例子。 但是，即使你遵循了这些“最佳实践”，也不能保证人们会觉得你的 Report 有用。
“好”Report 的特征
当一份 Power BI Report 能帮助用户快速、清晰且毫不含糊地获得正确理解或洞察时，它就是“好”的。 这听起来也许很明显，但我们不妨明确一下：我们希望一份 Report 达成什么目标：
- 更短的洞察时间。 目标信息应在几秒内就能看见并理解，而不是点十几次之后才明白。
- 更低的认知负担。 用户可以专注于数据，而不是纠结该先看十二个 Visual、六个切片器还是三个图例。
- 以用户为中心。 图表应以用户为出发点，而不是沉迷于与结果无关的多余格式和装饰，因为这些并不会让最终结果更有用或更有效。
- 在任何交互下都保持正确性。 图表必须可信，并能给出业务用户对其数据所期待的结果。 在进行交叉筛选或下钻之后，总计和明细拆分仍然应当合理一致。 如果你在某个页面上展示“On-Time Delivery %”这一 KPI，同时该页面还包含针对“Is Delivery On Time”的“是/否”切片器，那么 KPI 会随着选择在 0% 和 100% 之间跳变。 这在技术上没错，但也是自证预言；指标被它自己的结果所筛选，因此并无参考价值。
- 语义一致。 同一个指标无论出现在哪里都应表达同一含义。例如，“Revenue”不应该在一个 Visual 中表示总收入，而在另一个 Visual 中表示净收入。
- 可维护性。 在 Report 中新增分段、时间周期或业务规则时，不需要回过头去重做并重新验证其中大量内容。
一些与这些目标背道而驰的例子包括：
- 缺少上下文的指标。 一张卡片显示“Orders MTD: 518M”，如果没有目标、差异或趋势，就无法传达任何信息。 这是好消息还是坏消息呢？
注意
你可以在 Power BI 视觉对象中创建更令人印象深刻、更复杂的 KPI 卡片。 虽然这些 KPI 在内容里很常见，但我们现在尽量不再使用它们，因为创建和维护成本高得不成比例。
- 页面过于密集。 如前所述，人脑并不擅长同时处理大量信息；而且页面上每增加一个元素，Report 性能都会进一步受影响。
- 隐藏状态。 如果用户无法轻松看出哪些内容被筛选、或哪些会受交互影响，他们就必须先“破译”Report 的工作方式——这会拖慢他们的进度，并埋下不信任的种子。 常见示例包括：
- Visual 上的 Visual 级筛选器：用户必须将鼠标悬停在“filter”图标上，才能知道哪些筛选条件正在影响该 Visual。
- 同一页面上的 Visual 交叉突出显示和交叉筛选，但没有提供用于区分其不同行为的上下文说明；被交叉突出显示的 Visual 仍会显示未筛选的数据，只是把所选数据高亮出来。 很容易把未筛选数据与已筛选数据混淆，尤其是当其他 Visual 通过交叉筛选仅显示已筛选数据时更是如此。
- 业务逻辑分散。 如果你不得不在 Visual 里写复杂 DAX、用一些奇怪的变通做法，或到处塞页面专用逻辑，那你是在错误的层面上弥补语义模型的缺口。 一个名为“Orders MTD Report（排除退货）”的 Report，如果其中的 Visual 又各自标注“（仅开票）”，这其实是在暗示模型并未清晰定义“Orders”的含义。 与在语义模型中一次性表达逻辑相比，把业务逻辑分散到各个 Visual 中更难治理、测试和维护。
注意
一些常见且很实用的功能（例如条件格式、动态标题和工具提示等）确实需要特定的 DAX 度量值或 Visual 级计算。 这些用法完全可能是合理的。 反模式在于滥用：与在语义模型中一次性表达逻辑相比，把业务逻辑分散到各个 Visual 里更难治理、测试和维护。
好的 Report 会围绕三点进行优化：
- 效率：既包括 Visual 与交互的性能，也包括用户多快能得到答案。
- 可信度：Report 不仅要准确，还要避免在用户切片、钻取、到处点击时（无意或故意！）误导用户……
- 可演进性：随着业务变化，Report 能轻松（甚至自动）更新——这种变化是常态，而且一年中会频繁发生。
如果其中任何一项长期被忽视，最终都会以挫败（“这没法用，Visual 加载太慢了”）、不信任（“按产品筛选时 这些数字就不对”），或开发瘫痪（“不改这个就改不了那个，而且一改就会把这和那都弄坏”）的形式爆发出来。 要优化“人理解得快”，关键在于按照人脑的工作方式来设计。 3-30-300 规则是一个很好的经验法则，用来设计更适合人阅读的 Report。 细节我们建议参考 SQLBI 链接的文章，但在下一节关于如何开始设计、before building 的内容中，我们会借用其中的一些思路。
先从问题开始，而不是从画布开始
Power BI 让你很容易直接上手做 Report：打开带有组织主题的报表模板，连接到语义模型，拖进几个 Visual 和一两个切片器，然后——就这样，你就有了一个报表。 从画布开始，往往会做出“看起来不错”，但概念上很模糊的结果——也就是说，它没有锚定到需要回答的业务问题。
注意
Report templates 和 organizational themes 很棒，可减少用于格式化的时间，并确保企业形象的变更能被统一应用。 它们也能通过提供可直接参考的示例，帮助自助用户避开常见设计坑，比如网格布局，以及按钮和工具提示等预先格式化的交互元素。
更好的方式是反过来，先问问你自己——也就是设计者：
- 这个页面要回答哪个问题？
例如： “对于任意月份，我们是否达成订单目标？哪些客户类型、产品或地区在推动超额完成或未达成？” - 用户会根据这个答案做出什么决定？
比如： “我们是否需要调整策略，还是集中销售投入？ 如果超出目标，我们是维持现状还是重新分配资源？ 如果低于目标，我们是把精力放在表现不佳的产品（产品策略/定价），还是高风险客户（客户关系管理/激励措施）？” - 如果数字发生变化，决策会如何改变？
举例： “如果订单 MTD 高于目标，且超额主要由关键客户带动，我们就持续监控并保持现有策略。 如果订单 MTD 降至低于目标，或日度波动加大，我们就展开排查：先看未达成幅度最大的产品，再看明显低于其目标的大客户”。
要求自己把页面要回答的问题写成一句话。 如果这很难，可能是这个页面想做的事情太多；你的指标语义仍然不明确；或者你还没有清晰了解用户到底需要什么。 去和他们聊聊。
TIP
这一点在当下尤其有价值，因为随着智能代理逐渐成为宝贵的开发工具。 有了 Agent，技术门槛和成本都在降低；对业务流程和领域理解到位的非技术人员，也能创建相当复杂且实用的 Visual、BI 解决方案或定制软件（顺带一提，并不一定都得是 Report 或 Dashboard！）。
如果你具备良好的设计与需求调研能力，你就能在这个新时代占得先机！
当这些需求明确后，图表的选择就不那么主观了。 The Orders MTD Report 只用了七种图表类型，而这些同样的图表基本能覆盖约 95% 的业务报表场景：
- 带上下文的 Card/Big Number visual：目标、差异、趋势指示
- 用于对比类别的条形图或柱状图
- 用于展示时间趋势的折线图
- 用于明细拆解与精确数值的表格
- 用于探索两个指标之间关系的散点图
- 用于地理维度对比的地图
- 用于展示两个时点之间变化的瀑布图
- 用于简单构成分析的圆环图或饼图（最多 2-3 个类别）。 这在 Orders MTD Report 中没有使用，但如果问题是“哪种账户类型主导了超额？”而不是“每种类型贡献了多少？”，它就可以替代“Over by Account Type”的瀑布图。圆环图会立刻显示关键客户占比超过一半，而瀑布图则提供便于对比的精确数值。
NOTE
关于是否使用饼图和圆环图，一直存在争议。 有人认为没有它们世界会更美好，也有人持更细致、更有分寸的观点。 我们认为用它们也不是什么世界末日。 如果类别很少（不超过 3 个），它们往往能达成目标：清楚地表达“某一类远超其他类别”。
如果你不确定哪个图表最契合你的问题，可以参考诸如 Dr。 的图表选择器 来指导你选择。 关键在于：让图表匹配你最需要回答的问题。比如，一年内的月度销售额，你该用折线图还是柱状图？ 折线图强调整体趋势，而柱状图会让每个月更像一个独立周期，便于逐月对比。 如果趋势比逐月对比更重要，就选折线图；反之亦然。
进一步推荐阅读
- 我们需要在 Power BI 中制作这份 Report（Data Goblins）：一个实用的 Report 需求收集框架，以用户及其需求为中心，帮助你避免基于假设去构建 Report。
- 用于制作更好 Report 的 3-30-300 规则介绍（SQLBI）：关于如何设计 Report 布局的详细指导，贴合人们实际获取信息的方式，从标题到深度分析。
- 业务 Dashboard 的四种模式（Ryan Gensel）：将 Dashboard 设计按不同用途归类为四种模式。
- 在 Power BI Report 内及跨 Report 复用 Visual 格式设置（SQLBI）：用于保持 Report Visual 风格一致的实用技巧，减少格式调整成本，并确保 Report 观感统一。
结语
好的数据可视化，与其说是把图表样式做到完美，不如说是清晰、快速且一致地回答正确的问题。 布局、图表选择、刻意用色等最佳实践确实有帮助，但它们只有在服务于明确的用户需求、并且建立在可信的语义模型之上时才会真正奏效。 因此，需求、语义和设计意图，比任何单一的 Visual 都更重要。