This is part four of a series on dashboard visualization.
Today, I’m going to look at three important principles when it comes to visualization. In the next post, we will look at three additional principles. There are certainly more principles, but also there’s only so much time in a presentation, so go with me here…
Those principles that I want to cover are:
- Cognitive Load
- Less Is More
- Where The Eye Looks
Did you read Meagan Longoria’s post on cognitive load? Because you should do that. And the rest of her design concepts series. She covers it so well that I’m not even going to bother here; just read what she has.
Less Is More
Remove unnecessary items. This includes things like extraneous text, logos, indicators, and other things which do not advance your story.
Here’s an example of a dashboard:
My just-so story for this dashboard is as follows: we started out with a logo and title, and then put on a couple of graphs. Well, I wanted to explain what the donut chart and treemap are doing there, so I put in some explanatory text. But there’s so much stuff on here and I want people to look at the treemap first, so I put a bunch of arrows in to tell them to look there.
This is an absurd example, but too many dashboards end up looking sort of like this. Here’s stuff that we don’t need:
- The logo and company name. If this is an internal dashboard, your users already know where they work and don’t need the reminder. If it’s an external dashboard, there can be an argument for putting the logo or title in a tasteful place, but you don’t want it in the top-left. That’s okay for reports but this is a dashboard and the rules are different. For dashboards, we only get the single screen and can’t go on for page after page.
- I don’t need to put explanatory text on the dashboard itself. If users need help or more information, I’d rather that be in some separate help file somewhere. The reason is that this text is only helpful once, after which point it becomes a nuisance because it’s taking up space and not telling people anything interesting.
- Once I get rid of items, I can also get rid of the silly arrows.
After doing those simple changes, I have a much more concise dashboard:
From there, I can tighten it up a little bit more by removing the legend on the donut chart. Legends are pernicious things because they require people to move their eyes up and down and up and down. I go look and see that black represents 2016, and then go look and see that red represents 2017, and then I can go look and see that green is 2015 and…wait, what was black again? Yeah, on this example it’s a little silly, but if you have a chart whose legend includes a dozen or more items, people really do have to keep looking back and forth. Instead, include the data labels inline:
If you’re concerned that you have too many labels to fit on your visual, then you might have the wrong visual. This is particularly true if you’re using something like a pie chart or donut chart, about which I’ll rage some other day.
Reduce your color usage, and keep color usage limited and consistent. Here is an example of a bar chart with a lot of color. From this chart, you can see that Kentucky and Ohio are related, just like Indiana and New York.
I didn’t intend for there to be assumed relationships between these states, but when people see colors grouped together like this, they naturally assume that there is some relationship. It goes back to the cognitive load example above.
So if I don’t really mean to link states together with color, the best thing I can do is use a single color to represent each state:
At this point, I’m now telling the user that there are no co-state relationships of note. This also lets me do something nice. Let’s say that I want to single out the state of California:
Looking at this picture, you immediately see the different color without me even explaining what I was going to do. If I left it as-is, I could not have used color to draw your attention to California.
The third dimension is sometimes good for movies, but it’s almost never good for data visualizations. There are rare exceptions where a 3D image is better than its 2D equivalent, and those are usually in areas like geology and physics. For the world of business, you want to stick to the first and second dimensions. For example, this Excel maestro does absolutely nothing helpful for us:
It’s unnecessary 3D and actively harmful because it’s hard to read those values.
Where We Look
In European languages, we read from left to right and from top to bottom. In Middle Eastern languages like Hebrew and Arabic, we read from right to left and top to bottom. In ancient Asian languages (particularly Chinese), we read from top to bottom and right to left, but in modern Chinese, we read left to right and top to bottom. As far as Japanese goes, we read every which way because YOLO. The way we read biases the way we look at things.
There has been quite a bit of research done on looking at where we look on a screen or on a page. I’m going to describe a few layouts, but focusing on research done on Europeans. If you poll a group of Israeli or Saudi Arabian readers, flip the results.
The Gutenberg layout is a classic and indicates that we tend to scan our eyes from the top left down to the bottom right, focusing at those two points and glazing over the rest unless we see something particularly interesting.
The Z layout contrasts with the Gutenberg layout and indicates that people will start out interested and read across the top, and then scan back to the left and across the bottom, ending up in the terminal area.
About a decade ago, Jakob Nielsen came up with the F layout after additional design studies. The F layout is a testament to the interest level of readers: they start out interested and move their eyes left to right, but as they lose interest, they start sliding down the page, skimming through and waiting for something to catch their eye.
The trick with all three of these layouts is that they work for evenly distributed, text-heavy, homogeneous data like books or newspaper articles. Your dashboards shouldn’t look like books or newspaper articles, so I ascribe to a different type of layout style: focal points. The idea with focal points is that people will gravitate toward the most interesting-looking parts of your page and meander from one focal point to the next, sometimes catching the stuff in between.
When I say interesting-looking parts, there are a few attributes which work well for focal points. First of all is size: if a particular visual is a bit larger than its neighbors, people will naturally look at it first. Second, if you’ve followed the advice of limiting usage of color, a judicious splash of color on a visual can be a great attention-grabber. Third, gradient can matter too: maybe a bolded or darker-shaded title could grab attention, or possibly even a shading for the background. This starts to become riskier as you do it more often, and the question eventually becomes, how many focal points do you really have on this dashboard?
Nevertheless, judicious focal point layout can help us a lot in telling a coherent story with a dashboard. You have the beginning of the story be the first focal point, and critical sections of your visualization tale make up the remaining points. Exculpatory and explanatory visuals can cluster around the focal points. On a dashboard, I’d probably want no more than three or four focal points; more than that and you probably start to overwhelm the user.
In today’s post, we looked at three visual principles (including the one where I said Meagan can explain it better than me so just go read her stuff). Next time around, we’re going to look at a few more principles.