Part 1: Building Data Literate Teams with Tableau – Busting the Buzzword

I’ll let you in on a little secret. Data literacy goes far beyond chart-making. Don’t get me wrong, charts are swell. I love them in fact and make a whole living out of designing some awesome looking charts (okay, there’s a bit more to it than that, but #AskAnAnalyst and that’s the answer you get).

This post owes a debt to Tableau Conference and the fact I finally got to sneak into the Executive Experience. Maybe I shouldn’t say too much, but after years of begging to just poke my head in, I got in to present. On data literacy! Woohoo!

Maybe it was the 3,000 word treatise I wrote on data literacy or that I spent a ton of time exploring data visualization as a possible language (short answer, no, but it has language-like constructs), but they let me bust some myths with a few others. And, folks, it was awesome! I also got to meet the wonderful Heather Gough and the stellar Buchi Okafor (both who had some ties to Columbus, incidentally enough) who were my co-presenters on this topic. Career highlight aside, there’s real content here, I promise. In fact, there’s so much content, I’m breaking it up this time.

Busting the Buzzword

All too often, we equate data literacy with charts. We typically see the data presented in this manner and it makes sense, much like false cognates do. That is, until we dig deeper.

Graphicacy is an important skill. Don’t let this image convince you otherwise. We’ll get to where this fits into the puzzle in a bit.

So, then, what is data literacy? It’s the ability to navigate the whole cycle of data: from inputs to storage to shaping it on towards defining metrics and dimensions to – the parts we most often recognize – the analysis and output.

Inputs

Our inputs might be Salesforce, MavenLink, Trello, EPIC, and the whole host of software we use on a given day. It can also be forms, such as various surveys and census data. Knowing how this data is inputted can tell you a lot about what you can really derive from it. Take my favorite example from the USDA:

Take a good look at this form. Reminder: I can choose up to any 3 decision-makers to provide this information for in any order. “Involved in decisions for this operation” leaves me pretty open for interpretation, especially if I let people vote on certain decisions or count deciding as being in the room. Looking at inputs tells us what assumptions we can and can’t make with the data.

Storage and Shaping

When we get into storage and shaping, this probably feels like familiar territory. But, don’t get too comfortable, as this is where we set the stage to do a ton of our accuracy work. Are our models transparent enough in their join logic? Are we changing data for storage purposes?

As we prepare this data for analysis, are we preserving the accuracy we expect? What are we removing and why? Are we merging items and redefining them? Do we have a clear understanding of what one row is?

Defining: A Key to Success

As we shape our data, it becomes especially important share our definitions. Is null the same as 0? It may not be and we should probably make this clear to our users. The world loves a good KPI so we need to understand what those measures mean and the impacts they have. You’ll notice this part takes into account the entire diagram. Quality pays dividends. The clearer you are in your definitions, the better others are in presenting and understanding them.

Take the time to make nice folder structures. They may not match tables, but are business-user-centric, so they may match some of the input structures or put like items together (like nested calculations or dates). Comment your calculations, but head also into default properties and add information to your comments (which show on highlight). Rename fields as needed to be human readable or easier to navigate (such as when various dates exist and one is the primary one used for the record). All of the effort here makes for an easier and faster analysis.

Analysis

This is the fun part. We explore the data and begin to understand it. We’re ideally educated in graphicacy, so we know which charts are appropriate and how our users will likely understand them (oh, you thought I’d stop at appropriate – nope! We also have to consider the literacy skills of our users.) As we explore, we start working towards our final output, which in Tableau is likely to be published up to server.

Output

It’s polished, it’s pristine, and it’s the best dashboard you ever made! Friend, you’re not done yet. Test it with your users, delete calculations, and yes, name your sheets (sheet 78 (copy) (copy) is not very helpful). Once you have this and all your other polishing done, share it well.

Ideally, in time, you revisit these. You monitor their use, refine them, and occasionally, delete them entirely. A good dashboard is meeting the needs of its user base.

So now that we know data literacy goes beyond the chart, what comes next? We need people for our team to take our organization to the next level. And with that…

A Preview of our Team

Often, when we recruit for data roles, our demands map to it someone who can do it all – you know, a full stack data developer or whatever fun title we want to pick.

Tune in next time to explore alternatives to unicorn hunting.