I like revisiting old books and resources I relied on in the past. It is always interesting because it helps me see how far I’ve come in my own personal journey working with dataviz. Back when I got my first job, I barely knew what a spreadsheet was. I could say that a big part of my career evolved and was shaped alongside BI technology. First, it was Excel, then it was Tableau, then it was Power BI - but one thread was always the same - regardless of which tool I’m using, my primary concern has always been with communicating complex subjects to others. Mostly visually but also through text here and there (like I do with these reviews).
So, while, in part, the nature of my work has always been about visualising data, the ways how I get this done have changed over time. And whether or not I like to admit it, the technology I learned during this time has shaped how I think about such subjects. Every new tool I learn makes me rethink the things I assumed to be true with the tools I used prior. The truth is, the evolution of my work, and the perceptions and definitions I hold about data and how to best visualise it were, in one way or another, shaped by a mix of the environments I work in, the technologies I learn and use, what other practitioners have done before me, and my own attempts and mistakes.
This evolution is a slow, gradual process. It is constant, but we barely feel it. We often take it for granted. This is also why we’re sometimes taken aback when faced with a novel chart type and “don’t get it” right away. But we sometimes forget that data has not always been communicated visually, and even when it has, it could have been in ways we may find challenging for our modern perception too.
I’m bringing this up because I revisited another one of Stephen Few’s classics this week. Information Dashboard Design, originally published in 2006, with a second edition in 2013. This review is based on the second edition.
I wrote about Few’s views on data visualisation before when I reviewed Show Me The Numbers. This review will share a lot of similarities.
What is a dashboard?
Ahh, this question. I brought it up in a recent newsletter issue as well. I’ll revisit a bit of it here.
There are two current definitions that most people who either build or use dashboards rely on.
The first one comes from Information Dashboard Design (the subject of today’s review), in which Stephen Few postulates:
“A visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance”.
While The Big Book of Dashboards (Wexler, Cotgreave and Shaffer - review coming soon) offers a wider definition, which says:
“A dashboard is a visual display of data used to monitor conditions and/or facilitate understanding.”
But if you look into other sources, you’ll likely find multiple definitions, which will likely overlap with these ones to some extent.
Nick Desbarats has an outstanding presentation from Tableau Conference 2019 in which he names 13 different types of information displays we often call dashboards. And I dare say this is likely not an exhaustive list.
The way I currently see all of these dashboard definitions in my mind goes somewhat like this:
In practice, I am often more concerned with creating a common language within the group with which I’m developing a dashboard - however they may choose to define it, as long as it’s a shared and consistent meaning. While it is important to have a clear definition, it can’t be so narrow that it makes using the term a chore, nor can it be so wide that it doesn’t really define anything. How narrow or how wide really depends on where the group assigning the meaning to the term is coming from (their context). So, whenever I am asked to develop a dashboard, I like to understand where the request is coming from, why they’re using this term and what they think this term means within their own context. It may differ slightly from job to job, but that’s ok by me. Language, as much as dataviz, is an ever-evolving thing.
I think this is worth clarifying because of the unnecessary noise that such discussions sometimes cause, which may have the unintended consequence of steering away alternative views and voices from engaging with the community. So, while I do include Stephen Few’s very strict definition of a dashboard in my lexicon, I do so alongside multiple others - because there’s no such thing as a common and unified canon of dataviz.
What isn’t a dashboard?
If I had to choose a central theme for Information Dashboard Design, it wouldn’t be so much the design principles discussed within it as it would be its preoccupation with defending its own definition of a dashboard. Every chapter is sprinkled with examples of non-dashboards and why the author wouldn’t call them as such. While there are useful concepts about layout, design and visual perception, every chapter mentions at least once a handful of examples that do not conform to his definition of a dashboard. I find it rather amusing, actually. It is a long book (there’s a lot to be said about dashboards), but the semantics discussion takes the central stage.
The tone across the book also seems to be one of profound bitterness and resentment with tools, vendors and developers who dare venture into experimenting with broader concepts of what a dashboard can be or do. While the author certainly made an effort to find truly dreadful examples of information displays, the negative focus takes away from its own message in a lot of ways. While in this very book, we can read Few arguing that poor design happens because most people aren’t exposed enough to really good and functional examples, he proceeds to spend a lot of pages exposing the reader to even more terrible examples.
The first time I read this book (circa 2016, when I first realised I had to make sense of this thing called dashboard), a lot of the book resonated with me. I took multiple lessons from it to heart and applied them dearly to much of my work. But upon revisiting it today - after I have done this for a while, seeing what has worked or not in different environments, with different people, for different purposes, with different tools - I notice its age. I also notice that while it is informative in many ways, the manner the information is often conveyed makes me uncomfortable.
I have never met Stephen Few nor seen much of his own blogging until recently, so what I have to go from is the impression I get from his books. And the impression I get is that of someone incredibly passionate about his field but at a stage where he felt deeply uncomfortable with the effects that new technologies and approaches were bringing to the field. More people were using more tools that allowed them to create more visualisations at a record pace - and like with any intense period of sudden innovation, most of the initial output will be experimental (and sometimes a bit rubbish). That’s always a given. It’s like when digital cinema came up, and people were concerned that it wouldn’t be “true cinema”, or when electric guitars were invented and considered “too loud and just noisy, not real music”. The AI debacle is our newest instalment of this same phenomenon.
Back in 2006, when Information Dashboard Design first came out (and I believe still in 2013 with the second edition), data was not yet “big” as it is now. We also didn’t have a proliferation of tools and vendors that allowed more people to access and work with more data, more quickly. We have become digital natives. We became mobile first. We got used to scrolling as a quasi-natural gesture to consume information. We have social media. The world has changed dramatically, and so have the ways we think of and interact with the data we collect. Very few written pieces that try to define an object that is so reliant on context and technology as dashboard is would still be fully relevant today. Such is the nature of what we do.
The good bits
Having said all that, there are incredibly insightful bits inside Information Dashboard Design that are still relevant today, and we should give credit where credit is due. A lot of what we build today relies on what came before, and this is a foundational book that informed most of the current literature about dashboards. That’s what makes it a classic.
In Chapter 2, Stephen Few defined thirteen design problems that are frequently found in dashboards - and most of these still apply to dashboards today, regardless of tool.
Here are my five favourite ones that I still rely on to inform design decisions today:
Choosing ineffective measures: Dashboards - regardless of which definition we decide to go with - display metrics. If those metrics aren’t clear and fit for purpose, though, the dashboard itself won’t fulfil its intent.
Supplying inadequate context for the data: Without context, it's challenging to understand if a number is good or bad, improving or worsening. Even if your display of data isn't strictly concerned with performance tracking, metrics are an abstraction, a representation of a process or situation; context helps users to link this abstraction back to reality.
Displaying excessive detail or precision: While a dashboard can be used to promote investigation or understanding, it must display the right level of complexity and detail - neither too much nor too little. It is a hard balance to strike but essential nonetheless.
Misusing or overusing colour: Color should be used purposefully, with intent, and not in a distracting or misleading way.
Arranging the data poorly: Poor layout can make a dashboard hard to navigate, especially if it includes lots of details or is designed to enable further exploration. Visual hierarchy makes a lot of difference in promoting understanding.
Should you read it?
If you’re curious about data visualisation and particularly into the world of creating dashboards, you should give it a go. I wouldn’t recommend it for beginners as its advice can feel a bit outdated. It also requires a bit more practical experience from the readers to make sense of some of the critical tone in the text.
I wouldn’t dismiss it, though, as it is a classic and heavily referenced by other authors in the field. But if you have to choose, there are other more current books you can pick before you get to this one to get more in-depth on how to improve your dashboard designs, considering the latest research and advancements in how humans interact with technology and consume data.
Always check your local library first to see if any of the books I recommend are available. If they’re not, consider donating a copy!
Get a copy at your local library | Amazon
If you subscribe to my monthly Newsletter, you’ll get a summary of all recommendations, plus more of my data viz musings.
You can also follow Data Rocks on LinkedIn or read this and other articles on Medium.
Comments