3. 仪表盘需求分析与用户画像

环境数据可视化仪表盘失败的最常见原因，不是图表画得不好看，而是从第一行代码开始就没有想清楚“给谁看、看什么、看到什么程度算成功”。同一个空气质量数据集，环保管理者关心的是“今天哪个区超标、要不要启动应急响应”，科研人员关心的是“PM2.5与臭氧的日变化相位关系是否显著”，公众关心的是“我家附近现在能不能开窗通风”。如果用一个仪表盘同时满足这三类人，结果往往是三类人都不满意。因此，需求分析的核心任务是把模糊的“做个环境仪表盘”转化为可验证的角色画像、关键问题与成功标准。

一、从角色到问题：用户画像的三层结构

用户画像不是写一段人物小传，而是要落到可操作的三层信息上：角色职责决定他关注什么指标，决策场景决定他什么时候看、看多久，信息素养决定他能接受多复杂的图表与交互。以某市级生态环境监测中心为例，可以梳理出三类典型角色。

环保管理者（如区县生态环境局值班负责人）：职责是监管与应急调度，决策场景是每日晨会与污染过程期间的实时盯守，单次查看时间约1～3分钟，信息素养中等，偏好结论先行、异常高亮、可下钻到站点。其关键问题是“当前哪些站点超标、超标持续多久、未来24小时是否恶化”。

科研人员（如大气环境研究所分析人员）：职责是机理分析与论文支撑，决策场景是长时间的数据探索与导出，单次使用可达30分钟以上，信息素养高，能接受多变量联动、散点矩阵、时间序列叠加与统计标注。其关键问题是“污染物浓度与气象要素的相关性如何、不同季节的日变化规律是否一致、数据缺测率是否影响结论”。

公众：职责是生活防护，决策场景是通勤前、户外活动前的碎片化查看，单次查看约10～30秒，信息素养差异大，偏好颜色分级、健康建议、地图定位。其关键问题是“我所在位置现在空气质量如何、今天适不适合户外运动”。

二、把关键问题转成可验证的成功标准

需求清单里最容易含糊的是“成功标准”。建议为每个关键问题配一条可观测的判据，而不是写“界面美观、响应快速”。例如管理者的“哪些站点超标”可定义为：打开仪表盘后，无需任何点击即可看到超标站点数量与名单，且名单与后台超标判定逻辑一致；判据是“首屏信息完整率100%，超标站点识别耗时≤3秒”。科研人员的“相关性分析”可定义为：任意两个污染物或气象变量可在两次点击内生成带回归线的散点图，并显示样本量n与缺测率；判据是“变量组合覆盖≥8个，导出字段与图表一致”。公众的“是否适合户外活动”可定义为：定位成功后首屏出现当前AQI等级、颜色与一句健康建议；判据是“移动端首屏加载≤2秒，建议文案与AQI等级映射无错配”。

这些判据的价值在于它们可以被测试。做原型评审时，让一位值班负责人实际打开页面，计时他找到“今日超标站点”的时间；让一位科研人员尝试导出“PM2.5与相对湿度”的散点数据；让一位非专业用户说出“现在能不能跑步”。三次测试的结果直接决定需求清单中哪些条目保留、哪些降级。

三、需求清单的字段与示例

需求清单应能直接交给设计与开发，建议每条需求包含：编号、角色、关键问题、指标/数据、视图形式、交互、成功判据、优先级。下面给出一份可直接填写的示例（数据与判据为教学假设，非实测结果）。

四、需求收敛与冲突处理

三类角色的需求必然冲突：管理者要“少而醒目”，科研人员要“多而可探”，公众要“简而可懂”。处理原则不是折中，而是分层承载：首屏只放各角色最高优先级的一条结论，复杂分析收进二级页面或“分析模式”开关，公众端独立为轻量页面。另一个常见冲突是实时性与准确性——管理者希望分钟级刷新，但监测数据存在审核与补录，此时应在界面上明确标注“实时未审核/已审核”状态，而不是用刷新频率掩盖数据口径问题。

最后需要强调，用户画像与需求清单不是一次性文档。上线后应通过访问日志（各角色停留页面、下钻深度）、用户访谈与任务完成率回访，持续校正优先级。例如发现管理者几乎不使用24小时色带而频繁点击站点列表，就说明“名单”比“预报”更贴近其真实决策路径，下一版应把名单前置。需求分析的终点，是一份能被测试、能被迭代、能被不同角色各自认领的需求基线。