By: Bridget Cogley
By: Bridget Cogley
Editor's Note: This article was originally published in December 2019 by Bridget on Tableau Fit.
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.
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.
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:
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?
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.
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.
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…
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.
Please read "Building Data Literate Teams with Tableau-Busting the Buzzword-Part 2" to explore alternatives to unicorn hunting.