Creating Dashboards in Shiny for Python

Isai Guizar


Dashboards are among the most powerful tools in business intelligence and data science because they transform raw data into accessible, decision-ready insights. While static charts show what has happened, dashboards invite discovery by connecting data, visuals, and user input in real time. Shiny for Python makes this possible directly in Python, combining analytical tools we introduced in the previous sessions with an easy way to build responsive web interfaces. In this part of the course, we will learn how to design and build reactive dashboards that respond instantly to user input.



1 Fundamentals of dashboard design

A dashboard is a visual information system that connects data sources, transforms them into indicators, and provides an interactive interface for users to explore trends or detect anomalies, hence, facilitates decision making.

Few (2006) defines a dashboard as a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.

A good dashboard satisfies three dimensions:

  1. Relevance

    – Every element answers a question that matters. – KPIs connect directly to organizational or research goals. – “If a metric doesn’t drive a decision, it doesn’t belong.”

  2. Clarity

    – Minimal cognitive load; the story is visible at a glance. – Appropriate chart type (bar for comparison, line for trends, etc.). – Clean use of color, typography, and whitespace.

  3. Actionability

    – Highlights deviations and patterns, not just numbers. – Enables users to drill down or filter for context. —Encourages interpretation (“why”) rather than pure display.

The literature offers a rich variety of perspectives on the design of effective dashboards. For further exploration, see, for example, Bach et al. (2022), Burch and Schmid (2023), and Wexler, Shaffer, and Cotgreave (2017).

1.1 The Five Stages of Dashboard Development

Pauwels et al. (2009) describe a structured, five-stage process that organizations typically follow when developing dashboards.These stages move from identifying what to measure, to ensuring data availability, to establishing causal relationships, forecasting scenarios, and finally linking results to financial performance.

Stage I – Selecting the Key Metrics

The first stage focuses on identifying which performance measures should be included in the dashboard. Two complementary approaches: the general approach, which limits metrics to a core set that can be used across business units for benchmarking, and the tailored approach, which customizes metrics to the organization’s unique strategy, market, and objectives.

Although the tailored approach enhances relevance, it can lead to excessive complexity unless guided by strong managerial leadership to prioritize and simplify.

The key to success at this stage is achieving a balance between comparability and strategic relevance.

Takeaway: Define a small, meaningful set of metrics that reflect strategic goals and avoid over-measurement.

Stage II – Populating the Dashboard with Data

After defining the right metrics, the next step is to populate them with accurate and timely data.This involves identifying data sources, validating their quality, and resolving differences in data frequency—since some indicators (like sales) update daily while others (like brand equity) may update annually.

At this stage is often where many firms stall, as integrating heterogeneous data streams across departments can be technically and organizationally challenging.

Effective coordination between marketing, IT, and analytics teams is crucial to achieve a single, consistent data backbone.

Takeaway: Build reliable, synchronized data pipelines before worrying about visualization.

Stage III – Establishing Relationships Between Dashboard Items

Once data are in place, the dashboard must reveal how these metrics interact. Stage III transforms the dashboard from a reporting system into a true decision support tool.

Managers must identify causal relationships among indicators—for instance, how customer satisfaction affects retention, or how advertising spend influences brand equity and sales.In this stage the authors recommend using modeling methods to uncover patterns.

Understanding these relationships not only clarifies performance drivers but also allows for more informed decision-making.

Takeaway: Move beyond “what happened” to “why it happened” by modeling causal links among metrics.

Stage IV – Forecasting and Scenarios

With relationships among metrics established, organizations can use the dashboard for forecasting and scenario planning.Stage IV applies the underlying models to simulate “what-if” conditions, evaluate budget allocations, or plan marketing campaigns.

In this stage, the dashboard becomes an active management tool—enabling managers to predict outcomes and test assumptions before committing resources.

This evolution represents a major leap from retrospective reporting to proactive decision support.

Takeaway: Use your dashboard as a simulation tool to explore future outcomes, not just past performance.

Stage V – Connecting to Financial Consequences

The final stage links marketing and operational metrics to financial outcomes such as revenue, profits, shareholder value, or market capitalization.

This integration demonstrates how marketing actions contribute to the firm’s overall financial health, aligning dashboard insights with strategic business and investor goals.

At this level, dashboards become strategic instruments that bridge marketing, finance, and corporate management, providing a unified view of how marketing drives value creation.

Takeaway: Integrate marketing and financial metrics to show how actions translate into business value.

1.2 Common Mistakes in Dashboard Design

Few (2006) identifies thirteen frequent errors that undermine the clarity and effectiveness of dashboards:

1. Exceeding the Purpose of a Dashboard

Many dashboards attempt to include everything the designer can measure rather than focusing on what the user needs to know.

Takeaway: A dashboard should monitor key information, not become a full-featured reporting system.

2. Choosing Inappropriate Measures

Including metrics that do not relate to organizational objectives distracts from critical insights. Lesson:

Takeaway: Select only measures that correspond to well-defined performance goals.

3. Excessive Detail and Precision

Overly precise numbers or unnecessary granularity add noise.

Takeaway: Summarize information at a level suitable for quick interpretation.

4. Improperly Designed Display Media

Using 3-D effects, circular gauges, and decorative charts reduces accuracy and wastes space.

Takeaway: Favor simple, two-dimensional displays that communicate values clearly.

5. Poor Use of Color

Color should highlight meaning, not decorate. Garish palettes or inconsistent coding cause confusion.

Takeaway: Apply color sparingly to draw attention or indicate thresholds.

6. Ineffective Layout

Placing items arbitrarily or scattering related information forces the user’s eyes to wander. > Takeaway: Arrange elements according to logical grouping and reading patterns.

7. Cluttered or Unreadable Typography

Too many fonts, small sizes, or bold emphasis everywhere reduce legibility.

Takeaway: Use a limited, consistent typographic hierarchy.

8. Inappropriate or Misleading Graphs

Pie charts, 3-D columns, and area graphs are often misused for data they distort.

Takeaway: Match graph type to the relationship being shown—bars for comparisons, lines for trends, etc.

9. Inconsistent Scales and Encodings

Different scales on similar metrics prevent meaningful comparison.

Takeaway: Standardize measurement units and axis ranges where possible.

10. Ignoring Context

Numbers without reference points—targets, time series, or benchmarks—cannot inform decisions. > Takeaway: Always present values in context to reveal performance direction and magnitude.

11. Inefficient Data-Ink Ratio

Visual elements that do not convey new information (logos, shading, gradients) distract from meaning.

Takeaway: Maximize the ratio of data to ink; every pixel should serve a purpose.

12. Ineffective Use of Space

Screen real estate is often squandered by decorative borders or oversized widgets.

Takeaway: Fit all essential information “at a glance,” typically on a single view or scroll-limited screen.

13. Neglecting the Needs of the User

Designers sometimes optimize for aesthetics or executive taste rather than analytical utility.

Takeaway: Begin with the user’s questions, decisions, and workflows.

1.3 From static visualizations to interactive dashboards

In data visualization, tools have progressed from static charts, which communicate a single finding, to interactive dashboards, where users can explore and filter information on their own.

This shift, from presenting data to engaging with data, sets the stage for our next step: building truly reactive dashboards that update automatically when inputs change.

💡 Reflect

What new kinds of understanding become possible when users go from observing an output to interacting with a visualization?

Think of an example where changing a filter, selecting a date range, or zooming into a chart helped you discover something you wouldn’t have seen in a static image.

To understand this transition clearly, we’ll first look at the difference between static, interactive, and reactive visualizations, and then begin constructing our own dashboard using Shiny for Python.

A. Static plot (Matplotlib) – “what happened?

<Figure size 672x480 with 0 Axes>

B. Interactive plot (Plotly) – “explore it”

<Figure size 672x480 with 0 Axes>

C. Reactive app in Shiny for Python – “informed decisions”

Explore the live dashboard

Interact with the dashboard below to see how static visualizations evolve into a fully reactive Shiny app built in Python.

2 Architecture of a Shiny for Python App

From datacamp:

Shiny is an open-source web application framework for Python (originally for R). It enables data professionals to turn their analyses into interactive web applications. The core of Shiny revolves around the concept of reactive programming, where changes in inputs (such as sliders or buttons) trigger automatic updates in outputs (such as plots or tables) .

There are many benefits to the Shiny framework:

1. Shiny leverages reactive programming, allowing you to build applications that respond dynamically to user inputs, creating a more engaging and personalized experience.

2. Shiny has a user-friendly library and comprehensive documentation, allowing those with basic programming knowledge to create interactive and visually appealing applications.

Here are a few examples where the Shiny framework would be valuable:

  • Interactive Dashboards: Shiny is perfect for building interactive dashboards that allow users to explore and visualize data in real time. You can use these tips to design a stellar dashboard.
  • Data Exploration: Analysts can use Shiny to create applications that enable users to interactively explore datasets, adjusting parameters and visualizations on the fly.
  • Decision Support Systems: Shiny can be utilized to develop decision support systems, facilitating data-driven decision-making by providing dynamic insights.
  • Educational Tools: Shiny is valuable in an educational context, allowing the creation of interactive teaching materials and demonstrations.

Here is a detailed list of why to chose shiny over other popular frameworks

2.1 A Shiny app has three core pieces:

1. UI (User Interface) – declares layout and widgets (every element users observe and interact with are part of the UI ).

2. Server – It consists of functions that take the inputs defined int the UI and process them to produce the output (how data are filtered, transformed, and rendered). Defines reactive logic.

3. App – the object that binds UI and server and runs the app.

2.2 Core concepts

  • Inputs (ui.input_*) Interactive controls in the UI; read in server via input.id().

    • Examples: ui.input_date_range, ui.input_select, ui.input_slider.

  • Outputs (ui.output_* + @render.*) Placeholders in the UI that are “filled” in the server.

    • Examples: ui.output_text ← @render.text, ui.output_plot ← @render.plot, ui.output_plotly ← @render.plotly, ui.output_data_frame ← @render.data_frame.

  • Reactivity

    • Reactive calculations (@reactive.Calc) Cached computations that automatically re-run when any dependency (e.g., an input) changes. Use them to create filtered datasets or shared transforms used by multiple outputs.

    • Reactive events (@reactive.event) Handlers that re-run only when a specific event fires (e.g., a “Reload” button).

  • Session (session) Object for per-user state and utilities (e.g., downloads via @session.download).

  • Layout (ui.layout_sidebar, ui.layout_columns, ui.card, ui.sidebar)

2.2.1 My first app

This is my first app in shiny:

Shiny documentation:

Getting started

Shiny components

Running Shiny apps in the browser

References

Bach, Benjamin, Euan Freeman, Alfie Abdul-Rahman, Cagatay Turkay, Saiful Khan, Yulei Fan, and Min Chen. 2022. “Dashboard Design Patterns.” IEEE Transactions on Visualization and Computer Graphics, 1–11. https://doi.org/10.1109/tvcg.2022.3209448.
Burch, Michael, and Marco Schmid. 2023. “Dashboard Examples.” In, 163–212. River Publishers. https://doi.org/10.1201/9781032657301-5.
Few, Stephen. 2006. “Information Dashboard Design.”
Pauwels, Koen, Tim Ambler, Bruce H. Clark, Pat LaPointe, David Reibstein, Bernd Skiera, Berend Wierenga, and Thorsten Wiesel. 2009. “Dashboards as a Service.” Journal of Service Research 12 (2): 175–89. https://doi.org/10.1177/1094670509344213.
Wexler, Steve, Jeffrey Shaffer, and Andy Cotgreave. 2017. “The Big Book of Dashboards,” March. https://doi.org/10.1002/9781119283089.