Dashboards that shimmer 'n' shine

(CAUTION: The word “Journey” is used throughout this post)

What am I wittering on about today?

Design.  There was a time I didn’t even consider the design of a dashboard as something separate from the actual build/development. Didn’t think about it at all.   I got the requirements, heroically fought with the data sources and made a brilliant dashboard (in my opinion). I must be good at it, afterall, I built dashboards for a living.  Maybe not a lucrative living but it allowed me to buy life’s little luxuries like bread and shoes.

If design was considered at all it was usually after all the main components had been built.

With hindsight, I’d been guilty of focusing on the "grand finale" rather than the whole show.  Perhaps you have too!

When did I realise I was doing it wrong?

Well, not really “wrong” and it wasn’t exactly an epiphany.  But the more I was exposed to KPIs and dashboards and how they looked, the more I began to think about the design; how a user navigates (or is led) and how subtle feedback can improve their experience.  Even a good dashboard can crash and burn if the consumers don’t like its behaviour.

Nothing. I'm just a bit more aware of the overall “package” I, as a developer, can provide when building a product.

The most important thing is communication. Talking to the users to find out about how they perceive the challenges.  Draw up their “journey”; e.g. when seeking an answer, where do they start, what do they do, what’s their end point?  From this you can work out the flow of your dashboard and any bits of data plumbing required.

Even better - storyboard it. Create a user story that involves the issues they face. They might want to know the attrition rate in a specific department (end point) and need to traverse the rugged barren plains of  4 or 5 spreadsheets (starting point) just to get a parameter to pass into another system before exporting a dataset that they then dump into excel for more manipulation before they find their answers (journey).

Once everyone agrees on the initial “look” you can start to wire-frame it with the images/objects you might use in the final dashboard – this lets the users see something beginning to take shape based on their input. It’s also important since the objects/images you create for this can be used in the final product.  Regular meetings like this help build up a level of ownership with the users and improve the chances of your product being successful. Even better, if your doing regular demos with groups, they'll be familiar with how the dashboard looks and feels even before it's officially released. Sneaky eh?

Giving feedback TO the user.  This is a bit more subtle and refers to the visual cues that your dashboard provides.  A lot of the concepts for design are based around Gestalt principles - “The whole is other than the sum of the parts.” — Kurt Koffka.  You can find out more about it here:  https://www.smashingmagazine.com/2014/03/design-principles-visual-perception-and-the-principles-of-gestalt/

It’s an interesting read and you’ll definitely start to think more about design. 

Anyway…

Things like grouping, size, distance and colour are all techniques that impart information to the users.  Are certain functions/buttons grouped together?  Do similar dimensions/objects have the same colour or are the same size? 

Use of recognisable icons such as the disk icon (save), house (home) etc.  A user knows intuitively what these do without any further knowledge of how they work.  I click on the house icon and I’ll go back the main “home” page.  I click on the disk icon and it’ll save my work.  Many graphics are universal and can be used to help navigate around a dashboard.

Buttons

When clicking a button does the users see the button being “pressed”?  If so, that's a visual feedback for the user.  If not, the user may not be aware that the button has carried out it’s function and press it again leading to frustration. By simply showing the button as “pressed” the user knows their action has registered and will wait for the outcome.

Menu’s

Are menu items grouped accordingly?  Does the menu behave the same across all pages?  Is it always in the same place (Left or Top).

All of these little features help the users find answers quicker.

To summarise -  visual cues give information to the user indirectly and the user behaves accordingly.

So?

So, I went from simply putting together a dashboard where the attention was on the end result (show me my data!)  through to developing a more rounded solution; showing the data but using design principles for a better overall experience.  Thinking about the design throughout a project has meant I’ve created better more “rounded” dashboards.

So, next time you’re carefully throwing together your BI Reports, take a step back and think about how the users interacts with it and how you can help them along the way.  They’ll love you for it.  Maybe not love.  Maybe they’ll treat you with mild indifference, but it’ll be an improvement and you’ll get a warm glow knowing you did something that helps them find bad news faster.