This article is initially available on our podcast. Click here to listen.
Here are a couple of quick things concerning dashboard best practices. We’ve done some other podcasts about what dashboards are and what their purpose is. I want to reiterate that a dashboard is not a complete reporting solution. A dashboard might be a component of a reporting solution or a business intelligence solution, or a comprehensive analytics package. But a dashboard is essentially one small amount of information that you can access quickly and easily, like the dashboard of a car, to get a few pieces of information to tell you overall what’s happening. It’s not all reports.
Let’s discuss best practices
A couple of things in terms of best practices. One is, make sure that you have the appropriate level of detail. By that, we mean suitable for the individual who is using that in particular. That means that if you have a frontline user, or if you have a manager, or if you have an executive or an owner of a business, those are all different types of individuals who might want to have other things provided to them.
So you need to have an appropriate level of information and a proper level of detail for that individual. That means their role (not just their title, but their role in the organization) and even that individual. Some people want more detail, and some are more drivers and want quick, easy, concise things. So make sure that that’s geared towards the individual user.
Focus on the end-user
Ask them what they want. That’s always a great approach. But start from the concept that different users and different roles within the organization will have different needs, particularly on how many reports are going to be in that dashboard, what level of detail, and so on.
The same thing for visualizations for each user. Each user may have different wants or needs. Some people like pie charts. I think pie charts are a disaster, but there may be an individual out there who likes pie charts. So, again, you want to make sure that it’s appropriate for that individual user.
Less is more
The other huge one, which ties back to the first thing that I started saying about what a dashboard is, is less is more. What happens typically over time is you have an organization, an individual, or a department, whatever it might be, who has a certain number of reports where. You may start off designing a dashboard and saying, “Hey, what are the key things that we want to communicate?” Then, over the course, especially of time, it starts to grow and grow and grow.
Even if you don’t run in that situation, it’s not uncommon for people to try to throw everything into a dashboard because they want to make sure that you’ve got everything. That’s a typical approach. Yet, we want to meet people’s needs. Also, we want to solve problems. We want to make sure that something is complete.
Often, that destroys the concept and the benefit of a dashboard. If you’re trying to get everything in there, it’s not a dashboard anymore. That’s like a massive amount of reports. In addition, somebody’s going to be filtering through and weeding through and paging through it all. For what? To find what they want. That’s not helpful anymore.
Clear out your dashboard
Going back to that concept of growth over time or scope creep effectively, from a software program standpoint, when you have an individual who starts with a certain number of reports, they may see somebody else who has a different program, “Oh, that’s helpful! I’d love to have that.” Or there might be something that they’re running regularly now and saying, “Oh, I want to have that. Put that in my dashboard!” Or it may be that, again, there are particular initiatives for the organization, “This quarter’s initiatives require us to look at this kind of information. Next quarter or next year requires us to look at different types of reports.” But the old stuff doesn’t get cleared out.
There isn’t sort of a zero-based accounting for the dashboard, where you start from scratch each time and say, “Okay, what are the basic things that we need to see and only those things?” And so, it starts to build up like clutter over time. That means that the dashboard no longer conveys just crucial information quickly. You’ve destroyed the value of a dashboard.
I can’t tell you how many times we’ve heard somebody say, “I don’t have time to look at all this.” If you ever hear that, you know it’s a complete failure. You should throw it out and start from scratch. It shouldn’t even be, “How do we remove or how do we cut?” Just eliminate it. Start from scratch and say, “What are the couple of basic things you need to know fast?”
And that’s what goes on the dashboard. Everything else should be buried somewhere else. I don’t mean buried like it’s inaccessible or it’s hard to find, but I mean, it’s not in the dashboard. It’s on a separate tab that has all kinds of detailed information.
On the other hand, it’s in a series of additional tabs or a repository. However, it depends on how their strings are structured. It can be organized in a lot of different ways. But it’s not that quick and easy visual information on the dashboard. Bang, bang, bang. If it’s become cluttered or busy or built up over time to be too much, literally kill it and start over.