Data Visualization Advice for UX Designers
By: Claudia Love
Tags: Design, Data Visualization, UX

Not too long ago, I was the lead UX designer on a project that involved some robust reporting features. The system would aggregate data from multiple sources to show teachers how they were performing compared to their colleagues in their building and in their school district.

I designed one of the report screens that listed all the indicators that the teachers were compared on. For each indicator, there was a chart. Since the charts were going to be generated dynamically with Highcharts and I was never great at math and analytics, I decided to leave them to the engineers. This is what they came up with:

I later learned that this is called a Box Plot chart

When I first saw it, I felt dumb — I had no idea of what was going on. Once the engineers broke it down for me, it made sense, yet I still found it to be overly complicated. “Can’t we just use a bar chart?”, I asked. They replied saying that this is the standard chart type for showing a position within a range. Being completely out of my depth, I shrugged and agreed to roll it out and show it to the client.

To my surprise, the client was as confused as I was. They asked if we could keep this version as an “advanced view”, but default to a simple… bar chart. Facepalm. So this was the final result:

The “Alternate View” flips the chart to show the first version (the box plot chart)

It seems pretty obvious now: our end users were school teachers. Unless they were math teachers, their ability to understand charts was probably not a lot better than mine. Which leads me to the first advice…

Know Your Audience (The Who)

This is one of the pillars of UX (we normally replace audience with users, but it’s the same thing) yet I failed to apply it because I doubted myself. Had our users been financial traders, the box plot chart would have worked perfectly fine with them, but that was not the case.

It might seem obvious but the first step is to always use research to understand who your users are and what their needs are.

Know Your Data (The What)

Mean? Median? Index? This threw me back to my high school math classes. Not a fan. Yet after my experience with the teachers application, I knew I had to step up my data viz game. Bill Shander does an amazing job explaining all of this on his Data Visualization Fundamentals course on Lynda.com

Basically, you need to understand what it is that you are trying to represent before you can make a decision on how to represent it.

Choose Wisely (The How)

Now that you have all the background information you need, it’s time to pick a type of chart to represent your data. And this is where us designers can become our own worst enemy. Because the sexiest, coolest-looking chart is not always the best chart. There, I said it.

Ask a designer to design a dashboard just for fun, without any regards for actual data. The result will probably be a beautiful combination of a line chart, a bar chart, a pie chart and/or a few donut charts, and maybe a couple of “big number” widgets as well. Most real-life dashboards, however, will end up being a set of bar charts and perhaps a line chart. And this is okay because the data should drive the type of chart we use and not the other way around.

Bar charts and line charts might be boring, but they are very effective. Pie charts and donut charts should be used with caution, because no matter how good they look, it turns out our brains are not great at comparing slices of a circle. (Tip: search for “pie charts bad” on Google and you’ll see what I’m talking about)

Sometimes the best way to go might be not using a chart at all and use a grid, a map, or a single number. It all comes down to what brings the most value to the end user, not what looks better.