Visual Principles, Part 1

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:

1. Cognitive Load
2. Less Is More
3. Where The Eye Looks

Cognitive Load

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.

Decluttering

Here’s an example of a dashboard:

This dashboard has too much going on.

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:

It turns out you don’t need arrows to get people to look at a treemap.  Surprise!

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:

Moving data labels inline reduces the number of back-and-forth eye movements and keeps your users from getting dizzy…or at least upset with you.

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.

Decoloring

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.

Kentucky and Ohio are related, though!

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:

Now all of the states relate to Ohio.  Just as it should be.

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:

Picking out a bad apple from the lineup.

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.

De-3

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:

Sales in Q4 were in your face, at least if you move your face to the right side of your monitor.

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.

Conclusion

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.

Advertisement