Five Questions to ask before starting a dashboard

Written by Jennifer Bradford (Phastar), Julie Russell (Bayer), Milan Geybels (Novo Nordisk), Marie‑Laure Casadebaig (Incyte) and Peter Krusche (Novartis)

Introduction
Dashboards are powered by data, summarizing one or more data sources into an effective tool, to continuously monitor, analyse and present information for decision making. They can be extremely effective for communicating messages to an audience and in this blogpost we bring together some key questions you may consider before deciding to convey your message using a dashboard.

1. What is a dashboard?

First thing, let’s consider what a dashboard is and how that might differ from a report. A dictionary definition of a dashboard is “a user interface or web page that gives a current summary, usually in a graphical, easy-to-read form, of key information relating to progress and performance”.

A dashboard is an interactive, graphical representation of data, which can summarize a lot of information into key messages with a limited focus. Dashboards are usually linked to one or more data sources, resulting in a dynamic (updated as data changes) interface. Dashboards are typically hosted on a server to make them accessible to end‑users.

The remainder of this blogpost will focus on key questions to consider before starting a dashboard. Hopefully these will serve as a useful guide, ensuring you think about your message, your audience, the right medium or platform and how to avoid some common pitfalls.

2. Do I need a dashboard? Dashboards and reports are used to summarise data, see the difference below:

Creating a dashboard and maintaining it takes time and effort:

• Everyone focuses on development time rather than maintenance time to address dashboard evolution/troubleshooting,
• 20:80 rule — 20% of time is needed to make it look ready (mock it up) but actually 80% of time to make it ready,
• It is important to factor in maintenance. Even after launch, a dashboard requires maintenance as data or software may change,
• Since dashboards are dynamic, they can evolve, this evolution will require further programming resources.

If you only need to answer the question once you probably don’t need a dashboard, consider using a report.

If you intend to review your data on multiple occasions you might need a dashboard, especially if:

• You want to look at different data subsets (e.g., patient subgroups),
• You wish to incorporate the ability for end-users to manipulate the data, e.g. filters, and/or
• What you wish to show cannot easily be done in a static report, for example, complex visuals or interactive review of thousands of genes.

Different software solutions exist for dashboarding. Among the most popular tools are Shiny (R), Dash (Python) and Tableau, but many others exist.

Assuming you feel that a dashboard would be the best solution for your situation, 3. What is my message?

Without a clear message it is difficult to develop a focused dashboard, which is key. Ideally, a dashboard is designed so that important conclusions can easily be drawn by stakeholders. Furthermore, given a clear message, it will be easier to reach early agreement with stakeholders on the design and layout of the dashboard.

Ideally, a dashboard is made because there is a clear need from stakeholders as then there is a higher chance for the tool to have a real impact and improve processes. A dashboard should not be made simply because it is possible. The development team should agree on the visualizations and features (options) before the programmers go to work.

This is an example of a focused dashboard from FiveThirtyEight. Here, a clear question was posed and addressed using a dashboard: How popular/unpopular is Joe Biden? The dashboard has a relatively simple interface, with one interactive figure, and only focuses on the key statistics needed to address the question posed.
https://projects.fivethirtyeight.com/biden-approval-rating/

Another example, coming from clinical drug development, was the use of dashboarding to display individual patient profiles of patients in haemophilia clinical trials (where all patients received the same investigational drug; no active drug would be considered unethical). The question the team aimed to address was: are there any patients with outlying profiles? This was easy to do using a dashboard that visualized all key efficacy and safety information in a plot of time (x-axis) versus dose taken (y-axis). Stakeholders could easily browse many patient’s profiles. Furthermore, data were updated regularly and after each new data load the team would meet to review and discuss the updated profiles.

A further example is a dashboard aimed to address the question: What are the differences between treatment groups in relation to the development of AEs? This was addressed by AdEPro: Animation of Adverse Event Profiles which allows users to visually explore individual adverse event study data
https://link.springer.com/article/10.1007%2Fs43441-020-00178-4

A final example is a dashboard aimed at presenting the outcomes and/or summaries of data exploration. A number COVID-19 dashboards have been created for this purpose allowing end-users to review cases, deaths, and vaccination data globally, regionally and by country through a selection of graphical and tabular presentations, see for example the WHO COVID-19 dashboard
https://covid19.who.int/

In conclusion it is much easier to make a question-driven dashboard than a generic data exploration tool.

4. Who is my audience? You need to know the typical data views (figures and tables) that your audience is used to and expects. e.g., a genetics audience may be used to different types of plots compared to a medical audience.

Also, it is important to factor in user-experience. That is, a more technical audience may appreciate more functionality (e.g., buttons, sliders, drop-down menus, data sheets) compared to an end-user less familiar with inspecting lots of information in an interactive way. Often, it is a good idea to have some in-text description of how to use the app and different functions within it.

5. What could possibly go wrong?

1) Your dashboard may not be scalable, that is, not flexible enough to address an accumulating data pool or functionality.
a) For example, suppose a dashboard was created to address a certain volume of data but the volume of accumulating data begins to slow the performance of your dashboard.
b) For example, end-users want more detail that is difficult to implement (e.g., the dashboard currently presents information for a specific time point but end-users request that it include all time points).

2) People are not using the dashboard as much as expected. This could be due to lack of promotion. One should not assume that a single kick-off event is sufficient to convince people to use a new dashboard. It is the responsibility of the dashboard team to both promote the dashboard (e.g., via a formal launch, by asking for feedback, and building use-cases based on the dashboard) and educate stakeholders in using the dashboard (e.g., training sessions).

3) Results from your dashboard are misinterpreted. This can be prevented by clear instructions and provision of a data example illustrating how to interpret results e.g., the statistical model. Here it is also important to always have a point of contact listed for the dashboard; someone who is available to address questions and help the end-user. Further, in-text instructions can also be helpful.

4) No information on user-experience feeds back to you. This can be resolved by connecting with the end-users and asking for feedback (e.g., via a survey).

5) Your dashboard stops working which may occur as software/data structures change over time. For this reason, it is important to allocate resources to dashboard maintenance. Maintenance needs must be balanced with addressing “scope creep” which takes the dashboard beyond its original intent and potentially beyond your available resourcing.

We value your comments — please get in touch!