How we made the BBC Audiences Tableau Style Guide
tl;dr — we made a style guide to help our teams make awesome dashboards, you can see it on Tableau Public
The BBC has a long history of looking at data to ensure that the many and varied voices of its audiences are top of mind in all decisions made in the organisation. And these voices are represented by the Audiences department day-to-day in many different ways. The BBC conducts focus groups, commissions surveys, uses web analytics, develops perception trackers and follows social media to achieve this. And that’s just scratching the surface.
And often (if not in most cases) this data gets visualised in some way or form, including PowerPoint decks, Excel summaries, emails, our internal websites, custom code in R and Python and a wide range of small tools, plugins and dashboards.
Roughly two years ago we started using Tableau to help create meaningful stories out of the data that is available to us. As through and through data visualisation geeks we’ve been lucky enough to lead on that process.
Initially, we decided to use the tool in what we referred to as the “wild west” approach — anybody building in Tableau was encouraged to do so in any way they saw fit. This was a conscious decision. Many of our researchers, analysts and data scientists were getting used to the tool, and we wanted to make sure they got as comfortable as possible using it without somebody looking over their shoulder, nudging them to tweak the way the visualisation worked, the colour choices they made or the approach to layout.
In parallel, however, we worked to develop an internal course aimed at helping develop data visualisation literacy. If we were going to ask our teams to suddenly also become data visualisation experts, we felt it was necessary that they have the theoretical foundation to think like data visualisation experts.
The one-day course looked at general design principles, how to use gestalt for effective design, how to apply Tufte’s thinking to everyday reporting, design for accessibility, approaches to colour for data visualisation and how to become more eloquent with their graph choices (based around the fantastic Visual Vocabulary developed by the FT’s data visualisation team).
And then, a few months ago, we started on formalising a style guide that could be used by our Tableau developers.
In developing the guide we had three core aims:
- Create a consistent user experience for all BBC stakeholders accessing dashboards and visualisations on our Tableau Server
- Ensure adoption of best practice data visualisation throughout
- And finally, ensure that all dashboards are a recognisable part of the high quality output produced by the Audiences team
Alongside these aims, we had a few other considerations. We wanted to make sure that dashboard builds used the capabilities Tableau offers to the utmost. We were keenly aware that the style guide shouldn’t be adding onto the development time (otherwise the project wouldn’t work). We wanted the style guide to be flexible and expandable enough to accommodate changes in Tableau’s capabilities or changes to data visualisation best practice. And, finally, it was essential that we relied on expertise from all corners to provide a strong rationale for the design choices in the style guide.
We started with that last point and devoured a pretty eclectic mix of resources that would help us bring this together. We knew the aforementioned Visual Vocabulary would play a part. We looked at every possible visualisation style guide we could find (The Sunlight Foundation, the ONS and IBM being the standouts in our selection). We looked at storytelling, interaction, colour principles, and chart design principles (approaches from Datawrapper’s Lisa Charlotte Rost get referenced throughout). And we were very lucky to work with the BBC’s UX department who we consulted with on a regular basis, shedding a light on all our blind spots.
We also tested iterations with Tableau developers to understand how they would use the guide. One of the things that came up as a challenge early on was that they often came back with “I want to do this, but don’t know how”. At the same time we wanted to make sure that this guide isn’t a how-to make things in Tableau, but what to strive towards visually. Luckily the Tableau community is great at sharing its techniques, which meant we made a point of linking to what we consider to be the best throughout.
While doing desk research, one of the big questions that we kept coming back to was “How are we going to deliver this?” It looks like a simple question, but we iterated a lot. We considered using our internal website to document and screenshot approaches. We looked at developing PDFs that people could reference. And we even went a little bit out there, by starting some designs that could be used as a Top Trumps deck.
None of these really clicked. And in many ways, the obvious choice was staring us in the face — just develop the whole thing natively in Tableau. This would mean users would be able to see the principles in practice, it was easily shareable through our Tableau Server and developers would be able to download and adapt the workbook or tinker to see what’s under the hood.
With those key elements in place we started development in earnest. The guide is split into two core areas: style guide principles (mainly tackling consistency) and charts in practice (tackling the best practice approaches in visualising datasets in Tableau).
There were three things in particular that we really wanted to get right.
One was interaction, which, from what we’ve seen, often got overlooked in builds. Tableau creates a lot of what Don Norman would call “affordances”. In other words, opportunities to interact. At the same time, we noticed that these opportunities often led nowhere. Clicking on a part of the visualisation would have no effect. We really wanted to make sure that wasn’t the case and that users always see an effect in the interactions they have.
This meant codifying what those effects are. The deceptively simple principles we came up with were:
- Click to filter
- Hover to highlight
- Menus to navigate and investigate other options
The second part we really wanted to drive home was around structured layout. In other words, using the space of each visualisation to guide the reader through a visualisation. Conveniently, Tableau recommend this as part of their guided analytics approach (requires registration). So we collaborated with Tableau to do a couple of internal sessions on how this approach works in practice.
The third, and trickiest part, we really wanted to make sure came together was colour. And this is tricky because, from what we’ve seen, use of colour was often subjective, at best relying on learnt habits (brand x has red as a dominant colour, so we’ll use red in this chart, brand y has pink in the logo, so we’ll use pink, etc).
We wanted to make sure that the visualisations work really well and that it’s very hard to get colour wrong. After much deliberation on this, we went with a slight Gordian Knot solution — our developers could use any colour, as long as they used that as their only colour, and they were using it to differentiate data from the rest of the dashboard. We do actually encourage developers to break this rule, but only as long as they can demonstrate they are using colour in a consistent, meaningful and accessible way.
We rolled out the style guide to our internal Tableau community and the reactions were very positive — we even had several teams outside of the Audiences department who wanted to champion the style guide in their departments.
Another key element was that we also offered a template based on the style guide (going back to making sure that the style guide doesn’t impact the amount of time it takes to develop dashboards). This means people start their builds in the template and have less to worry about in terms of their visualisation choices.
But to really make this work, we invited our community to be part of a rotating peer-review panel. Each week we look at a dashboard in development, and our peer review panel produces meaningful feedback structured around the style guide. And it has been amazing to see how the teams we work with now have a very strong rationale when they think about the quality of a visualisation.
This hopefully illustrates the amount of care and thought that goes into communicating audience data within the BBC and gives you a behind-the-scenes peek at how we’ve tried to apply the amazing thinking done by the visualisation community into something that our team now use on a regular basis.
**********************************
The BBC Audiences Tableau Style Guide was developed by Jovan Lekovic and Helen Jones on the BBC’s Audience Insight Data Visualisation Team
A lot of the development of the Style Guide wouldn’t have been possible without the visualisation community publishing their work online — this is an attempt to add to that conversation so if you have questions and comments do let us know
