4 Things to Consider Before Dashboard Design

What is a Dashboard?

Before we even begin the process of discussing requirements, visuals, or platforms it’s important to understand what a dashboard is. It may be obvious, but a business intelligence dashboard takes its name from the vehicle dashboard or dash.


The car dash(board) above and each element and visual serves a very specific purpose and that is to provide the driver with the necessary information to operate the vehicle safely.

Looking at the above dashboard. How many pieces of information are being displayed to the driver at any given time (excluding warning indicator lights)?

12!

Much like a vehicle’s dashboard provides key information for a user to operate the vehicle safely a business intelligence dashboard should provide specific information for a very specific purpose and for a very specific audience. This post will walk you through the process of creating a dashboard to help you understand what questions you need to answer before building a dashboard, where dashboard data comes from and the required effort and time to build an effective dashboard.

Here are four things you must consider in order to embark on your dashboard journey.

Decisions / information

The first step to building a dashboard has nothing to do with a dashboard. The first step is to identify the decision(s) you need to make. A dashboard is merely a visual representation of the information you need to make those decision.

Let us take a look at the car dash as an example. Below is break down of a few decisions a driver needs to make and the information needed in order to make those decisions:

DecisionInformationVisual
Do I need to speed up or slow down?How fast am I going?Speedometer
Do I need to add fuel to my car?How much fuel is in my car?Fuel Gauge
I need to go forward/reverse.What gear am I in?Gear indicator
Is my engine over heating?What’s my engine temperature?Engine temperature gauge

Just as each visual in a car’s dash provides information for a driver to make a specific decision a business intelligence dashboard should do the same. Each visual should provide specific information in order to inform a specific decision/action.

For a typical PCI business intelligence dashboard, the breakdown of decisions, information and visuals might look like this:

Coverage, targeting, completion of tasks, actual vs. targets, rapid decisions using real time data

Some information needed to make those decisions could include the following:

  • How many people served
  • Location/timeframe of services
  • Dollars spent
  • Sex desegregation
  • Changes over time
  • % completed
DecisionInformationVisual
How many surveys have been completed, and have we collected enough data?Number of surveys completed, by dateBar graph showing number of surveys completed against the target number of surveys
What kind of coverage do I have in the different communities of the intervention area?Number of interventions, services and beneficiaries by communityHeat map with color coding for different levels of coverage in each community
How many females and males am I serving with intervention X?Number of beneficiaries of intervention X, by sexPie graph with % and number of beneficiaries for intervention X, by sex

We make lots of decisions at PCI that a dashboard can help inform.  From a project perspective, we typically use key performance indicators (KPIs) as the information source to inform those decisions.  And we typically align those indicators to the project Theory of Change/Results Framework.  But in business intelligence, the indicator should align with a decision point, so if there is a decision that needs to be made and we don’t have project indicator data to inform that decision, it might be time to think about designing additional indicators.

Frequency

Back to the car example: How useful would a car dash be if it only provided information every 2 days?

A car’s dash provides information in real time. However, few business intelligence decisions require real time data. Determine how often do you need to see information to make the necessary business decisions.

Is the decision being made every year, quarter, month, weekly, or daily? The more frequently data is collected and dashboards are used, the more useful and informative the dashboard will be.  So consider focusing your dashboard on the most frequently made decisions.

Data Source

Now that you know what decisions you need to make and what information is needed to make those decisions it’s time to identify the data source.  Dashboards require an underlying data source, or data sources.  If the data are not readily available, or do not yet exist, then a dashboard is not the right solution for you at this time.  Instead, take a few steps back and start thinking about what data you need to support your decisions, and how you are going to collect that data.

Data in a dashboard do not need to all come from the same place.  Dashboard platforms have the ability to pull in the data from multiple sources at the same time.  Data sources that work well with dashboards include SQL databases and cloud based relational databases like Salesforce. The most important factor here is that data can be accessed via the internet and not data that needs to be manually exported and uploaded to a business intelligence platform.

Also consider what form that data are in.  Dashboards and dashboard developers are not good at cleaning and coding data, this should be done before integrating a data source with a dashboard.  So consider the following:

  • Are the data in their rawest form (Not IPTTs)?
  • Are the formulas for computed/calculated variables clear (Note that dahboards ARE good at creating new calculations, but the formulas need to be clear ahead of time)?
  • Are data complete. For example, if you want a map on your dashboard, are data geo coded?
  • Are all data in one column the same data type (number, currency, text, date, etc)?
  • Are variables clearly labeled (either in the data or with a data dictionary)?

Audience

Understanding who the users are is key in focusing the design of a dashboard.  Who will be consuming the dashboard and making decisions based on the information presented?  In the car example, a car’s dashboard is designed for the driver to help them drive safely (slow down or speed up, add fuel or not, drive or reverse, etc.).  If you were designing a car’s dash for a backseat driven, it would likely look different.   Or, if you were a car manufacturer that needed to see engine performance of your entire fleet of vehicles, your dashboard would also look different.

 Now what?

Now that you’ve thought through each of the 4 considerations before dashboard design you are ready to engage a dashboarding team. There’s a specific process that is used in building a dashboard and that process is very much akin to the technology lifecycle.

Dashboard Lifecycle

  1. Requirements Gathering:

The 5 considerations before a dashboard

This first step would be to formalize the requirements and determine a workplan as well as how to publish/host the dashboard.

  1. Data Integration

Determine how to get the data and the data protocols required. What format does the source system export the data in? Is there an API?

  1. Data Modeling and Transformation

Any manipulation and/or formatting done to the raw data. This could be changing data labels, coding variables, or setting hierarchical relationships between data.

Connecting related data tables

Calculations will need to be created using the data and each calculation needs to be tested and verified. Examples could be household size is the sum of all household members.

  1. Design and test the dashboard

The first functional prototype is to ensure that data can be queried and the calculations are working. This stage the designer will pull the data, shape the data, create calculations and visuals that reflect the requirements.

Validate Prototype

The designer will take the prototype and validate with the primary audience of the dashboard. Does each visual provide the necessary information for decision making? What stylistics changes does the end user want?

Build final dashboard

The designer will incorporate feedback from end users and then build the final dashboard. This often includes finalizing the data model, data shape, and the style of the dashboard. This is where art meets science with much flexibility given to the designer.

  1. Publish the dashboard

This process involves preparing dashboard for its final form. This process also involves setting up necessary integrations such that data is automatically refreshed and that the final dashboard is made available as outlined in the requirements.

Training end users

  1. Monitoring and reporting

Ensure that data is updating the dashboard and look for any issues regarding the final dashboard.