The other day I realised something! It wasn’t a very innovative thought but it helped me to better contextualise what I (and most others who will read this) do. When talking about data visualisation, the first thought which comes to many peoples minds is “creating charts”; that’s – understandably – what many people associate with visualisation. Even as professionals we might explain to friends and family that this is what we are doing.
When thinking about it however, this hardly scratches the surface of what we are doing. I would assume most of us are aware of it. At the same time I would also assume that many – similarly to myself – struggle to accurately articulate why this is an actual profession. After all, everybody can create a few charts in their tool of choice…and everybody DOES! So what is it we are actually doing and why doesn’t “making pretty charts” cut it?
Visualisation is a Process
Saying Data Visualisation is about creating charts is similar to saying Journalism is about spelling words. Sure, technically that’s what they do but there is much more to it.
Visualisation is a process which starts with figuring out the reason something should be visualised in the first place, includes the understanding and possibly transformation of the data as well as the development of the actual visualisation and ends with the delivery of the finished product. These steps are not necessarily performed by just one person, however it is ideal if everybody involved understands all steps as much as possible in order to make sure that one step supports the next one.
This is why questions like “How can I improve this report?” and “My manager asked me to create a performance report, how should I visualise it?” cannot be answered with a simple “Just do X!”. These questions assume data visualisation is mostly a question of aesthetics, the business equivalent of “Should I wear the blue or the brown shoes with these pants?”.
Visualisation is Questioning
There are definitely quick fixes which can improve every visualisation (check your chart types, go easy on the colour, don’t truncate bars, etc.) however we will quickly end up in a situation where the “why?” becomes very important. I can recommend to remove all colours from the 10 bars, but maybe it makes sense to use colour for an additional attribute. Or some bars are of particular interest and they should be highlighted. Does it even make sense to use “Sales” here when all other charts display “Profit”? Or is “Sales” actually the important metric?
These questions quickly lead down a rabbit whole and I think more than once people who asked for a quick advise left with more questions than answers. Sometimes I think it might be me overthinking things and making them more complicated as they are. But then I want to make sure people understand that what I do is not just “making a chart pretty”. Learning basic visual best practise is not overly complicated. It’s my (our!) experience with data and the potential pitfalls that people get when they talk to me (us!).
Visualisation is Experience
When your colleague tells you that a third party requested a certain visualisation, it will be beneficial in all cases to talk to that third party directly, before starting any part of the work. Even if your colleague has a perfect understanding of the data, they will most likely not be aware of some limitations or caveats when it comes to the visualisation part of it. And let’s be honest, the colleague who asks you for help will in most cases only have a basic understanding of how data works and what it can and cannot do. That’s perfectly fine and usually not their job to know these things but this makes it incredibly important to determine the requirements for yourself and not get them second-hand.
The experience we bring is on the most simple level the knowledge that you shouldn’t use averages of averages (in most cases) and that dual axis charts are (nearly always) problematic. On a more advanced level it’s the ability to question the benefit of any given view of the data. Does it actually make sense to look at a monthly year on year comparison, when your business is not seasonal? Is the subset of the data actually a biased sample and why should you not extrapolate of those figures? Only once all these questions are answered, we can start visualising the data in a way that makes sense and is as useful as possible.
Visualisation is Investigation
In the end it’s very close to a business analysis role. Understand all the requirements, make sure they are defined properly and actually develop something which fulfils these requirements. The difference – I would say – is that it involves more investigation to define what it’s actually needed opposed to what somebody wants, it often also includes more development.
And this brings us back to the journalism analogy! A good journalist doesn’t just write down what somebody tells them. A good journalist questions what somebody says, they try to figure out “what actually happened” and they craft a piece of text around it. Everybody can write about an event but it requires a professional to do it in a way which is concise, informative and engaging.
Similarly a good Data Visualiser does not “just create a chart”! They figure out what is actually needed, investigate which factors are important for this and craft a chart around it. Everybody can visualise data but it requires a professional to do it in a way which is concise, informative and engaging!
Data Visualisation is not about creating charts. Charts are the visible part of the finished product, visualisation is the whole process which leads to that chart.
Thank you for making clear understanding for the beginners in this area and very helpful to explain to others whenever anyone says Data viz is just about creating charts.