Occasionally, I come across a claim on social media that, in order to become truly competent at dataviz, you need to know about theoretical concepts such as graphical objects, encoding channels, and preattentive attributes of visual perception.
Is that true, though? Or can you still create effective charts without knowing about those theoretical concepts? Well, if it were true, graduates of my Practical Charts course still wouldn’t be competent chart creators because that course includes virtually no theory. Workshop alumni frequently tell me, however, that their charts are much more effective after taking the course, and that their charts no longer leave audiences confused, bored, or misled. Clearly, then, it’s possible to create highly effective charts without knowing dataviz theory.
Does that mean that no one needs to learn dataviz theory? Well, if you create data art, scientific charts, data journalism pieces or other types of highly customized visualizations, you’d probably laugh at that idea because theoretical concepts such as marks (or geoms), encoding channels, and spatial transformations are so central to your work.
So, should you learn dataviz theory or not? Well, as dataviz guru Andy Cotgreave is fond of saying, it depends. For this question specifically, I think it depends on what kind of work you’ll be doing:
I do think you need to learn dataviz theory if you’ll be…
Creating highly unusual, novel, or customized visualizations, such as data art, scientific charts, domain-specific charts, or data journalism pieces, or…
Doing dataviz research, or…
Developing dataviz software, or…
Creating visualizations by writing code that leverages low-level charting libraries such as ggplot or D3.
I don’t think that you need to learn dataviz theory if…
You won’t be creating any of the types of visualizations listed above, and…
You’ll only be creating “everyday” charts for reports and presentations (which can virtually always be accomplished using a few dozen common chart types), and…
You’ll only be using GUI (Graphical User Interface) applications such as Microsoft Excel, Google Sheets, or Tableau Desktop to create charts.
The vast majority of people who create charts fall into that second group, that is, they’ll only ever need to create everyday charts using a GUI application (or, probably very soon, natural language prompts). Therefore, some chart creators need to learn dataviz theory, but most don’t, IMO.
Does this mean that, if you’re just creating everyday charts, you don’t need to learn anything? No, creating effective, accurate, everyday charts requires quite a bit of practical know-how, including knowing how to choose chart types, quantitative scale ranges, and color palettes, as well as how to tackle common challenges such as handling outliers or showing very large numbers of values. You also need to know how to avoid many common dataviz mistakes, such as failing to annotate bars of zero length in a bar chart, or using a sequential color palette to identify non-sequential categories.
If you only create everyday charts, why not learn practical guidelines and dataviz theory? Learning theory in addition to practice can’t hurt, right? Well, no, it wouldn’t hurt, but…
It would substantially increase the time required to learn how to create effective everyday charts. For example, despite containing virtually no theory, my Practical Charts course is still two full days or four half-days in length, and adding fundamental theoretical concepts would make it considerably longer.
Some theoretical concepts can be hard to grasp and may involve advanced mathematics, so it can require quite a bit of effort to learn them, depending on your background. If you’ll never need those theoretical concepts in practice, then, learning them could suck up a lot of effort for little benefit.
What about only learning theory and skipping learning the practical guidelines? Would you be able to create effective everyday charts if you only know theory? No, I suspect that your everyday charts wouldn’t be as effective as those created by someone who’s been trained with a good set of practical guidelines. If you’ve only learned theory, it might, for example, not occur to you to include helpful callouts, comparison values, inset charts, or other features that make key takeaways obvious, or you might create charts that are too complex or unfamiliar for the level of data savviness of the audience.
Theoretical concepts are also harder to translate into real-world chart design choices compared with practical guidelines that are more “concrete” and specific. Theoretical concepts tend to leave many possible design choices open, but practical guidelines quickly narrow down those design choices, and often point to a single design choice.
Now, I can already hear some experienced chart creators objecting that guidelines that are that specific constrain creativity, but that’s only true if one considers practical guidelines to be unbreakable rules, which I do not consider them to be. Good guidelines reliably point to good design choices, but an experienced chart creator may occasionally think of better—or even brilliant—design choices in specific situations. Therefore, an experienced chart creator can—and should—deviate from guidelines, as long as the chart creator is aware of those guidelines and has good reasons for deviating from them. I think of practical guidelines as “training wheels” that help learners become competent quickly, and that help them avoid common chart design mistakes; they’re not unbreakable rules that define what’s “correct” or “incorrect.”
Many people—including me—think of dataviz as a language. In that analogy, I consider dataviz theory to be the “linguistics” (morphology, phonetics, etc.) of the language of dataviz. If you want to study language, invent new words, or use language in very unique or creative ways, you should learn linguistics. If, however, you just need to write clear emails and reports, you might want to spend your time learning more practical writing skills instead.
Agree? Disagree? Awesome! Let me know in the comments or on LinkedIn or Twitter.
