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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
Set Permissions and Access Determine who can view what. Some metrics may need restricted access. Consider both security requirements and organizational politics.
当需要明确仪表盘需求时,请遵循以下步骤:
-
定义核心目标 从仪表盘应解答的问题入手,而非直接确定要展示的图表。该仪表盘将辅助哪些决策?缺乏明确目标的仪表盘只会沦为虚荣指标的展示工具。
-
确定目标受众 明确谁会使用该仪表盘、使用频率以及使用场景。高管每周复盘所需的仪表盘,与团队每日站会看板的需求截然不同。
-
明确关键指标 针对每个指标,需记录:名称、业务定义(用通俗易懂的语言)、计算公式、数据源以及基准/目标值。模糊的指标会导致仪表盘与需求不符。
-
设计可视化方案 根据数据要传达的信息推荐图表类型:时间趋势适合用折线图;对比分析适合用柱状图;构成分析适合用饼图/树状图。需包含维度细分。
-
定义筛选器和细分维度 明确用户所需的下钻分析功能:日期范围、用户细分、产品领域、地理区域。提前预判用户可能提出的“切片分析”需求。
-
记录数据源 确定数据来源以及已知的数据质量问题。注明延迟要求:仪表盘需要实时数据,还是每日刷新即可?
-
设置权限与访问规则 确定不同用户的查看权限。部分指标可能需要限制访问。需同时考虑安全要求和组织内部的权限规范。
Output Format
输出格式
Use the template in to structure the output.
references/TEMPLATE.md使用中的模板来组织输出内容。
references/TEMPLATE.mdQuality 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 for a completed example.
references/EXAMPLE.md可查看获取完整示例。
references/EXAMPLE.md