Skip to content

# [RFC] End-to-End Dashboard Development Workflow with vizro-e2e-flow #1504

@lingyielia

Description

@lingyielia

Have you already looked into this request?

  • I've reviewed the Vizro documentation to see if this feature is already supported, including through Vizro extensions
  • I've searched through existing issues for similar requests
  • I've already searched online (e.g. Dash documentation) but couldn't find anything relevant

Which package?

None

What's the problem this feature will solve?

Summary

With the introduction of vizro-mcp, LLMs can now generate fairly accurate Vizro dashboard code, making the "how to build" part significantly easier. However, the harder problem remains: "what to build" and "how to structure the dashboard" based on audience needs and business context.

This RFC proposes vizro-e2e-flow, a structured 5-stage workflow implemented as Claude Code skills, to guide users from initial concept through Information Architecture, UX design, visual design, implementation (leveraging vizro-mcp), and testing.

This extends Vizro's existing technological solution to automating dashboard best practices, to further enable users to design and build dashboards in Python.

#1481

Problem Statement

Current State

  • Implementation is now easier: vizro-mcp enables LLMs to generate accurate Vizro dashboard code
  • Design decisions are harder: Dashboards can be structured in vastly different ways depending on:
    • Audience role: C-suite executives need distilled, high-level insights vs. operators need detailed, thorough information
    • Business context: E.g., retail dashboards prioritize sales funnels, while healthcare dashboards focus on patient outcomes and compliance metrics
    • Data complexity: E.g., single KPI trends vs. multi-dimensional cohort analysis across time, geography, and product segments
    • User goals: E.g., "Why did sales drop?" requires drill-down paths and comparisons vs. "What's our status?" needs high-level summary views

The Gap

Users often jump straight to implementation without properly thinking through:

  1. What analytical questions should the dashboard answer?
  2. How should information be organized across pages?
  3. What's the appropriate level of detail for the target audience?
  4. How should users navigate and interact with the data?
  5. What visual design choices best communicate the insights?

This leads to dashboards that don't align with user needs or poor UX that confuses users.

Describe the solution you'd like

Proposed Solution: vizro-e2e-flow

A 5-stage workflow implemented as Claude Code skills that guides users from idea to meaningful dashboard:

Stage 1: Information Architecture

Purpose: Define WHAT information will be presented, WHY it matters, and HOW it's organized

  • Map analytical questions to dashboard pages
  • Identify and structure KPIs
  • Define data sources and relationships
  • Create audience-appropriate information hierarchy

Output: spec/1_information_architecture.yaml

Stage 2: Interaction/UX Design

Purpose: Design HOW users navigate and explore data

  • Design navigation structure and page flow
  • Define filter strategy and placement
  • Determine layout logic
  • Create wireframes (ASCII)

Output: spec/2_interaction_ux_design.yaml + wireframes

Stage 3: Visual/Data Design

Purpose: Translate wireframes into visually compelling designs

  • Select appropriate chart types for each insight
  • Establish visual hierarchy
  • Define color strategy and typography

Output: spec/3_visual_data_design.yaml

Stage 4: Development/Implementation

Purpose: Build the working dashboard using Vizro

  • Review specs generated from prvious stages
  • Set up data connection
  • Implement visualizations and interactivity

Output: Working Vizro dashboard code

Stage 5: Test & Iterate

Purpose: Test basic dashboard functionality (smoke testing)

  • Launch dashboard and check for startup errors
  • Test navigation between pages
  • Verify filters and controls work correctly
  • Check console errors

Output: spec/5_test_report.yaml documenting issues found

Key Features

  1. Structured specifications: Each stage produces YAML spec files that serve as binding contracts for later stages
  2. Flexible entry points: Users can start at any stage depending on their starting point (Proposed but not fully tested yet)
  3. AI-native workflow: Designed specifically for LLM-assisted development
  4. Integrated tooling: Pre-configured MCP servers (vizro-mcp, playwright) for producing bug-free code

Current Implementation Status

The vizro-e2e-flow plugin is currently in development at /vizro-e2e-flow/ with:

  • All 5 skills implemented with initial guides
  • Reference materials attached to skills for areas need deep dive
  • MCP server integration (Vizro MCP, Playwright MCP)
  • YAML spec templates for each stage

Request for Comments

We need feedback on:

1. Workflow Structure

  • Is the 5-stage breakdown appropriate? Should any stages be split or merged?
  • Are there missing stages or considerations?
  • Does the linear flow make sense?

2. Skill Content Quality

  • Are the guidance effective and simple enough?
  • What can we remove from the current version?
  • Any critical points missing?

We have a first-pass implementation and need domain experts to validate and enhance the content in each skill.

3. Specification Format

  • Is YAML the right format for specs?
  • What additional fields or structure would be helpful in the spec files?

4. Integration Points

  • Should this workflow integrate with other tools (Figma, V0, etc.)?
  • Are there other MCP servers that would enhance the workflow?
  • How can we better support team collaboration in this AI-assisted process?

5. Success Metrics

  • How should we measure the effectiveness of this workflow?
  • What outcomes indicate a "well-designed" dashboard?

Use Cases

This workflow is particularly valuable for:

  1. Teams without deep design expertise building dashboards
  2. Teams creating audience-specific views of the same data
  3. Teams rapidly prototyping dashboard concepts
  4. Teams delivering dashboards across diverse client contexts
  5. Teams standardizing dashboard development practices

Related Work

Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions