How user-centred design can help us communicate better with data
Written by Jon Geraghty, Head of Data Visualisation at dunnhumby
User experience meets data visualisation
Having worked in both User Experience (UX) Design and Data Analytics & Storytelling, it’s interesting to me just how inter-related those two disciplines are.
At dunnhumby we build data products — serving customer insights to retailers and food/grocery manufacturers — so it’s probably unsurprising that there would be overlap between UX and data visualisation here, but I believe that anyone who uses charts and graphs to communicate with data can be more effective when adopting a user-centred approach.
Reader = User
A key thing to remember is that data visualisation is a form of communication.
We communicate in many ways: verbally, written, through pictures, icons, even our body language and the clothes we wear are forms of communication. A chart we create is simply a way to encode data in pictures; fast-tracking to comprehension by harnessing the power of visual processing in the reader’s brain.
A key thing to remember is that data visualisation is a form of communication.
It takes two to communicate. I am creating the message but for communication to have successfully taken place you (the reader) need to be able to understand it. When I show you a chart, I want you to see evidence in the data and understand how it answers your question.
It doesn’t matter how beautifully designed our chart might be, if the reader struggles to get the meaning from it then we have failed to communicate. When we construct a visualisation we must remember to consider our audience; our ‘user’.
User-centred design
User-centred design (UCD) is a commonly used approach that grounds the design process in information about people who use the product. When we build, we keep in mind the goals of the people who will use it, not just what our stakeholders think is important.
Such a process might look something like this:
1. Context: It’s vital that if you are designing something that works for a user then you really need to know who they are and relevant context such as when and where they will be using it.
2. Requirements: What is the user trying to achieve? Knowing the user’s goals allows us to decide what features the product will contain and their priorities.
3. Design: What should we build and how will users interact with it? Explore multiple options at varying levels of fidelity from paper sketching right through to interactive prototypes and pixel perfect visual designs, where appropriate.
4. Evaluate: Ensure that our designs actually work by testing with real users.
Applying UCD in data visualisation
OK, so that’s how you’d be user-centred when building some sort of product or website, but what does that have to do with data visualisation?
Who is the reader? [Context]
Context for us is about knowing the role of the reader and their level of visual literacy, as well as identifying what mode they will be in when they are reading it: are they expecting the visualisation to explain something to them or will they carry out their own data exploration.
For example, the audience and context for a scientific paper is quite different to that of a fitness tracker, and you’d expect the complexity of your visualisations to reflect that.
At dunnhumby we generate a lot of insights for clients and it’s all too easy for a data scientist or analyst to compile something complex that makes sense to the creator, especially one who has had time to pore over and understand the data, but is that complexity suitable for a busy account manager who only has a few minutes to digest what they’re seeing? Inversely, someone looking to analyse a complex multi-dimensional problem won’t be impressed by a simple infographic that discards key data points.
What is the business question? [Requirements]
The user requirements when it comes to data visualisation are generally about answering a specific question; and getting the question right is fundamental, as Kaiser Fung of Junkcharts identifies in his handy trifecta checkup. In some cases, your reader may want to just play around with the data but if they are looking to take actions based on your evidence then you need to make sure the visuals and data support it. Answering the right question can switch your visualisation from the “so what?” to the “ah, now we should…”.
What does the chart look like? [Design]
Exploration of alternative visualisation designs is rarely done, formally at least, but can be a great addition to the toolkit, especially the sketching part. I often loosely scribble what a visualisation design might look like and try out variations before I fire up the digital tools. As part of a visualisation design workshop here at dunnhumby we run a group sketching exercise to re-design an existing visualisation and it’s amazing to see the creative exploration during an intense 10-minute sketching session and the great ideas that come out of it. Give it a try!
Is it comprehensible? [Evaluate]
Easy to overlook and logistically challenging, the evaluation step of a UCD process is arguably one of the most important. In data visualisation it may be overkill but we can certainly sense-check our chart with a peer (or even a random passer-by, guerrilla style) to check that it is comprehensible to someone other than ourselves.
Even if we only do this for a few of our charts it will help us to calibrate what other readers find easy to understand.
In summary
So, to summarise, there’s plenty of great inspiration we can take from the User-Centred Design process into our data visualisations.
We should start by knowing who the reader is and then design for our audience’s needs, answering the right questions. And we shouldn’t be afraid to sketch out and explore different visualisation designs, ideally testing with someone before we publish, to make sure the audience will be able to understand what we’re showing them.
