It turns out (okay, so this was no surprise to me) that what goes into a dashboard matters. And to make it clear, I’m talking about Business or Management Information dashboards, not vehicular ones, although no doubt the same general rule applies. In point of fact, a disproportionate number of dashboard software suppliers seem unable to tell the difference and I’ve seen far too many examples of these using automotive style dials trying to provide information about sales figures – and failing miserably. Now, they may be pretty, and that’s a moot point, but they’re generally not informative or, at best, not enough to make them worth the time to read them. Which seems a real shame considering just how much money goes into buying these tools, learning to use them, creating the dashboard and finally realising that it makes no sense at all of what you really need to know.
Of course there are many blogs on this very subject, one of my favourites being that of Jorge Camoes, which I have been following for a few years now and those of Stephen Few and Alex Kerin, which I dip into on occasion (okay, I admit it, they’re both in my RSS feed list). Now, I don’t always agree with them but, often, they do make a lot of sense. So, my advice if you are looking at creating a dashboard? See below…
- fall in love with your creation, and refuse to accept that it may not be perfect;
- decide that your dashboard is just what everyone needs, then spend weeks/months creating it without doing a little research first;
- throw in the towel when you realise that no-one else wants what you’ve provided or appreciates your vision.
- talk to the right people – the end-users;
- ask the right questions once you’ve found said right people;
- find out how they currently look at the data, what they like, what they don’t;
- share your ideas of how it should be like and allow for open discussion;
- be prepared to show how use of the dashboard can improve current performance;
- make a draft, actively seek feedback, accept some and stand your ground on others, provided they’re defensible;
- learn to tell the difference between what users say they need and what they actually need;
- help them to see the difference, diplomatically;
- be prepared to take what already exists and improve upon it;
- deliver what’s needed, and make sure it works;
- remember: if it’s great, that’s great; if it’s a hideous mistake, it’s your fault – so only build what you’re prepared and able to defend
That’s pretty much it. As an example of before/after I’ve taken a couple of screenshots.
This is part of the original (the whole doesn’t fit on a single screen), all of it driven by filters, with a requirement to scroll both across (26 columns, 9 hidden) and down (100 rows) the page to be able to get to some of the required data:
This is my quick-tweak version, bringing everything into one page, incomplete but showing what is possible in a single, n0n-scrolling page:
That’s pretty much how it works, all the relevant data, all accessible in a single screen, nothing to distract from what is pertinent.