Day 1 in the Desert — Designing for Data

I’m here in Phoenix, Arizona for the User Experience Professionals Association (UXPA) conference, where for the next four days I’ll be highlighting my experiences and top learnings in the field of design as it relates to UI, UX, and future technologies like voice, AI, and more.

The conference kicked off with an intensive workshop day, where I was immersed in two 4-hour long workshops. I chose to attend a workshop on Visualizing Data in the morning and Effective Design Reviews in the afternoon. I’ll highlight some of my main takeaways below just from the Visualizing Data workshop.

Visualizing Data for Presentations, Dashboards, and UIs

TL;DR

• For visualizing data, think about what you are trying to visually communicate to the user. What decisions do they need to make with the visualization they are seeing and interacting with?
• (Almost) Never use pie or donut charts
• Don’t try to show too much in one graph/visualization — Just because you can technically do it, doesn’t mean that you should.
• The best resource to get started with: Information Dashboard Design by Stephen Few

In this session led by Thomas Watkins, he led us through the redesign of 9 examples of poorly done visualizations. When I say “poorly done,” I mean visualizations that failed to communicate the information to the reader in a useful and usable way. The reason that we use visualizations is to allow a user too quickly and easily make a decision without requiring them to do any work.

One of the first examples we went through was visualizing asset allocations for an investment portfolio. You’ve probably seen this before if you’ve ever used an online financial advisor or robo-advisor.

An example of a typical asset allocation that you see which is visualized using pie charts. This is problematic for a few reasons.

Thomas highlighted that pie charts are grossly overused when people want to show “parts of whole” visualizations. Why are they problematic?

1. They don’t scale well
   As we add more and more slices of the pie, it’s hard to figure out how much of the pie each slice takes up.
2. We aren’t good at reading slope and area
   As humans, we aren’t good at quickly gauging and understanding slope and area. If I show you a ping pong ball compared to a basketball, you’re not able to accurately or quickly figure out the size difference between the two or how many times larger a basketball is than a ping pong ball. Answer: Roughly 200 times larger.
3. They require excessive mapping and labeling
   Take a look at the pie charts above. In order to understand what each one is trying to communicate you must constantly look at the values below it. Often, the designers of the pie chart will label each slice to try to prevent this but then this gets hard to read as the slices become smaller.

What’s a better way to visualize this? One way is via a histogram, which is used to show distribution.

Our eyes are better at judging and comparing lines as opposed to areas. For instance, without even the labels, we can see that the dark blue for Non-target date balanced funds is a bit more than double the length of bond funds.

Let’s take a look at one more example, this time from yesterday’s workshop. Here we see a chart that maps out responses to five questions in a customer service survey.

What are some of the main problems with this graph? (Besides for the spelling of “Survey”….)

• The goal for the user is likely to quickly understand the distribution of each response. For instance, they may want to quickly see if they are getting more customers who feel that yes, the service representatives are well trained. Using this stacked bar chart, it’s hard to tell what this distribution really is.
• The use of color here is off. A monohue (using one color, in this case various shades of blue) is indicating that the chart is going from less to more when in actuality each section of the graph are distinct values. This is common to see in modern visualizations because monohue charts are visually appealing, but in this case it is not appropriate.

And here is a sample solution:

Why is this solution better than the original?

Now, the user can quickly see the distribution for each response, understanding that on a whole, most customers are in the neutral to positive category for how they feel the company in regards to customer service. Also, the use of colors now make sense. The graph is mapping a very negative response (“Strongly disagree”) to a saturated red color and on the opposite end mapping a very positive response (“Strongly agree”) to a deep blue color. All other values fall in between, with a neutral response being shown as a grey bar, which makes intuitive sense.

Of course, being that the workshop was only four hours, we were only able to cover a tip of the iceberg as it pertains to data visualization. If your appetite is now whetted and you want to dive a bit deeper here are the three resources that Thomas most recommended:

• Information Dashboard Design by Stephen Few
• Show me the Numbers: Designing Tables and Graphs to Enlighten by Stephen Few
• The Visual Display of Quantitative Information by Edward Tufte

Do you have data visualization resources (books, blogs, articles, etc) that you love? If so, please share in the comments.

Thanks for reading — Now off to Day 2 for me!