This is design
The role of colour in chart design
Why dashboard designs sometimes fail
We consume a large amount of data in our working lives and, largely, the way we do that has improved over time. We used to share data in Excel files and regularly spend weeks creating static reports to present to people, which were likely out of date by the time they came to be used. Now, it’s just as likely that we have access to data in dashboards instead of being limited to a static spreadsheet. These dashboards update automatically, are available to everyone who needs them, and there have even been training sessions to show people what’s in them.
This is a significant improvement, without doubt, so why can’t people find the information they need?
Often it will come down to a straightforward, yet not effortless, reason: the information has not been presented with the users’ intentions in mind.
This article explains the process that you should go through to visualise the kind of business intelligence your company needs. For now, we’ll assume you’ve already sorted out data quality and the systematic complexities required to make it available in a dashboard, and you’ve selected a dashboarding tool that will do it justice. What now should you do with those tables of clean data?
For most people, it won’t be enough to simply see that data presented in a more visual way if it doesn’t easily enable them to answer their questions and make sensible business decisions using it. Often, dashboards are created to provide a window into a dataset and have quick access to up-to-date charts and tables—someone working with the data wants to show something. These dashboards may not have gone through much testing before being shared widely, and may focus too much on data and not enough on insight. This type of visualisation is great for exploring data, and gaining an understanding of how it works, but not everyone is interested in that kind of view. For many people, it takes time and patience to interact with data in this way, and can be frustrating if they need to hunt around for an answer to a specific question.
Dashboards are at their most valuable when they are designed for a specific purpose, and have taken the needs and constraints of the people using them into consideration. Just as we would present textual information in different ways depending on who it’s for and how it would be read, we should consider these variants when presenting data too. Consider, for example, the language and typography used for a news headline, an email, a report, a presentation—it is quite natural to vary our words and draw attention to different aspects of the information for these purposes, because the needs of the audience are different. The amount of time they have to spend engaging with the information, the intention behind seeking out the information, the action they’ll take after they’ve absorbed it, and so on. The same is true for data. Instead of creating a dashboard to show something, create one to help someone else understand what they need to from the data.
We can approach this using a design thinking process.
First, begin by empathising with the people who would need to use the dashboard (the users) and defining the problems they may be having with the existing dashboards. For example, who are they? What are they trying to do? What decisions do they need to make, or actions might they take upon looking at the data? How much time do they have? What situations will they use the dashboard in? How are they used to making decisions with data otherwise? And so on. Ideally, we’d talk directly to the users, through workshops and interviews, to get their views. You might find that you don’t have easy access to users—in that case an educated guess could help you get to a reasonable starting point to later test with users. It’s often helpful to write down the assumptions that you’re making during this process, so that you can refer back to them and understand how they may have affected your thinking. The information you acquire during this stage will form the basis of your user requirements, so this is an important step in the design process.
These requirements are a valuable tool for you to use to start coming up with ideas for features, functionality, filters and focus areas. Some requirements may not be immediately feasible because of data availability, cost, or some other factor, but you can make the decision to come back to those at a later date. Try to avoid jumping straight to your dashboarding tool at this point, and think about how you can answer the users’ questions with the data you have available. Jot them down, and arrange the ideas into a sensible structure according to who would use a dashboard, how they would use a dashboard, the amount of detail they’d need in a specific scenario, and logical routes from high-level to detailed information. Think about the kinds of filters and navigation the users would need to find their way around and easily access the information they need. While you’re jotting down ideas, it can be helpful to use something that’s easy to adapt as you consider potential scenarios—(virtual) post-its on a whiteboard can be helpful here. Draw links between your screens to show navigation between them and consider what someone might expect to see if they clicked on a specific element of your dashboard. Consider how you can use tooltips and other interactivity to help users easily understand the charts you’ve selected.
Planning your dashboard like this, holding back on immediate delivery to try things out in a quick and easy-to-amend manner, enables you to save time and prevent waste further down the line by designing for your audience right from the beginning.
By this point you’ll have a good idea of how your dashboard could work—you’ve got a record of where your users could find specific types of information and how they’d interact with the dashboard to reach the level of detail they need. Now you can build your prototype in your dashboarding tool. While you’re doing this, bear in mind the impact that visual design will have on how users interact with the dashboard. Position, size, contrast and grouping of elements on a screen all affect how a user sees the information. You’ll want to create a clear hierarchy to direct attention to a logical starting point to guide a user through the information. Remove anything that doesn’t have to be on screen—chart junk can easily add up to create a seemingly impenetrable view, and an overcrowded screen can be overwhelming on first view. Aesthetics aren’t just the icing on the cake, either—people are much more likely to want to use something they find appealing to look at, and they will be more willing to explore it in the first place.
Your dashboard should be shaping up nicely now.
Before you get too attached to it, test it out with a representative sample of users to see whether they understand things in the way that you intended. You won’t be able to see this for yourself by this point, so if you can’t get access to real users, find someone else to test it for you. Fresh eyes are vital to spot inconsistencies, make sure your choices align with what the users need, and understand what they expect from interactivity within a dashboard.
Do this by setting users tasks that align with the original requirements, and watch how they attempt to complete them. Ask them to think aloud while they’re doing these tests. They might naturally search for the answer in a place you didn’t expect, which could be a change you make to improve the speed at which users can learn how to use the dashboard when you roll it out more widely.
It’s unlikely you’ll get the dashboard exactly right first time, and that’s to be expected. By observing users through tests initially, and later being receptive to feedback, you can revise your dashboard to be an irreplaceable tool for the people who need it. It bears repeating, but time spent in these design development stages will ultimately reap value further down the line.
The world is full of poor design examples. Don’t let your dashboards be among them.