From vizro-e2e-flow
Guides dashboard design via 3-step workflow: requirements, layout, visualizations. For Vizro; generates YAML specs. Activates on design/plan requests before building.
npx claudepluginhub mckinsey/vizro --plugin vizro-e2e-flowThis skill uses the workspace's default tool permissions.
Structured **requirements → layout → visualization** workflow.
Builds and tests Vizro dashboards from design specs by copying example app, fetching model schemas, and running Playwright tests. For Python-based dashboard implementation.
Specifies requirements for analytics dashboards covering purpose, metrics, visualizations, filters, data sources, and access controls. Use when requesting from data teams or defining KPI tracking.
Generates structured dashboard specifications from business questions, including KPIs, charts, filters, layouts, and data sources for BI developers using Looker, Metabase, or Grafana.
Share bugs, ideas, or general feedback.
Structured requirements → layout → visualization workflow.
Run Steps 1–3 in order; each step depends on the prior. Track progress:
Dashboard Development Progress:
- [ ] Step 1: Understand Requirements (define end user, dashboard goals, document decisions)
- [ ] Step 2: Design Layout & Interactions (wireframes, filter placement)
- [ ] Step 3: Select Visualizations (chart types, KPIs; colors only if user asked)
Interaction style: When gathering requirements or making design decisions, ask focused questions and present 2–5 numbered options so the user can choose quickly. Prefer using your client’s built-in multiple-choice or question UI to keep the interaction lightweight and clickable; if that isn’t available, use the same numbered format in plain text
Do not skip steps. Handle partial context as follows:
For simple dashboards (single page, less than 5 charts): Steps 1-3 can be abbreviated but not skipped entirely.
IMPORTANT: Each step produces a spec file in the spec/ directory to document reasoning, enable collaboration, and allow resumption in future sessions. Create the spec/ directory at project start.
Goal: Define WHAT information is presented and WHY it matters.
Save this file BEFORE proceeding to Step 2:
# spec/1_information_architecture.yaml
dashboard:
name: [Name]
purpose: [One sentence goal]
pages:
- name: [Page Name]
purpose: [What question does this answer?]
kpis: [List of 3-5 key metrics]
data_sources:
- name: [Source Name]
type: [csv/database/api]
decisions:
- decision: [What was decided]
reasoning: [Why this choice was made]
Before proceeding to Step 2:
Detailed guidance: See information_architecture.md; Anti-patterns: See common_mistakes.md section "Step 1: Requirements Mistakes"
Goal: Define HOW users navigate and explore data.
Tier 1: Global Navigation
├── Multi-page sidebar (automatic in Vizro)
└── Page selection
Tier 2: Page-level Controls
└── Filters/Parameters in left collapsible sidebar
Tier 3: Component-level
├── Container-specific filters/parameters
├── Cross-filter, cross-highlight interactions
└── Export actions
Load the designing-vizro-layouts skill for grid system, component sizing, filter placement, and selector rules. Use the wireframe templates when building ASCII wireframes for user approval.
Save this file BEFORE proceeding to Step 3:
# spec/2_interaction_ux.yaml
pages:
- name: [Must match Step 1]
layout_type: grid # or flex
grid_columns: 12
grid_pattern: [[0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3]] # Component placement
containers:
- name: [Container Name]
has_own_filters: true/false
filter_placement:
page_level: [columns with selector types]
container_level: [columns with selector types]
wireframe: |
[ASCII wireframe for ALL pages and tab views]
decisions:
- decision: [What was decided]
reasoning: [Why this choice was made]
Before proceeding to Step 3:
Anti-patterns: See common_mistakes.md section "Step 2: Layout Mistakes"
Goal: Choose appropriate chart types and establish visual consistency.
Load the selecting-vizro-charts skill for chart selection, color strategy, anti-patterns, and KPI card rules. Key design decisions:
color_decisions in the spec. Vizro assigns palettes automatically. Only include if the user explicitly requested custom colors in their message.kpi_card / kpi_card_reference; never rebuild as custom chartsSave this file BEFORE proceeding to implementation (dashboard-build skill).
# spec/3_visual_design.yaml
visualizations:
- name: [Chart Name]
type: [bar/line/scatter/etc]
needs_custom_implementation: true/false
reason: [if custom: has_reference_line/needs_data_processing/etc]
# DO NOT include color_decisions unless the user explicitly asked for custom colors in their message.
kpi_cards:
- name: [KPI Name]
value_column: [column]
format: [e.g., '${value:,.0f}']
has_reference: true/false
decisions:
- decision: [What was decided]
reasoning: [Why this choice was made]
Before proceeding to implementation (dashboard-build skill):
color_decisions is absent unless the user explicitly requested custom colorsAnti-patterns: See common_mistakes.md section "Step 3: Visualization Mistakes"
| Reference | When to Load |
|---|---|
| information_architecture.md | Step 1: Deep dive on requirements |
| designing-vizro-layouts skill | Step 2: Grid system, component sizing, filters |
| wireframe_templates.md | Step 2: Wireframe templates and interaction labels |
| selecting-vizro-charts skill | Step 3: Chart types, anti-patterns |
| common_mistakes.md | All steps: Anti-patterns to avoid |