15.1 Introduction

A dashboard is “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” (Few 2006). This definition highlights three properties that distinguish dashboards from other BI deliverables: they are visual (not tabular), consolidated (one screen, not many pages), and at-a-glance (designed for rapid comprehension, not deep reading).

The term “dashboard” is borrowed from automobiles, where a driver monitors speed, fuel, and engine status without looking away from the road. Business dashboards serve the same function — they give decision-makers a real-time or near-real-time view of organizational performance without requiring them to dig through raw data or lengthy reports.

15.1.1 Dashboards vs. Static Reports

Not every BI deliverable should be a dashboard. Static reports — PDF documents, HTML pages, or slide decks generated at a fixed point in time — remain essential for many purposes:

  • Compliance and audit: Regulators often require dated, versioned documents that capture the state of a metric at a specific time.
  • Deep analysis: A 20-page report on the root causes of rising absenteeism provides depth and narrative that a dashboard cannot.
  • Communication to broad audiences: A report can be emailed, printed, and read offline; a dashboard requires a browser and sometimes a network connection.

Dashboards excel when the audience needs to monitor changing conditions, explore data interactively, or make frequent decisions based on current metrics. The choice between a dashboard and a report — or a combination of both — should be driven by the audience’s needs, which is exactly what the business requirements specification from Chapter 13 captures.

15.1.2 Generating Reports in R

Quarto provides a natural path for generating static reports alongside dashboards. As introduced in Chapter 3, a Quarto document (.qmd file) combines narrative text, code, and output into a polished PDF, HTML, or Word report — using the same data pipeline that feeds a dashboard. This means the analytical work is done once, and the same code can produce both a live dashboard and a periodic report.

Parameterized reports extend this capability by allowing a single Quarto template to generate multiple versions of a report. For example, a monthly absenteeism report template might accept department and month as parameters, producing a customized report for each department without duplicating code. The command quarto::quarto_render("report.qmd", execute_params = list(department = "Operations", month = 3)) generates the Operations department report for March. This is particularly valuable for organizations that need standardized reports across many units — the template enforces consistency while the parameters provide customization. See the Quarto appendix for full details on parameterized reports.

15.1.3 The Last Mile of BI

Dashboards sit at the end of the BI pipeline. Every technique covered in this book — data cleaning (Chapter 5), visualization (Chapter 7), modeling (Chapter 9), and data mining (Chapter 11) — produces outputs that ultimately need to reach a decision-maker. The dashboard is where that delivery happens. A model that predicts employee absenteeism risk is useful only if its predictions are surfaced in a format that an HR manager can act on. A trend analysis is valuable only if the people responsible for the trend can see it.

This “last mile” framing matters because it determines what the dashboard must do. It is not a showcase for the analyst’s technical skills — it is a tool for the stakeholder’s decision-making. Every design choice, from which metrics to display to how the layout is organized, should be evaluated against one question: does this help the user make better decisions faster? (Dresner 2007)