Data visualisation: the value of design

Lessons learnt from designing and reviewing 700+ dashboards

Kamila Giedrojc
Societe Generale Design
7 min readAug 25, 2023

--

Before joining the team as a Product designer, I assumed that the bank had lots of beautiful dark themed dashboards filled with charts and lots of experts finding amazing insights from them. I even wondered what I could bring to the table as a designer.

Turns out, dashboards need to be designed too.

The reality is that there’s a lot of imperfect dashboards with data tables everywhere and a lot of acronyms users don’t understand. Three years and 700+ dashboards later, this is how I add value as a designer.

2 examples of dashboards
My daily life!

1. Focus

“Why are we only displaying three bits of data when we can just put everything (all 30 columns 😉) in one table?”

This is a common one: show me all the data. Why is this always the first instinct?

Dashboards tend to have too many tables. When teams want to display tables with lots of columns and rows they often give the arguments, “We want to give users an exhaustive view… Users may need all this data… Users can read the columns they are interested in”. In reality, it’s just a sign that an informed decision on what data users need has not been made. You might also hear the argument “Users are used to seeing tables, so we don’t want them to get lost with data visualisation instead.”

How to handle this: explain that finding insights in data visualisations is much faster than trying to scan a table. Even better, prepare an example with a table and a simple bar chart containing the same data, then compare how quickly conclusions can be drawn — here’s an example.

Table representation makes spotting patterns difficult.
A chart helps to spot trends and patterns faster.

So we should always replace our tables with nice visualisations? Not quite.

2. The right visualisation

First let’s talk about the abuse and misuse of charts. You’ve probably noticed that the most popular data visualisations are pie charts and donut charts. But they are often used for the wrong needs, providing the user incomplete, or misleading information — The risk here is that users will take incorrect decisions.

Use pie charts when users need to understand what the main categories (coverage) of given subject are. But if they need to compare categories, the pie chart will make their lives more complicated — comparing the size of category slices isn’t an easy job, especially if the difference is tiny. So use a bar chart to compare categories.

Comparison with pie chart. It’s difficult to know the difference between top two countries.
Comparison with bar chart makes the differences easy to spot.

What could make comparing categories even harder, but looks much more cool? Donut charts 🍩. With these good looking charts the comparison is even more difficult, as the coloured area is additionally reduced.

The common error we observe, is that teams take the raw data and just generate a chart/table from it. They expect users will calculate the difference between 2 periods on their own, or understand the trend from the table, or even calculate the average and mean on their own too. Make sure you simplify the analysis, so users read the chart at glance, and understand if the things are going well, or bad. It’s often a good idea, not only to display the row data, but also the trend and the ratio to provide context. If you can do storytelling with your data, that’s even better!

I won’t go through every single type of chart as there are plenty of solutions on the web that can guide you to select the right visualisation that fits your data and purpose. Here’s my shortlist:

- Visual vocabulary by Financial Times

- Datavizproject.com

- Data-to-viz.com

The key message here is to avoid using the best looking visualisations (looking at you Donut charts), and instead aiming for the best chart for the data that needs to be displayed.

Note that there is one case when using table could be an advantage over a chart: referring to Stephen Few tables make it easier to look up individual values.

3. The right level of complexity

Now that you’re looking at all these amazing visualisation types, it’s time for a “Data literacy disclaimer”: even if an uncommon data visualisation shows the information in an ideal way, many users may not adopt it as they will take too much time learning this unfamiliar visualisation.

Propose less common visualisations if you know that users will have the time to comprehend them and be able to use them regularly (so they don’t forget how it works). You can learn more about the right level of design complexity in our article about UX Efficient Frontier.

We could assume that in the finance sector we’d be more open to use elaborate charts such as bubble charts or Sankey diagrams, but… we’re not. Most of the time we use simple tables, bar / pie / line charts, or heat-maps.

Depending on the need, you can create data visualisations that are more exploratory or more informative. We do have both in the bank, but most of them answer the need of status monitoring. In that case it is particularly important to get the main insights quickly, without forcing users to do a complex analysis in their head to take an action.

To answer this need, the most standard charts will often be good enough. However even with simple charts or tables, it’s sometimes very complicated to get the main insight.

4. Actionable Dashboards

Actionable charts and dashboard are particularly important when supporting decision making. I’ve seen dozens of charts present data that just did not help to take any decision, or informed action.

If you think your chart isn’t actionable then challenge the chart with the “so what?” test. Even better, follow this method from Nick Desbarats — the idea is to ask the dashboard user the question:

“Can you name at least 1 specific action, that you personally would take back on this measure? Would you do something if these measures get extreme values?”

If the answer is “no”, then you probable don’t want to include it, at least in a status monitoring dashboard.

5. More Focus (Condensing information)

Does this kind of chart look familiar?

I’ve seen column charts like this one with 10–20 MORE columns…

I’m talking about dashboards and data visualisation that just show too much information.

This is often caused by not deciding what information is actually important, and instead forcing this responsibility upon users, who won’t appreciate the lack of focused data. Don’t be afraid to make choices and learn quickly from bad choices, too.

Display top categories and group minor categories in single category “Other”.

Another common error is the creation of “THE one chart” with all information possibly displayed in it. That often makes the chart very complex to read for users. In that case, you can apply the KISS (keep it simple stupid) principle, and encourage communicating one message per chart.

So now that you’ve chosen the right visualisation with the right level of focus and complexity — what else is there to do?! Well, a good chart can be ruined by poor annotations.

6. The right amount of annotation

Annotation mistakes are usually either far too many annotations, or not adding any at all. How often do you see a chart where the currency is not mentioned? Or maybe a time period for the presented data is missing? Or worse, abbreviations that are not explained.

Ambiguous chart title example: is it about the value of all orders, the number of orders, or an average value of orders? Who knows?

For a good balance of annotations, make sure you know who the users are and test it with them. It’s all too easy to assume that others know as much as we do, and that everyone will understand charts the same way that we do.

Bonus: 7. Visual consistency

We often use external tools or libraries for data visualisation. This is a big time saver, but they never align with the rest of our Design Styles. So when using external libraries there is a risk that the charts in your service will be a bit inconsistent.

To fight this at Societe Generale CIB we’ve created templates on top of an external library, which has now prevented lots of back-and-forth discussions on the consistency, but it’s still a struggle to ensure that teams respect fonts, colours, and text formatting (dates, time, amounts) when using custom visualisations.

If your Design System covers accessibility in data visualisation, using the design system will help users with disabilities access the charts content. If you’re being challenged on the importance of chart accessibility, you can just ask around your office how many people have some type of visual impairment. If, for instance, people can’t differentiate green from red, it’s going to be tricky if your PO expects heat-maps or KPIs to be green and red.

Note*: Accessible charts is a big topic on its own, so I hope to cover it in details in another article.

Well, that’s it. Now you know it all (?)

In many companies, most dashboards are created to enable decision taking. And as such they should be easy, quick to understand, relevant and actionable. I hope that by using some of the tips described in this article, you will enable users to take decisions faster and with more confidence.

Thanks for reading! Don’t hesitate to drop a comment and share your feedback. Et voilà!

--

--