Working with #DataViz in 2021 — What’s Next? (and what matters?)
This is a fairly long read, and it’s a topic I’ve been thinking about for a few months. The changing workplace & paying more attention to data strategies which work, as well as those that don’t has been a key driver to writing this.
So grab a drink of your choice, and enjoy what you’ve no doubt done for so much of this year — scrolling.
2020 was the year I started to watch the West Wing properly. I’d dabbled with it when travelling & catching it on US Netflix, but never swerved into it. I really like the phrase, “What’s next” that’s used often. Jed Bartlett, when explaining what he means by it says “When I say ‘what’s next?’ I mean I’m ready to move on to the next thing.”
So what is next for #dataviz? What are we doing, why are we doing it & how can we do better?
Data visualisation has had a decade, and in fact it’s had a bit of a year.
Even personally, at the start of the decade I would say that my first inkling of ‘visualisation’ as a thing that wasn’t referring to basic Excel plots, but in fact was thinking about them as infographics. The visual representation of data to make information more engaging, if you will.
Fast forward a few years, through a series of accidents via blogging about Ipswich Town as part of the Football/Soccer Analytics area of Twitter, I started using Tableau. I read* Stephen Few, Alberto Cairo, Andy Kirk.. and through working as a Consulting Analyst, I built upon the principles of data visualisations. Data-ink ratio, why 3D is misleading, building for an audience… There are countless resources on this stuff.
*as an aside — I must confess never actually ‘read’ a data viz book. The closest I’ve come to reading cover-to-cover is Storytelling with Data by Cole Knaflic, and that’s because it nails the basics & concepts so well (and is, er, short). The rest I’ve skimmed/flicked through, though I do/have read Stephen Few’s blog (and comments, they’re always great)
And here we are, at the end of 2020 — and it’s been a year where I’ve thought & re-thought about the purpose of the work we do as data practitioners. What is the goal? What is the function of data visualisation? How can we make this better or easier and lower the barrier to entry further?
Looking back (skip this part if you don’t want to read about 2020)
2019, as Elijah Meeks alludes to in his blog, was A Year™ for data visualisation (https://medium.com/nightingale/2019-was-the-year-data-visualization-hit-the-mainstream-d97685856ec) I’ve loved & followed the work of Elijah Meeks (he’ll be mentioned a lot in this piece) & the Data Visualisation Society, alongside their excellent Nightingale blog.
Citing data years in review, a data viz president & a number of acquisitions, it seemed like data visualisation was about to have it’s moment. And it did! But not in the way we thought.
I made it over a few hundred words before mentioning COVID-19 — but it’s played such a huge part in the growth & usage of charts. Not only have we seen countless companies engage in digital transformation in terms of cloud — but so many of us have relied on great work done by data visualisation journalists, data providers and practitioners to enable the public to stay informed.
However, this has suddenly meant that so many people, not just folks with an inclination to look at charts — are reading, interpreting & sharing charts. Alongside this, unfortunate knock-on effects in the job market have meant that folks have also re-skilled or up-skilled in their data visualisation skills — adding to and improving the pool of talent within this sphere.
So I’d say data visualisation has had quite a year once again, with growth in viz literacy, data literacy and exposure of many folks to visualising data.
Who am I referring to?
At this point I’d like to clarify something — I’m very much talking about data visualisation as a concept for mostly corporate use. Data-art, data-fun etc. I’m counting as exempt from this — this is about fundamentals of using, growing and developing data visualisation as a thing within organisations toward a common goal.
We can of course return to the Few/McCandless argument — and as ever, there is no dichotomy… But we can allocate different roles based on how far aside on each spectrum each is. Again, standing on the shoulders of Elijah, I’m borrowing this image from his blog “If Data Visualisation is so hot, why are people leaving?” (https://medium.com/@Elijah_Meeks/why-people-leave-their-data-viz-jobs-be1a7ab5dddc) The rest of this blog will very much focus on those users to the left of this spectrum.
If design is what people come for, what will they stay for?
The field of data is large; you have front-end and back-end; you have engineers, architects and evangelists; you have designers, BI directors and artists. Good, clean, engaging design draws people in — but they return to a piece for something more.
Fundamentally, they/we are all aiming for the same goal — to reduce the time to insight.
I love this phrase, I use it so often. The fundamental goal for most/any/all data practitioners is to reduce the time to insight — especially in the world of work. In most fields, a dashboard or chart is accompanied by a thought. It either evidences, supports or allows for further context to what is either known or explained.
But what if we’re wrong? Or rather, what if we’re approaching this from the wrong angle?
This also feels like a great time to throw in a Twitter thread I saw earlier this year that set off fireworks in my brain.
Check out the full thread here: https://twitter.com/jmspool/status/1293015767038996480
There are *a lot* of arguments to be made with this.
- It depends!
- You can’t build a catch all solution but you can build something that helps most people!
- People have so many needs and I need to get this done!
The thought that this triggered was simple — what if the dashboard designer doesn’t know what to ask? Worse still, what if the users don’t know what to ask? Or perhaps most frighteningly, what if neither groups know why?
Does focussing, pushing & mandating data literacy help or hinder this process?
I’m going to use this as a cornerstone for a chat about data literacy.
Some companies of a range of sizes are taking the widespread levels of low data literacy head on — instigating company wide programs, training courses and workshops.
But —my gut instinct is that when peeling back the state of data literacy, these companies are finding that the wound runs deep.
This isn’t a problem that will be solved through company wide training programs or through dogmatic barriers — it’s something (like replacing typing pools with e-mail) which will either a) take time or b) be solved in a swoop by technology.
My personal view is the reason we exist in this state of data/viz literacy is largely down to the way the problem is approached. Some, most, data literacy programs or initiatives focus on upskilling colleagues and employees, looking to raise the bar. But I feel the core is deeper — it lies within critical thought.
Speaking to a few other friends within the data community, we agreed that critical thinking almost has to serve as a foundation of a good data analyst. Indeed, why constantly refer to the ‘citizen data analyst/scientist’ when the question on whether they want to be hasn’t been broached?
You’ll be hard pressed to find people who don’t agree on the value of data. But surely what they truly want is to reduce the time to insight — or in simpler terms, help to make my job easier. The body of people who have a vested interest (read, can make big gains through an investment in this space) have by and large done this, or at least started it.
As Elijah posts in his article “But we’re now seeing an acknowledgment that if you don’t have good data visualization then your insights are less apparent, resonate less with audiences and are harder to communicate among scientists.”
The rest of the workforce (arguably) aren’t that fussed. They get it, but ultimately the value add from investing hours, days to get good at something that has a marginal gain in what they do is tough.
The next wave of data & analytics will be context-driven ‘Just in Time’ insight
For me, the value will come from making data contextual. The thread from Jared Spool had one massive takeaway for me — that the point of delivery of information should be pre-empting ‘flow’. What is the ‘flow’ of questioning, how does what the user is trying to find out relate to what data can be supplemented — and how can this be delivered at the point of questioning.
Tools like Tableau are superb because with a trained hand (this is key), the user can explore data quickly, speedily and find a nugget of information — like Indiana Jones hunting for that killer artefact. But the end user of the dashboard created is driven by assumptions made by the dashboard designer. It adds a layer of complexity to the user to also be an amateur archaeologist to find what they need specifically at that point in time.
In a very loose, broad sweeping statement, I have a theory that data practitioners can face three sticking points — that they are:
- Questions rich, but time poor
That the practitioners have lots of questions, but because they are stretched for time to invest in finding the ‘perfect’ answer, they opt to only ask the high priority ones. - Data rich, but questions poor
That they have lots of data, lots of data tools, insightful dashboards at their fingertips, but no idea what to ask. This is a flaw of exploratory dashboards without training — owning a soldering iron is a useful tool, but if only a few people can operate it and get value, suddenly it can prove a poor expense. - Time & questions rich, but data poor
And if we focus simply on data availability and quality, there’s also a scenario where folks have lots of questions and time to speculate the possible — but suddenly the data says no.
And suddenly, the move toward AI, natural language and ‘simpler’ interfaces starts to make sense. But of course, these all depend heavily on understanding the context that a business operates in — understanding the boundaries, what metrics matter & how to aggregate or compare data points.
So — what’s next?
Solving some of this has roots in education, that if each key insights tool (key here meaning, most used by most people) has a tutorial or educational element to direct the user how to use (behavioural nudges are great for such a thing) this could help move the needle.
I also think the way that data & data visual literacy is taught should start, not with statistics but with design. Most users will build relatively basic analysis to begin with, so the starting point in my opinion should be to start with design — the reason? It’s a tangible output! A skill that is immediately applicable will help folks to come back for more. There is, as ever, a nugget from Cole Knaflic which can be shared here from her first blog post back in 2010 (https://www.storytellingwithdata.com/blog/2010/12/5-tips-for-communicating-effectively);
But perhaps for 2021, the trend will for designers to build more ‘throwaway’ dashboards (where the purpose is to answer a specific question in the context it is asked) and technology providers will continue down the ‘no code’ building blocks — but with almost a fresh thinking cap on… how can the point of delivery of insight be changed, and how can the ‘flow’ be used as a point for just-in-time education.
All about understanding the analytic flow
I wanted to finish on this concept of analytic flow.
When I talk about flow, I mean it in a sense of the sense of truth seeking.
And most importantly, referring to a majority of data practitioners — not the builders, or senior leaders, but the silent mass of folks accessing visualisations that are built for them. When this user goes toward a dashboard, or piece of analysis that’s being presented — they either follow the lead of the presenter or educator or they seek their own truth from interpreting the product.
Damien Newman’s Design Squiggle can help explain some of this. As designers, this process may seem normal. Trying to understand, building then delivering what we assume is a focussed piece of work.
But for a consumer, this process is remarkably similar — wondering how to use a tool, where to start and what exactly they’re looking for. This flow has to be shorter for a consumer, much shorter than what a designer sees.
This is where educating data practitioners about asking better questions, being inquisitive with critical thinking and supporting them with understanding the data they’re using is so important.
Going back to Jared Spool’s point — but what if the designer has misunderstood the angle? In a changing world, whilst metrics may be consistent, the angle of questioning and the relevant context may change. Think about a car dashboard, and the things that a driver would care about driving in a forest on a sunny day vs on a day where it’s sleeting, driving on a motorway? The conditions that we work in changes the importance and value of the context of the data we are using.
Understanding the thought process a user goes through when interrogating data visualisations, or how elements are used in a wider piece of analysis then allows for insights that are delivered at the point of requirement.
Does this assume a tacit knowledge of the metrics showed? Of course. And suddenly, the data literacy element steps away from generic concepts, but more toward understanding what a practitioner is using today. What does this metric mean? How are we measuring it or comparing it? This information is far more valid than learning about Anscombe’s quartet, or ordinal vs nominal data.
When flow is understood, then as data visualisation designers/engineers/evangelists, we are able to actually service what practitioners actually want to use.
The next generation of insights tools will be lead by the questions we ask — so we must wonder… are we asking the right questions?
I’d love to hear what you, dear Reader, think about these. What springs out? What would you add? Remove? Contest? I’d love for this to trigger a set of rich discussions which I would love to have in person!
Comment here, or join the conversation on LinkedIn or Twitter.
