This article focuses on business intelligence dashboards: How to approach design with purpose – stakeholder needs, dashboard types and strategic implementation, and includes practical case studies.
Perhaps your organisation has started to approach the end of Phase I of your business intelligence project, and the time has come to start leveraging the newly aligned data for consumption.
Alternatively, your organisation may want to consolidate and regenerate the existing set of reports and dashboards built up organically and spread disparately across the organisation over time, with neither a consistent grain and definition or look and feel.
The task may appear to be a simple request at first. With so many powerful tools available in the marketplace that claim to make “Data Visualisation” a snap, you may think this is an effortless process.
As you start to review the collection of reporting requests or piles of information being generated, two questions quickly come to mind – “Where do I start” and “How do we get value from our BI Investment”?
How to design a BI dashboard
At QMetrix we take a high-level approach of understanding the principles of strategic information consumption before moving on to dashboard design. These principles are focussed on:
- identifying the audience,
- understanding the information that is needed and how to group this information logically, and finally
- determining the most effective style of distributing the information to the end consumer.
For those of you who have been in the cockpit of an aircraft, you will be familiar with the extraordinary number of dials and controls on a pilot’s dashboard as compared to a car. This is because the pilot needs all this information to be available to him/her to enable a safe flight.
Historically, these individual pieces of data have been grouped into logical individual pieces of information delivery. In the age of digital flight dashboards with customisation available, many of these dashboard items are still collected into logical groupings.
For example, altitude, rate of climb, angle of climb and controlled air space height ceiling are always grouped together for easy and relevant reference.
Each of these is then aligned for information consumption by different members of the crew – Captain, First Officer, Engineer. Each of these members need to be able to focus on different pieces of crucial information relevant to their role in order to support a decision-making process.
This is similar when approaching the creation of a suite of BI dashboards for an organisation.
At QMetrix, we generally follow these five strategic points when approaching a dashboard project.
- Identify your different ‘Information Consumers’
Captain, Co-Pilot, Steward and Flight Engineers all have different immediate needs, just as the CFO, Operations Manager, and Business Analyst have different needs. The type of information they want to see and how they consume it is very different. Catering to your audience is an important key to success.
- Consider the type of dashboards
Each type of dashboard contains information consumed differently. Be cognisant of the needs for different styles while still trying to maintain a consistent look and feel.
- Group information topically
Don’t put the fuel warning light next to the toilet block indicator. It may seem like common sense but so often we see poorly conceived dashboards where information is scattered all over the screen simply in an effort to “use the page”.
- Be strategic about implementation planning
Don’t boil the ocean; focus on the users, understand their needs and plan your delivery.
- Keep it simple, relevant and focused
Although the cockpit of an aircraft may seem overwhelming, a lot of thought and consultation has gone into ensuring that what is needed is there, and what is not needed isn’t included.
Let’s dive into each of these points in more detail.
1. Identify your Information Consumers
The most important step in building dashboards and reports is to consider your audience, understand the message they want to see, and then write it down.
Try and recognise the audience’s pain points and what they are looking to achieve to make their day an easier experience. Does putting all this information on the dashboard of your car make it an easier driving experience or more complicated?
As difficult as it can be, we recommend you take a step out of the “day-to-day mentality” and approach things from a different angle. At QMetrix, we have the ability to observe the challenges across the organisation both horizontally (across divisions and departments) and vertically (from C-level executives through to business analysts).
Each of these people have their own diverse needs, and the focus of your dashboards should be giving access to common and consistent information which is relevant and easily digestible.
Equally as important is to understand how your information consumers need to use the dashboards you provide. A CFO that glances at a daily summary on their phone in the lift should be different to an operations manager who may have a screen always visible with near real-time metrics.
2. Consider the type of dashboard
First, a word of warning. Having previously worked with organisations where there was a “standard template” which every reporting project had to follow, QMetrix is familiar with the issues that dashboard builders start to face with the single “standard template” approach.
It is difficult to shoe-horn the diverse needs of the information consumer into a “standard template”. Ironically, this rarely results in the outcome being aligned to anyone’s true requirements. It is therefore vital to challenge the notion of the “standard template” before expending too much effort.
When asked to approach a dashboard design project, it is crucial to understand what the dashboard should actually do – a.k.a. what is its purpose in the organisation? Does it need to enable instant access to real-time (or near real-time) information, or should it support executive decision making?
At QMetrix, we usually see the dashboarding request fall into one of three basic groups – Operational, Strategical, or Analytical.
- Operational dashboard: An operational dashboard is used principally to monitor operations, usually to facilitate the management of processes or actions. The timescale of an operational dashboard is usually extremely short, often immediate, aka “What is happening NOW?”.
An example of how an operational dashboard can be effectively used is in a call centre to demonstrate the number of calls in a queue or staff available.
Another example is this dashboard below, built in Power BI for an Orange Packing Warehouse. It is displayed on the Production Manager’s phone for easy access and integrated with alerts. We have optimised the screen space available, while calling out the immediate data values relevant to the Orange Packing Warehouse.
When combined with alerts, the Production Manager can see immediately the important information required in real time, alerting her to those which need attention by the use of colour and simple spark lines.
- Strategic dashboard: A strategic dashboard is so called as it is not frequently referred to; it is typically observed on an infrequent but regular interval.
Often the information is strongly focussed on historical trends and designed to allow the observation of high-level indicators, thus enabling the monitoring of critical indicators in an organisation.
An example may be a HR dashboard that shows the accumulation of outstanding leave values (both from a financial and chronological perspective).
- Analytical dashboard: An analytical dashboard is often rich in data, but logically grouped and well-presented. This enables the consumer to effectively slice and drill into large amounts of information collated as a summary presentation, without losing the layout and feel of the original dashboard.
A key element of analytical dashboards is having an effective layout to ensure large pieces of information are logically grouped to allow access for instant consumption.
Although it may be tempting to incorporate varying pieces of information into a single dashboard, ask yourself if it is relevant to the consumer’s role. Is a C-level executive going to be interested in sales volumes as well as the number of customers currently waiting on a phone queue in the call centre?
Understanding which piece of information and which style of dashboard you should be pursuing is important to ensure your dashboard is designed for effective consumption.
3. Group information topically
It is important to consider the relevance of information and how that information may be consumed by end users. Grouping of information into relevant topics supports instant decision making and helps “tell a story” without the need to navigate away to achieve the answer required.
Let me give you an example.
Case Study Part 1
We are building a new dashboard page to monitor the fuel status of 12 diesel generators in a factory. During the initial requirements review we are handed a Business Requirements Document (BRD) that describes the need to monitor fuel consumption on a new dashboard.
As part of the requirements gathering phase, we interview the Operations Manager and discover the factory has a large single tank and she would like to see the amount of fuel each generator uses on a new page.
She shows us an existing dashboard set with multiple pages – one that demonstrates the wattage output of each of the generators and another showing the oil temperatures and pressure of each generator.
We suggest that perhaps instead of a third page showing fuel, the Operations Manager would be interested in seeing a two-page dashboard:
- Page 1 – Operational dashboard: Showing high level statistics such as fuels flows, total power output, operating hours till maintenance, and a separate call out section showing the operational status of all generators and calling out any alarms that perhaps need to be investigated (oil pressure, fuel flow, etc).
- Page 2 – Analytical dashboard: Showing detail on the individual diesel engines including current statistics like oil pressure, temperature, fuel flow, air flow power output, and then a small set of charts (or spark lines) demonstrating statistical movement over time.
The Operations Manager is happy and can’t wait to sign off on her new dashboard layout.
4. Be strategic about implementation planning
Apart from considering which dashboards you are going to develop, you need to think of who your first consumer will be, and where this consumption will lead.
Often, we find that developing an effective dashboard simply increases demand rather than satisfies it, so it is important to be across the needs of the organisation from a wholistic perspective. In doing so you will be able to identify synergies across different divisions or areas and leverage existing developments to satisfy those needs. This will greatly improve planning and implementation.
As telling a story is very rarely achieved from a single perspective (there can be many moving parts that contribute to the source of questions), it provides the opportunity to take a step back and work with several areas of the business to investigate these moving parts.
From the above case study, we can see that the Operations Manager was focussed on her part of the problem. However, there were other areas of the business that could benefit from accessing that same information.
Although we may appear to have a happy customer from our case study above, there may be opportunity to leverage the dashboard requirements for additional business users.
Case Study Part 2
Following up with the business in the previous case study, we discovered the Supply Manager was responsible for ensuring the availability of onsite storage of diesel and that reporting the fuel status (both current and historical) was an important piece of information.
Rather than develop the reporting information requested in silo, we asked the Operations Manager if we could enhance the dashboard that she and her team were using to include an additional piece of information – “Fuel Storage Levels”.
As it turns out, she was quite excited at the suggestion as she quite often had to ask the Supply Manager for these numbers and calculate them separately for her daily capacity planning.
Having discovered the synergies in need for information, we organised a meeting with the Operations Manager and Supply Manager to discuss each of their reporting needs from a wholistic perspective.
By working across multiple areas of the business, we can begin to understand how the information flows from one area to the next and where crossovers exist in requirements.
5. Keep it simple, relevant and focused
One of the important principles to try and adhere to when coming up with a dashboard is to focus on information which is clear, simple and concise and assists in decision making, rather than data which may distract the user.
Be careful about putting too many pieces of information together in a single chart and ask yourself: What message do I want to demonstrate?
For example, to show period on period comparisons you could use a clustered column chart. But if you were looking to simply show a trend over time, a single column chart would be better way of demonstrating that trend.
When we work with the consumers of the dashboards, we do our best to understand “the message” that needs to be delivered to the information consumer, and how we can demonstrate information in a clear and digestible format.
Case Study
Ma and Pa Farmer are the owners and CEO/CIO of a national Agri Business called “Farmers Lane”, which grows and distributes a range of agricultural produce.
Following an initial discussion, Ma and Pa are interested in leveraging the investment in capital and understanding how the increase in Monthly Tonnage would reflect in sales over the year 2019.
Although the Gross Sales and Monthly Tonnage gives them an insight into the overall performance, they would like to be able to get further information from each of the farm managers as to how the properties in each region are performing.
Ma and Pa didn’t want a load of flashy charts and complex reports. They were interested in seeing the following facts on both their iPhone and PC to enable decision making:
- Monthly Tonnage Production
- Monthly Gross Sales
- The relationship between the two
- How much sales have been achieved in the year
- The Average Monthly Tonnage for the year
By working with the business, we can identify the sources of information needed, and understand at what grain the data needs to be collected in order to support the above requirements.
Based on these initial discussions we can start considering which dashboards are going to be needed – Strategic, Operational, or Analytical.
We have also been able to identify key stakeholders that need to be engaged in order to collect additional requirements, as well as sources of data to present the information that Ma and Pa need.
To satisfy the immediate need for Ma and Pa, we deliver an initial module with three visualisations – a single chart and two data cards.
The above example shows neatly a way of grouping several pieces of information as well as a clear trend that is easy to digest. The different relationship between Monthly Tonnage and Gross Sales is clearly defined by utilising a “Line and Column Chart”.
We have demonstrated the movement over the year in the C-level Strategic dashboard. Ma and Pa can now see how one of the key drivers of the business (Monthly Tonnage) is performing, and gain insight into how that is driving an increase in sales.
In addition to the chart, we have several simple card visuals with icons chosen to ensure the eye was drawn to the section of the dashboard that held the relevance of Monthly Tonnage. As the business was in farming, the tractor was chosen to clearly associate the number with Production.
Closing comments
One of the important things to understand when deciding what to include in a dashboarding or reporting project is how to include enough information without removing the ability to understand facts. This is always made easier by following our five points above.
As a final example, imagine the dashboard on a car. It has a fuel gauge which gives you a rough idea of how much petrol exists in your tank.
Imagine if instead of showing you a relative amount ie, it’s just under half full with a light when it’s about to run out, you were given a number which represented the litres remaining in the tank – perhaps it said 27L.
This number would be irrelevant if you didn’t know the volume of your tank, requiring yet another number – let’s say 65L. Now we can work out that the tank is 41.54% full (or a smidge under 50%), so we can display that number too.
In our example, is it easier to show our information consumer:
- A gauge showing the tank is just under half full
- The exact amounts of three numbers –
- 27L
- 65L
- 41.54%
- Or is it better to have both?
From a dashboarding perspective we would break these pieces of information into two groups:
- Operational ie, half full, is going down, got some left, just under half, no problem yet.
- Analytical ie, we have 27L remaining in a 65L tank which equates to approximately 41.54% of our fuel reserves, so at a burn rate of approx. 9.6L/100km we should be able to drive for another 281km before we need to put more fuel in the tank.
If we remember the five-point approach we could ask ourselves the following questions about our fuel display:
Q1: Who are our Information Consumers?
A: Drivers of all ages and skill sets.
Q2: What type of dashboard should I have?
A: A Strategic dashboard for key facts (speed etc), and possibly a supporting Operational dashboard for other features (radio etc).
Q3: How should I topically group my information?
A: We would discourage putting the radio station in front of the speedometer.
Q4: Is our information delivery planned?
A: We have focused on the immediate needs, whilst allowing future information to be displayed effectively on support dashboard(s).
Q5: Have we kept it simple?
A: Perhaps putting the various metrics of fuel consumption on a car dashboard isn’t needed, but a supporting dashboard for the trip computer would be useful.
Remember: To be effective, a dashboard needs to be designed for specific objectives and should provide a purpose each time it is referenced.
So, the next time you are tasked with designing a dashboard (or suite or dashboards), ask yourself these five questions. Place yourself in the information consumer’s shoes and relate to the problem they are trying to solve – did you help answer the question, or just leave them puzzled with more questions than before?
Don’t be afraid to reach out for help if you feel your dashboarding projects are struggling and you need additional support.