measure-dashboard-requirements

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Dashboard Requirements

仪表盘需求文档

A dashboard requirements document specifies what questions a dashboard should answer, what metrics it displays, and how data should be visualized. Clear requirements help data teams build dashboards that actually inform decisions rather than just displaying numbers.
仪表盘需求文档用于明确仪表盘应解答的问题、展示的指标以及数据的可视化方式。清晰的需求有助于数据团队构建真正能辅助决策的仪表盘,而非单纯展示数字。

When to Use

使用场景

  • When requesting a new dashboard from data/analytics teams
  • To define KPI tracking for a product, feature, or team
  • When formalizing ad-hoc reporting into a persistent dashboard
  • Before quarterly planning to specify what visibility you need
  • When onboarding stakeholders who need self-serve analytics
  • 向数据/分析团队请求新仪表盘时
  • 为产品、功能或团队定义KPI追踪规则时
  • 将临时报告规范化为持久化仪表盘时
  • 季度规划前明确所需的数据可视化需求时
  • 为需要自助分析能力的利益相关方提供入职指导时

Instructions

操作步骤

When asked to specify dashboard requirements, follow these steps:
  1. Define the Purpose Start with the questions this dashboard should answer, not the charts it should show. What decisions will this dashboard inform? A dashboard without clear purpose becomes a vanity metrics display.
  2. Identify the Audience Specify who will use this dashboard, how often, and in what context. An executive weekly review has different needs than a team's daily standup board.
  3. Specify Key Metrics For each metric, document: name, business definition (in plain language), calculation formula, data source, and baseline/target values. Ambiguous metrics lead to misaligned dashboards.
  4. Design Visualizations Recommend chart types based on what the data should communicate. Time trends need line charts; comparisons need bar charts; compositions need pie/treemaps. Include dimension breakdowns.
  5. Define Filters and Segments Specify what drill-downs users need: date ranges, user segments, product areas, geographic regions. Anticipate the "slice and dice" questions users will ask.
  6. Document Data Sources Identify where data comes from and any known data quality issues. Note latency requirements.does the dashboard need real-time data or is daily refresh sufficient?
  7. Set Permissions and Access Determine who can view what. Some metrics may need restricted access. Consider both security requirements and organizational politics.
当需要明确仪表盘需求时,请遵循以下步骤:
  1. 定义核心目标 从仪表盘应解答的问题入手,而非直接确定要展示的图表。该仪表盘将辅助哪些决策?缺乏明确目标的仪表盘只会沦为虚荣指标的展示工具。
  2. 确定目标受众 明确谁会使用该仪表盘、使用频率以及使用场景。高管每周复盘所需的仪表盘,与团队每日站会看板的需求截然不同。
  3. 明确关键指标 针对每个指标,需记录:名称、业务定义(用通俗易懂的语言)、计算公式、数据源以及基准/目标值。模糊的指标会导致仪表盘与需求不符。
  4. 设计可视化方案 根据数据要传达的信息推荐图表类型:时间趋势适合用折线图;对比分析适合用柱状图;构成分析适合用饼图/树状图。需包含维度细分。
  5. 定义筛选器和细分维度 明确用户所需的下钻分析功能:日期范围、用户细分、产品领域、地理区域。提前预判用户可能提出的“切片分析”需求。
  6. 记录数据源 确定数据来源以及已知的数据质量问题。注明延迟要求:仪表盘需要实时数据,还是每日刷新即可?
  7. 设置权限与访问规则 确定不同用户的查看权限。部分指标可能需要限制访问。需同时考虑安全要求和组织内部的权限规范。

Output Format

输出格式

Use the template in
references/TEMPLATE.md
to structure the output.
使用
references/TEMPLATE.md
中的模板来组织输出内容。

Quality Checklist

质量检查清单

Before finalizing, verify:
  • Purpose is framed as questions to answer, not charts to build
  • All metrics have clear definitions and calculation formulas
  • Data sources are identified and accessible
  • Visualization choices match the type of insight needed
  • Filters enable the drill-downs users will want
  • Refresh frequency matches decision-making cadence
最终定稿前,请验证以下内容:
  • 目标以需解答的问题而非需构建的图表来呈现
  • 所有指标都有清晰的定义和计算公式
  • 已明确数据源且数据源可访问
  • 可视化选择与所需洞察类型匹配
  • 筛选器支持用户所需的下钻分析
  • 数据刷新频率与决策节奏匹配

Examples

示例

See
references/EXAMPLE.md
for a completed example.
可查看
references/EXAMPLE.md
获取完整示例。