When I landed my first role that officially had anything to do with data (Insights Analyst), we did everything in Microsoft Excel. It was a large company, but its data practice wasn’t great. For many back then, data was this buzzword they were trying to grapple with. The concern was more about not being left behind rather than making sure they made the best of it. Governance was non-existent. Documentation was sparse and outdated. Data was siloed in the hands of a few specialists who had all of its meaning in their heads. If they left or retired, the knowledge would all go with them. And they relied on a gamut of tools for their reporting, fragmenting the practice across multiple platforms, legacy and new. The result was a lack of trust, lack of access to data in a workable condition, and suspicion whenever a data analyst entered the room or joined a meeting.
The team was trying to cope with the sheer number of requests for data. Their reaction was often defensive and resulted in blaming stakeholders for their lack of grasp on dealing with code or systems. Comments like “They don’t even know basic Math!” or “I gave them this a couple of months ago; why can’t they just learn where to get it again?” were commonplace. On the business side, the comments ranged from “I don’t want to talk to the data team again, but I have no choice” to “Those data guys think they’re so smart, but these numbers are all wrong! I’ll do it myself instead…”. Not great.
The data team was not bad, but they were clearly misguided, and their frustrations resulted in them placing blame in the wrong spots. They were a closed team. There was no communication with others outside of their data bubble. They were mostly around the same age, all male. When someone asks me how I ended up working in a data role, I usually answer that the role chose me, not the other way around. I was a new immigrant, recently arrived. I was looking for a job in a field I had experience with, which could get me a good start. I applied for a supply chain planner role - a field I had worked with for quite some time. And then, I received a call saying they had a role as an Insights Analyst in a data team that worked alongside the supply chain business unit. The description sounded good and like something I could do. The recruiter did give me a brief warning that I didn’t quite catch at the time, though. “They are looking to add more diversity to the team, and someone who knows the business side and communicates well is just the right fit!”. It didn’t take long after I was hired for me to start hearing comments along the lines of “they just hired you because you’re a woman” or “in this country, we don’t do things that way.” I was their first diversity hire, as they’d call it. Trailblazing seems to be my middle name, so I went along with it.
I bring this up because of where it took me in my data experience. I ended up being allocated to deal with what my team considered the most difficult stakeholders - they made a lot of noise, were very opinionated, asked for a lot of data, and their area was deemed less important than others. I was allocated to do Health and Safety reports. They didn’t have the glamour of Finance or Customer Experience, which had a direct channel to the C-suite executives. They weren’t operationally vital like Logistics or Shipping, the heartbeat of any supply chain. They were the guys who told everyone on the factory and distribution centre floors that they had to wash their hands. My stakeholders were shift managers and supervisors. There were several of them. The company had sites nationwide, some in quite remote areas. We were this virtual, distant, faceless team they had to deal with whenever they needed a spreadsheet with a few numbers on things like damages, injuries, or pest control. Most of my stakeholders barely spent time in front of a computer at all. It was basically the role none of them wanted.
A couple of weeks in, I got the most painful spreadsheet I had ever seen to update. It was a report that, in theory, should be updated and sent to all sites monthly. I say in theory because my manager - who was trying to run the report while they were looking for a new hire - told me some months the spreadsheet just didn’t work. Something to do with broken lookups, he said. And with no documentation and 30min of general guidance on where to get data (emails) and how to update the report (paste them and refresh tables), I was stuck with this spreadsheet. It was about Pest Control. A subject that, every time I brought it up, would get people flinching and frowning because ‘eww - rats and flies!’
As a curious person who grew up in an old house, I don’t flinch much at rodents and insects. If someone had to count and report on them, I would do it, and I would do it well. Considering that nobody was really that interested in what I’d be doing with this report, I took it as a chance to well…. do whatever I wanted. The few calls I had from site managers were lovely, actually. Here I had real people doing real jobs (not bullshit ones), caring about the Health and Safety of the company’s products and their staff. They were interested; they wanted to have information and do better. They just didn’t have anyone who cared enough to help them before. So, I did. And it was talking to them that I discovered a project aimed at reducing the risk of pests entering the sites. They were hiring external companies to help them assess the need for specialised services. In a couple of months, I knew everything there was to know about how this project worked and how the service providers counted and reported pests on site. It was a fascinating new world. Who knew there was someone out there whose job is to trap a bunch of mosquitoes in adhesive tape to later count and classify them to learn their behaviour!
Long story short, by the third month, I had created my first piece of work that could fit the definition of a dashboard! A Pest Management Dashboard! Probably one of the works I’m most proud of, not because of how it looked but because of all the work I did alongside people who cared about it so much. That terrible spreadsheet I inherited became a process for the sites to report their data to one central point at the Pest Control provider, who would make sure everything was correct and then send it back to me, where I fed it to a neat-looking dashboard that was then printed out and pinned to the sites’ notice boards around the country. It was really nice to visit a distribution centre and see my work there for everyone to see. Even though some of my colleagues would still joke about me being the lady who counted rats, I couldn’t be prouder. A subject that used to make most people flinch was now being mentioned in meetings, and people started paying attention to success stories about Pest Control - as there was no evidence of what worked and what didn’t previously.
About a year after the first iteration of my Pest Management Dashboard, the company introduced Tableau as the new reporting tool, and a new era of data started to unfold. Soon enough, we were tasked with transferring all of our work into this new tool. And so I had to re-learn all I knew about dashboard making. But at the same time, a new world opened up before my eyes - Tableau was this amazing tool that could help me make all of those little improvements my stakeholders were asking for, which I had no idea how I would manage in a spreadsheet without making it unnecessarily complex. Tableau was love at first chart.
The year was 2016. And back then, although we already had a wealth of training materials and very engaging forum discussions about Tableau, there wasn’t much in the way of what good examples of dashboards looked like. I did mine more or less intuitively and based on a lot of feedback and iteration. If I noticed someone struggling to find the information they needed on my reports, I’d change things around to make it easier for them. This empirical process was time-consuming, but it taught me plenty about how different people perceived what I produced for them. And yet, I missed having more concrete advice about what worked and how. My first contact with literature about dashboards was with Stephen Few’s books. But even though I learned and used many of the principles, it didn’t feel practical enough - the books are filled with examples of things not to do, and the few examples of what he considered good did not fit my stakeholders' requirements.
A little later (sometime halfway through 2017), I noticed a lot of buzz in the Tableau forums about a new book coming out, all about dashboards - and this is how I first came across today’s subject: The Big Book of Dashboards by Steve Wexler, Jeffrey Shaffer & Andy Cotgreave.
The Cotgreave Tooltip
My Excel dashboard had seasonality charts. They were a new concept for my stakeholders, but they fit the data really well. We made a big effort in tracking back old spreadsheets to consolidate 24 months' worth of previous data to help us understand the seasonal behaviour of certain pest species. For example, this allowed us to realise that the most critical period wasn’t Summer, as we initially thought. It was Autumn because rodents want to hide in warm places when the temperature starts to drop. During Summer, they prefer to be out and about - and this means that a cozy place like a warm factory becomes really attractive as temperature drops. But as with any successful dashboard, people start getting more questions as they use it. One of these questions was a breakdown of where, of 3 levels of traps, most pests were detected over time. Doing this on Excel meant adding more charts to an already busy display. I added a table at the very bottom, breaking down the charts in more detail, but then seasonality visibility is somewhat lost. The person reading the dashboard had to make a mental note that they were interested in a particular month (say, April) and then look for April’s row in the table underneath to check the breakdown. It gets the job done, but it isn’t ideal. I’d often receive calls asking about this information, only to explain it was there, just not as visible.
It may seem like a small annoyance, but this is what dashboard design is all about - the small iterative adjustments that help it remain relevant to your audience as they learn to rely more and more on data. With the change over to Tableau, though, I got access to a range of new ways to visualise the same data. One way was through the addition of tooltips! I could now just add a little extra interactive tooltip to each month’s total where they could see the breakdown by area of their sites. But back in the day, Tableau didn’t have visuals in tooltips. It was all text. Even though adding this extra layer of detail on demand did add to the overall experience, the fact that it was all text still made it a little bit harder to identify where the focus should be. Less difficult than before, but still not super easy.
Back then, the Tableau Forums were super active. We’d get hyper-detailed tutorials and walkthroughs from the community, and it was always awesome to spend some time every day scrolling through the most discussed topics. It was also the place to discover people to follow on Tableau Public and on the forums, as they’d always contribute with awesome ways to bend the tool’s features to their needs. That’s when names like Ben Jones, Ken and Kevin Flerlage and Andy Cotgreave became familiar to me. Andy Cotgreave had this outstanding post about how to use text elements, such as font symbols, to create the shape and illusion of bar charts into text-only tooltips. They became known in the Tableau Community Forums as The Cotgreave Tooltip, and they also featured on my first-ever Tableau dashboard, to the amusement and delight of my stakeholders, who loved that they could finally get the nice small details they longed for.
And because I followed Andy’s work ever since, it almost felt like The Big Book of Dashboards was made for me in a way - the lurker longing for examples of what good dashboards looked like, alongside critique and feedback on what made them awesome and how to implement such advice in my creations. I don’t think I ever felt as closely identified as the audience of a book before. I never miss a chance to recommend it to anyone looking to improve their dashboard practice - and now you all know why.
If you can only read one book about dashboards, let it be this one
That sums up everything I’ll say from here on.
But here’s the detail.
If you have ever tried looking for examples of well-designed dashboards on the web, you probably found one of two situations:
Plenty of examples of very poorly designed dashboards, sometimes alongside advice of what not to do, but no examples of what good looks like in that context;
Dashboards inspired by web design, which look awesome but have very little substance and content.
Either situation will leave you wishing there was a resource that could give you some more consistent and reliable guidance. The Big Book of Dashboards is the antithesis of the books about dashboards that came before it. It is not preoccupied with the semantics of what a dashboard is or isn’t so much as it aims to be a trustworthy resource filled with examples of what good looks like. Not only that, the authors use their 30+ years of combined experience in crafting dashboards to explain why certain things work better than others. It is the book you’ll fill with Post-it notes, draw over, and take out of your bookshelf a dozen times a week for inspiration.
The book is structured in three parts:
Part I gives a primer on data visualisation principles. Even though it doesn’t discuss every aspect in-depth, it goes deep enough to clarify some important aspects without overwhelming beginners. It provides the right amount of information to get you going with your learning while leaving you wanting more. It covers topics such as colour, preattentive attributes and a brief explainer of the most commonly used chart types. It has the obligatory warning about pie charts.
Part II constitutes the bulk of the book. Each chapter breaks down the concept and execution of a different dashboard. There are 28 dashboards in total. Each covers a different subject, across multiple fields, from different authors. The variety in purpose, audience, design and approach makes for a very engaging exploration of how dashboards go from idea to final form. In each chapter, the three authors give their critique, advice and elect a few central topics to discuss a bit further. There are instances where they discuss alternatives, iterate on the original dashboards, or highlight specific features with more examples of how they can be used in other situations. It is an easy but fulfilling read, and even if the dashboard of a certain chapter seems to be from an area you’ll never imagine yourself working with, every chapter has a precious lesson that you can easily transfer to your own work. This section is the one you’ll keep going back to over and over.
Part III concludes the book by diving deeper into certain subjects that permeate most dashboard discussions. It brings up themes like the multiple ways you can visualise time series or how asking why is the real winning factor in most successful dashboards. The last few chapters contain tool-agnostic, timeless advice that can be useful to anyone producing visual displays of information to others.
I have many favourite things in this book. But here are some of them:
My first favourite aspect of the book isn’t necessarily explicit in its content. If you read it cover to cover, there’s a common thread that comes through the author's attitude towards all works they analyse and pick apart. While creating a successful dashboard takes a good grasp of different elements - analytics, design, visual hierarchy, colour, layout, etc., the biggest success factor seems to be feedback and iteration. You can see it in every chapter: a dashboard has an initial outline, and while the vision may already be somewhat established, it is the multiple rounds of feedback and iterations that take all works from good to outstanding. Going through this process guided by such experienced and thoughtful voices in the field makes for an awesome reading experience.
My second favourite thing is the term that best defines how to call the big numbers at the top of a visual display (usually depicting KPIs). The BANs - originally Big Ass Numbers (or Big Angry Numbers, or Big Aggregate Numbers). Apparently, it was Steve Wexler who coined the term! One for History.
And my third favourite thing is how the authors chose to clearly label which examples are not good ones:
On a more practical note, here are some of the big lessons I took from The Big Book of Dashboards:
Establish your visual hierarchy: how many pieces of information or themes do you intend to display? What are the most important bits? And what are the second and third most important ones? You can use attributes like size (Big Numbers, typography size), colour (with highlights), or position (most important at the top, least important at the bottom) to help your audience navigate your dashboard.
Design to a grid: this is a favourite of Jeffrey Shaffer’s across the book (along with typography!). When you have a grid as the base of your layout, placing elements is much easier and makes for a more harmonic and organised layout.
Reduce clutter: adding more to a screen is always easier than removing. But we should strive to remove everything for which we can’t have a clear explanation. If it doesn’t have a good reason to be on-screen, it is probably best to remove it!
Iterate, iterate and iterate again: I see my dashboard process as a loop, likely because I’ve learned that my best work has always resulted from deep collaboration with my audience. Iterating as they evolve is a great way to ensure long-term adoption while you support your audience’s journey to becoming more fluent in data.
Learn from others: find and look at different examples of great dashboards. Pick them apart. Reverse engineer them. Figure out what differentiates them from not-so-great examples. Put it in words and try to replicate similar principles in your work.
Should you read it?
If you’re looking into improving your dashboard design practice, this is a resounding YES.
Just go and get your own copy of the book. You won’t regret it.
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.
