一键在 Manus 中运行任何 Skill

dashboard-specification

星标3

分支3

更新时间2026年6月14日 05:06

Define complete requirements for a data dashboard before development begins. Use when a new dashboard is requested, when an existing dashboard needs redesign, or when stakeholder alignment is needed before building.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

ryudkiss-hue

ryudkiss-hue/nyc_data

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

When to use

A stakeholder requests a new dashboard and you need to capture requirements clearly
An existing dashboard is misaligned with user needs and needs redesign
Multiple stakeholders have conflicting ideas about what the dashboard should show
A developer needs a clear spec before building

Process

Define dashboard purpose — articulate the single sentence: "This dashboard answers [question] for [audience] who need to [decision or action]." If this can't be expressed in one sentence, the scope needs narrowing.
Profile the users — for each user type, document: visit frequency, primary questions, key decisions, and technical comfort. Different audiences typically warrant separate dashboards rather than extra filters.
Define the metric hierarchy — organise into: primary KPIs (top of page, max 3–5), secondary metrics (supporting context), and detail breakdowns. Flag scope creep if total metrics exceed 10–12.
Design information architecture — follow hero → trends → breakdowns → details pattern; place most important content top-left; define sections and their purpose
Specify interactivity — list every filter, drill-down, and toggle; justify each one (adds decision value vs. adds complexity)
Document data requirements — for each metric: source table, calculation, refresh frequency, and any known data quality issues

Inputs the skill needs

Required: stakeholder's business question or use case
Required: intended users and their roles
Optional: existing dashboard or report to build on
Optional: refresh frequency requirements and data source constraints

Output

references/dashboard_design_principles.md — layout, hierarchy, and interactivity guidelines
references/dashboard_requirements_guide.md — stakeholder question frameworks
assets/dashboard_spec_template.md (filled) — complete spec: purpose, users, metrics, layout, interactivity, data sources, and success criteria

同仓库更多 Skills

同仓库

data-catalog-entry

ryudkiss-hue/nyc_data

Create standardized metadata for data assets. Use when documenting new datasets, building data catalogs, improving data discoverability, or creating data dictionaries for teams.

2026-06-173

analysis-planning

ryudkiss-hue/nyc_data

Structure analysis approach before starting work. Use when receiving new analysis requests, breaking down complex questions into steps, or planning iterative analysis workflows.

2026-06-173

data-quality-audit

ryudkiss-hue/nyc_data

Comprehensive data quality assessment against business rules, schema constraints, and freshness expectations. Activate when validating production pipelines, onboarding new data sources, or when stakeholders report data quality concerns.

2026-06-143

segmentation-analysis

ryudkiss-hue/nyc_data

Identify distinct customer or user segments based on behavior, attributes, or value. Activate when you need to answer "who are our best customers?" or "what distinct groups exist in our user base?" and need data-driven profiles to inform strategy.

2026-06-143

visualization-builder

ryudkiss-hue/nyc_data

Create effective, publication-ready data visualizations. Use when choosing chart types, designing presentation visuals, building dashboard charts, or applying visual design best practices to data output.

2026-06-143

methodology-explainer

ryudkiss-hue/nyc_data

Create a clear, transparent explanation of analytical methodology for any audience level. Activate when you deliver findings that require the audience to trust the method — A/B tests, attribution models, forecasts, statistical analyses, or anything where "how did you get that?" is a likely question.

2026-06-143

name	dashboard-specification
description	Define complete requirements for a data dashboard before development begins. Use when a new dashboard is requested, when an existing dashboard needs redesign, or when stakeholder alignment is needed before building.

When to use

A stakeholder requests a new dashboard and you need to capture requirements clearly
An existing dashboard is misaligned with user needs and needs redesign
Multiple stakeholders have conflicting ideas about what the dashboard should show
A developer needs a clear spec before building

Process

Define dashboard purpose — articulate the single sentence: "This dashboard answers [question] for [audience] who need to [decision or action]." If this can't be expressed in one sentence, the scope needs narrowing.
Profile the users — for each user type, document: visit frequency, primary questions, key decisions, and technical comfort. Different audiences typically warrant separate dashboards rather than extra filters.
Define the metric hierarchy — organise into: primary KPIs (top of page, max 3–5), secondary metrics (supporting context), and detail breakdowns. Flag scope creep if total metrics exceed 10–12.
Design information architecture — follow hero → trends → breakdowns → details pattern; place most important content top-left; define sections and their purpose
Specify interactivity — list every filter, drill-down, and toggle; justify each one (adds decision value vs. adds complexity)
Document data requirements — for each metric: source table, calculation, refresh frequency, and any known data quality issues

Inputs the skill needs

Required: stakeholder's business question or use case
Required: intended users and their roles
Optional: existing dashboard or report to build on
Optional: refresh frequency requirements and data source constraints

Output

references/dashboard_design_principles.md — layout, hierarchy, and interactivity guidelines
references/dashboard_requirements_guide.md — stakeholder question frameworks
assets/dashboard_spec_template.md (filled) — complete spec: purpose, users, metrics, layout, interactivity, data sources, and success criteria