I’ve written before about dashboard and how they’re typically awful even when the design seems nice and modern. The problem is known as ‘the portal problem’ and it’s been well documented – see this article on boxes and arrows.
Here’s an example of a dashboard that looks great, but that may or may not function well. Since it’s a template for generic business X, my guess would be that this will not function well when it’s implemented.
The problem is that dashboards are typically built for a general user that ends up serving 10-20% of everyone’s needs, and no one’s needs fully. Dashboards are typically built as if all users had the same needs when the reality is much, much different. Even users with similar needs end up wanting to view it and consume the information in a way that suits their particular style – and why shouldn’t they? The promise of technology isn’t that it’s a one-size fits-all solution that will frustrate 80% of the needs of users – it’s that it’s malleable and useful for the user – who happens to be a human. Humans process information in all sorts of different ways, and dashboards have to account for this if they’re going to be more than an update of the skeuomorphism of the vehicle-dashboard metaphor that was popular in the 90s and 2000s. The problem of course is that they rarely do and so in my opinion end up failing in most cases to deliver an optimal experience – or even a minimally useful experience.
I found an incredible article proposing a better way to design a dashboard. Unfortunately it’s long and filled with in-jargon that makes it difficult to understand (I had to read it twice to figure out what was being said, never a good sign).
To that end I’ll be linking to the article(s) and attempting to reduce 6 overly-long articles in one concise statement about building a better dashboard.
Make the views user-configurable
This has two aspects – first, allow the users to hide or show larger blocks of content. Do they want to see a KPI or don’t they? Second, allow them to configure existing blocks of information. If they want to see the KPI, then over what time period do they want to see it? What kind of chart would they like to view it as? Etc. We all process information differently and we shouldn’t assume that one view of data will work for everyone. Let the user customize and save their settings.
Let it be emailed, printed, etc
Sharing capabilities extends the usefulness of metrics. If we’re saying that a view of data is important enough to see everytime you log in (as in a dashboard view) then why not be able to save, email, and share that metric easily? Not everyone knows how to take a screenshot (seriously) so make it easy on people – a share functionality could also include attaching an excel spreadsheet with the information contained in the chart, graph etc.
Give the user context around the info being presented
How do users know if the numbers being shown are real and relevant? They might trust the numbers, but they might need to know more in order to make a decision. So give them the tools to investigate the data and let them deep-dive to help them feel confidence in what they’re being shown.
Let the user’s input be a signal about usefulness (and pivot based on that information)
Let users make notes on information. This could be one signal about it’s usefulness, and may or may not be useful to other users. Build in logic to recognize the frequency of an information block being consistently hidden or shown – this will be a signal about the usefulness of a given block. Basically treat the user as the end-all of product usefulness. If they aren’t using something often, then re-consider the value your organization is putting on maintaining that chart, graph or block of information.
How users consume data should inform the role/look/content of the dashboard
Typically dashboards are build on data that users want access to. There’s two ways to get at this kind of information – in the mockups phase, you can do card categorization tests with potential users and customers, to help you find out what kinds of data they feel is useful. Once the product is built, you can actually track their consumption of the data and verify that what they want (where they end up in the system) is actually what you’re delivering them in the dashboard.