Visualisation can be the most powerful way to utilise data, allowing the user to see key messages without having to struggle to interpret the information. However, the power of visualisation is dependent on the designer choosing the right approach, and that choice depends on understanding the needs of the user.
Last month I highlighted MEME (Monitor, Explore, Manage & Explain), a method of understanding users’ needs and choosing an appropriate approach. In this article, I focus on when and how to use the first M, Monitor, to meet the needs of users.
Car dashboards as an example
The most typical visualisation approach used for monitoring is the dashboard. However, too many dashboards fail to meet the needs of users because they contain too many elements, with too much animation, and insufficient focus. Thinking about a car’s dashboard can help illustrate what should be on your dashboard, what should be highlighted and what should be downplayed.
When we look at a car’s dashboard, we can quickly see the following key features:
- The dashboard is for the driver, it is optimised to be readable for the driver and it focuses on information that that driver needs.
- The key ‘widget’ on the dashboard is the speedometer. The driver needs to know the current speed of the car and has options for changing the speed of the car (e.g. accelerator, brakes, and gears). This combination of ‘need to know’ and having a method of responding is a key determinant of what to include on a dashboard.
- Another widget which is always visible is the fuel gauge, indicating how much fuel is available. The driver’s interaction with fuel is less intense than with the speedometer, limited to thinking about when to detour from a route so that the fuel can be topped up. Consequently, the gauge is typically smaller than the speedometer, the precision is less, and its position is less prominent.
- The dashboard contains several widgets that are typically not visible most of the time, for example the oil pressure light, battery alert and an engine warning light. These lights only turn on when the driver needs to be alerted to a problem. By contrast, data dashboards often show alerts in green when they do not need attention, amber for caution, and red for ‘needs attention’. If we did this with a car dashboard we would distract the driver, so why do it for data dashboards?
When designing a data dashboard, think like a car designer. Focus on the user, determine whether they need to know something all the time (like the speed they are travelling at), or do they need to know it periodically (like the fuel gauge), or do they only need to see it when their attention is required (like a battery alert).
Active versus Reactive Monitoring
When designing your dashboard, one dimension that needs to be considered is whether the information that is being shown on the dashboard is being used actively or reactively by the user. In the car dashboard example above, the speed is something the user (the driver) wants to know actively. The driver wants real-time data, and they have methods of changing the speed of the car.
If the dashboard user were monitoring the flow of traffic (and could control, say, traffic lights), or the temperature of freezers across hundreds of retail stores (and they could turn them up or down), or the level of queuing in a service situation (and they could divert staff to optimise cover), then the visualisation wants to be interactive.
The type and prominence of the visualisation will reflect the importance of the information and the intensity of the required monitoring. The speed is important and needs monitoring all the time. Unless the fuel is almost expended, the fuel gauge only needs considering a few times an hour, to allow the driver to decide when to re-fuel.
If a user only wants to be aware of the data if action is required (for example the battery alert), then it is a reactive visualisation. The alert should only grab the user’s attention when a message needs to be conveyed to the user. In terms of data dashboards, user complaints are a great example of something that is reactive. When there are no complaints, the dashboard should be clear, but if complaints start being received, the user should be alerted (if this user is the person who needs to be alerted).
Another dimension that needs to be considered for monitoring dashboards is whether the information should be current status, trends, or both. The difference between status and trend monitoring can be highlighted by somebody who uses an app like Strava to monitor their running or cycling. During a run, they might be interested in seeing current speed (interactive) and heart rate warnings (reactive). However, on a daily or weekly basis, they might want a dashboard that showed health stats over time, hopefully showing them building towards a target.
In the world of customer satisfaction, a service manager might be interested in status reports, for example what is satisfaction like today in a wide range of locations. However, for another team member (one with a more strategic remit), the need and relevant data could relate to trends, for example, which locations are showing a decline in satisfaction.
A nice example of a trend visualisation can be seen on the Worldometers Coronavirus website.
The chart above simply shows the latest data for the United States in terms of deaths. If you look at the day-to-day variations, you will see large jumps. These are caused by lags in the reporting of deaths, for example the data normally suggests fewer people die at theweekend – which is caused by delays in reporting.
The second version of the chart shows the 7-day moving average, removing all of the variation caused by day of week (e.g. the difference between reporting data on a Sunday and Wednesday). For anybody looking at the trend in deaths, the moving average is the line they need to focus on, not the status data. However, people managing things like hospitals will need to know the status data for their hospital, for example how many admissions today, how many discharges today, how many beds are currently free.
Summary
When creating a monitoring dashboard, focus on:
- Decide who is the user, what are their needs.
- Adjust the widgets so that the ones the user needs to focus on are more prominent.
- If a visualisation supports reactive decisions, don’t set its default to be always visible.
- Determine whether the user wants to see the current status of variables, or trends (or both).
