We see data visualizations everywhere: in the newspaper, online, in your payments dashboard and so on, but how often do you think about whether or not the graph you’re seeing helps you understand what’s going on behind the scenes? More often than not, visualizations can make data confusing — or misleading — when what we really need is a clear insight of data.

Data visualization is challenging to get right because while it’s easy to make a graph look beautiful, it’s much more difficult to do the numbers justice in a way that everyone can understand.

At Adyen, we’ve been thinking about the role of graphs a lot, and how we can use them to best help our users get more out of our product, rather than get in the way. Here’s how we’re thinking about visual storytelling with data visualization, and what we’ve been working on.

The impact of data visualization

To see why data is so powerful, let’s jump back to 1986; the Challenger space shuttle disaster saw seven crew members killed when malfunctioning O-rings caused the rocket boosters to combust. Could this have been foreseen?

Edward Tufte argues in his book Visual Explanations that the engineers actually knew of the dangers and failed to communicate them in a way that was digestible for those making the decisions. Those engineers had tested the O-rings and knew the critical factor was temperature at time of the launch, but when communicating this crucial information they presented it like this:

Image result for challenger visualization 🚀

A cursory look at this graph showing previous launches and damage to O-rings would tell you… very little. It’s difficult to come to an actual conclusion in this format, but the issue was hiding in plain sight.

The data showed a correlation between lower ambient temperatures and increased damage on the O-rings, but the visualization didn’t communicate that effectively.

On the fateful launch day the ambient temperature hovered around 36 degrees; this is indicated on the graph to be a much higher risk of danger but potentially miscommunicated by the format. This alone shouldn’t be assumed to be the cause of the disaster, but instead was one of many factors that might have contributed to a misunderstanding of the risks involved. Below you can see Edward Tufte’s improved visualization:

Edward Tufte’s visualization of the O-ring damage

How we think about data visualization

Fortunately, we’re not responsible for something as difficult and dangerous as launching a rocket. However, we approach data visualization at Adyen with great care and only use it in a way that actually helps our users get real insights, rather than just adding something pretty to a dashboard or showing numbers without context.

The first simple rule to follow: don’t use pie charts, because they often make it harder for a user to compare data than a bar chart would.

Pie charts are worse in practice because comparing area is incredibly hard for humans to do, while comparing length is far easier. Presenting the same information both ways, then asking your users will result in them almost always preferring the bar chart, because they don’t need to look at it for more than a second to understand it.

We’ve found that the best way to understand how people compare data and come to conclusions is to ask real users how they interpret the way information is presented by mocking it up in different ways or scenarios. If you actually ask people, the results can be surprising; even a simple exercise such as comparing the length of two bars may also not always provide the conclusion you’re hoping for.

The problem with most visualizations is that the user needs to work harder to understand the graph itself, rather than the insights you’re trying to give them. With that in mind, if you would look at many of your own visualizations you can probably find ways to improve them immediately.

Take this simple, made-up example of the popularity of data visualization gurus. Presented without the trendline it’s difficult to come to a conclusion about their popularity, or what any of this information relates to; there is no insight. But if we add a single sparkline per guru, we’re able to communicate more information which shows Jon Snow has seen a massive uptick in popularity lately:

Sometimes it’s actually better to present the data as a table instead of a graph if you’re showing lots of precise individual values or directly comparing a number, rather than showing overall trends. Try to create insights through the use of other elements, like sparklines or bulletcharts.

A direct example of this comes from our own dashboard, where we used a speedometer to show the user how much money was authorized on their account in the last 24 hours. A cursory glance at this tells the user everything is excellent — it’s green after all — but if you look at it hard enough it gets less clear.

Breaking it down, the lower right is the previous 24-hour period of authorizations, and the number below must be the dollar amount, right? As it turned out, that bottom number is actually just the number of transactions which have been authorized today, rather than the dollar amount — but users consistently assumed otherwise.

By showing this on the dashboard, we made the user work to understand whether or not this was a good thing, which meant that the visualization had failed to do the job it was supposed to do: provide a quick, correct conclusion even if the user is new. To approach this problem, we studied ways to improve communication of the same information to make it much more useful and self-explanatory. What we wanted to communicate in the first place was whether or not the majority of transactions were successful along with the reasons why they might be failing — all of which the old charts weren’t very effective at.

By switching to a stacked area chart, we realized we could communicate much more about the success rate in a similar amount of space. The user could understand why they might have seen a spike in failures at a particular hour of the day, and we provide a route for them to explore further by either expanding the chart or hovering over it to see more data.

By adding this information, we were able to make our visualizations self-explanatory so that the user doesn’t need to work to understand what’s going on, as well as providing the option to explore further without them needing to go elsewhere.

Combining a table, sparklines, and a graph as we did here immediately helps anyone understand at a glance that something might be wrong, then offer a way to pinpoint the trend to a specific time and cause without needing to investigate more in-depth.

We also specifically removed the green color, which could have otherwise taught the user to interpret the data in a specific way — our previous graph used green regardless of state, which may make them think that everything is fine even if half of their transactions were failing!

Color has a lot of power, but more often than not the graph can work just as well without it, which makes it more accessible to others as well, such as those who might be red-green color blind. By removing it, you can invite a broader, more inclusive group of users to benefit from your data.

Our data visualization finally did the job we wanted, rather than just look pretty.

Choose your data wisely

Last but not least, make sure your data integrity backs the way you’re presenting it and that you know what you’re trying to make it do. One of my favorite pastimes is finding ‘lie charts’ or ‘junk charts’ which are charts that either intentionally (or unintentionally) make the reader reach the wrong conclusion.

It’s possible to find hundreds of examples of visualizations like this that communicate the wrong information. The power of data visualization is that you can make a chart say anything you want if formatted carefully, leading people to the wrong conclusion through simple manipulation of basic elements.

As designers we are responsible for checking whether or not information is presented in a way that isn’t misleading, pushing the user to the wrong answer — or worst of all, completely misrepresenting the reality of the situation. Not only is creating misleading charts unfair on the end-user who’s trying to use our products, it may impact the way they go about the day. You will also look silly when the totals don’t add up, or the chart is total nonsense, so make sure your assumptions about how it’s interpreted are validated.

When creating your own visualization, always begin by understanding what it is that you want to communicate, and if it’s only there to fill a blank space, it may be worth considering why you’re using one at all. If we make people work harder to reach a conclusion, or are just sprinkling charts on to make things look pretty, we’ve failed at our jobs — because ultimately they should get out of the way and help the user get more done.

Edward Tufte, American statistician and professor at Yale once said “Instead of design variation, show data variation” and it’s an important rule to follow. Help your users understand trends without needing to understand the graph first. Keep visualizations close to the chest as a powerful tool for drawing attention to outliers when really needed — but wield them with caution.