poxiaoxi博客拿到一个数据看板需求时，最常见的输入可能只是一份Excel、一张简单原型，甚至一句“把这些数据做得直观一点”。如果直接进入UI设计，很容易出现一种结果：页面看起来很丰富，折线图、饼图、地图和数字卡片一应俱全，但真正使用的人仍然找不到自己关心的数据。
数据看板的核心并不是“展示更多数据”，而是让用户在有限的时间里快速发现重要信息，并进一步判断是否需要采取行动。
因此，处理数据看板需求时，与其先讨论用什么图表、背景用什么颜色，不如先回答几个更基础的问题：谁在看、为什么看、需要看什么、看完以后要做什么。
数据看板解决什么问题
数据看板可以理解为把关键业务数据组织成一个可持续观察的界面。它通常承担三个层面的作用。
监控：快速了解关键指标当前是否正常。
分析：发现异常，并继续追踪可能的原因。
协作：从数据进入具体业务任务，推动后续处理。
例如物流管理系统中的看板，不应该只告诉用户“今天运行了多少趟”，还可能需要同时呈现准点率、异常车辆、晚点任务和待处理事项。
如果某个指标出现异常，用户最好能够继续进入详情，而不是只能看到一张漂亮的图。
所以，一个成熟的数据看板往往不是独立的“数据展示页”，而是业务系统中的一个信息入口。
第一步先确认谁在使用
同一批业务数据，给不同角色查看，页面重点可能完全不同。
管理层通常关心整体趋势、关键指标和异常情况，希望几十秒内判断业务状态；执行人员则需要知道具体哪一项出了问题，并能够继续处理。
例如车队负责人可能同时关注车辆使用率、运输任务、准点情况和整体成本，而调度人员每天真正需要高频查看的，可能是待发任务、车辆状态和晚点信息。
如果不区分角色，把双方关心的数据全部塞进一张看板，就会出现“所有东西都是重点，结果没有重点”的问题。
需求阶段可以先确认：
主要使用者是什么岗位。
用户多久打开一次看板。
是在电脑、移动端还是会议大屏查看。
用户打开看板时最想知道什么。
发现异常以后需要进行什么操作。
如果几个角色关注的数据大体相同，也没有必要分别开发完全不同的页面，可以通过模块权限、筛选条件或角色配置控制展示内容。
大屏和业务看板不是一回事
“数据看板”这个词经常把两种使用场景混在一起。
一种是会议室、监控中心使用的数据大屏。这类页面通常距离用户较远，需要较大的数字、明显的状态区分和较强的视觉识别能力，有时还承担品牌展示作用。
另一种是工作人员每天打开的业务看板。用户需要频繁筛选、点击、查看详情和处理任务，这时信息密度、加载速度和操作效率通常比视觉效果更重要。
如果把大屏的设计方式直接搬到日常业务系统中，大量动画、渐变、地图特效可能反而降低阅读效率，并增加浏览器渲染压力。
因此，看板开始设计以前需要先定义使用环境，而不是看到“Dashboard”三个字就默认做成深色科技风。
先把每个数据指标问清楚
需求方给出“订单数”“完成率”“异常率”等字段，不代表设计人员已经真正理解这些指标。
同一个名称，在不同公司甚至不同部门中都可能存在不同统计口径。
例如“订单数”需要继续确认：
统计创建订单还是支付订单。
取消订单是否包含在内。
重复订单如何处理。
按照创建时间还是完成时间统计。
实时计算还是每天固定时间更新。
如果这些定义没有确认，后面的图表即使完全按照设计稿开发，也可能无法回答真实业务问题。
因此，在看板项目中，数据口径本身就是需求的一部分。
理清数据之间的关系
数据看板不是把每一个字段做成独立数字卡片。真正影响信息表达的是指标之间存在什么关系。
例如“运行次数”“晚点次数”和“准点率”并不是三个完全独立的数据。
如果业务定义为：
准点率 = （运行次数 - 晚点次数）/ 运行次数 × 100%
那么用户真正重点关注的可能是准点率，而运行次数和晚点次数用于帮助解释这个结果。
这时设计上通常应该突出准点率，再把构成指标放在次一级位置，而不是三个数字使用相同字号并列排列。
类似地，如果多个指标之间存在总量与组成、目标与实际、同比与环比、正常与异常等关系，也应该在视觉层级上体现出来。
查询维度需要提前确定
看板中的数字很少脱离条件单独存在。时间、地区、业务类型、客户、部门、产品和状态都可能改变最终结果。
因此需要在设计前明确用户通常按照哪些维度查询。
尤其是时间筛选，需要确认整个页面是否使用同一个时间条件。
例如页面顶部选择“近30天”以后，是所有模块一起变化，还是某个“实时设备状态”模块始终展示当前数据？
如果不同模块实际上使用不同时间口径，却让用户误以为整个页面都受同一个日期筛选控制，就容易造成数据理解错误。
复杂看板可以在指标旁明确标注数据周期、更新时间或统计口径，而不是只在需求文档中说明。
信息组织要围绕用户任务
数据定义完成后，下一步才是决定这些内容放在哪里。
信息组织可以先按照业务含义进行分类，例如：
整体经营情况。
业务趋势。
异常预警。
区域或部门表现。
待处理业务。
分类之后，再根据用户的关注频率和重要程度确定页面顺序。
用户每次进入页面都必须确认的指标，应该放在更容易看到的位置；偶尔才需要分析的数据可以放在页面下方或者详情页面。
如果数据很多、团队内部无法确定应该如何分组，可以使用卡片分类法邀请真实用户进行整理。卡片分类本身就是一种用于理解用户信息分类习惯的方法，它的价值在于发现用户认为哪些内容天然属于同一组，而不是让设计人员完全按照组织架构自行分类。
不要把所有指标都做成图表
看板并不是图表越多越专业。
一个数字如果用户只需要知道当前值，例如“今日待处理任务12个”，直接使用数字卡片往往比做成仪表盘更加清楚。
只有当用户需要观察比较、趋势、组成或分布时，图表才真正有价值。
| 数据关系 | 常见表达方式 |
|---|---|
| 单个核心指标 | 数字卡片 |
| 随时间变化 | 折线图 |
| 不同类别比较 | 柱状图 |
| 少量类别占比 | 饼图或环形图 |
| 两个变量之间关系 | 散点图 |
| 地理位置与区域差异 | 地图 |
| 明细与精确数值 | 表格 |
Apache ECharts对不同图表的定义也体现了这种关系，例如柱状图主要通过长度比较离散类别，饼图通过角度表示不同类别占整体的比例，而视觉映射本质上是把数据维度映射到颜色、大小、透明度等视觉元素。
因此，选图表应该从数据关系出发，而不是先找到一个效果好看的图，再想办法把数据套进去。
饼图并不适合所有占比
看到百分比数据以后直接使用饼图，是看板设计中的常见习惯。
饼图适合展示数量不多、确实构成一个整体的类别，例如四种订单来源加起来等于100%。
如果类别有十几个，用户需要比较非常接近的两个数值，饼图的阅读效率就会明显下降，此时柱状图通常更加直接。
另外，如果几个百分比并不是同一个整体中的互斥组成关系，即使每一项都带有百分号，也不应该因为“都是比例”就强行放进同一个饼图。
颜色首先用于表达信息
数据看板的颜色不应该只负责“让页面丰富”。
业务系统中，颜色经常承担状态编码作用，例如红色表示异常、绿色表示正常、橙色表示预警。
如果同一页面又使用红色表示A业务、绿色表示B业务，用户就需要不断重新判断颜色含义。
更稳定的方法是先确定颜色承担什么任务：是区分类别，还是表达状态。
同时需要控制颜色数量。一个模块同时使用大量高饱和度颜色，很容易让所有信息争夺注意力。
对真正重要的异常信息而言，周围视觉元素越克制，它反而越容易被发现。
精彩评论