IN SOME WAYS, data visualization is a terrible term. It reduces the idea of good charts to a mechanical procedure. It evokes the tools and methodology required to create when it should evoke the creation itself. It’s like calling Moby-Dick a “word sequentialization” or Starry Night a “pigment distribution.”

It also reflects an ongoing obsession in the dataviz world with process over outcomes. Even now, most of the energy poured into teaching dataviz focuses on making sure you do it the “right” way or judging you if you do it the “wrong” way; on picking the right form; on when to use what colors. Chart crit is all about technique, how the thing was built, what it looks like.

Enough of all that. Forget right charts and wrong charts. Data is only a middleman between phenomena and your ideas about them.¹ And visualization is merely a procedure, a way of using that middleman to communicate ideas that convey much more than just pictures of statistics. What we do, really, when we make good charts is get at some truth and move people to feel that truth: To see what couldn’t be seen before. To change minds. To cause action. It’s not data visualization so much as visual rhetoric: the art of graphical discourse.

A common understanding of some basic grammar is necessary for that, of course. We all need to use subjects and verbs in roughly the same way if we’re to communicate. But letting them govern our communication would be paralyzing and counterproductive. When you obsess on the minutiae of visualization rules—or, worse, when you judge a chart according to its relative adherence to those rules—you become one of Emerson’s little statesmen, adoring foolish consistencies, which as he noted, are the hobgoblins of little minds.

Besides, software is beginning to take care of all that for you. Tools are evolving to manage some of the grammar.² They’re getting their own versions of document templates, spell-check, and grammar check to guide formatting decisions and correct common missteps. Decisions about color, labels, grid lines, even what chart type to use—decisions to which entire books and courses have been devoted—are being encoded into visualization software so that the output in its default state is at least pretty good.

Interactivity helps too. The number and type of labels to include in a visualization, for example, is a decision that we’re used to making as we construct charts, and it can be difficult. Too many labels create clutter, making it hard to know where to focus; not enough confuse viewers and, likewise, make choosing the proper focus a challenge. But hover states help solve the problem. Toggles manage complexity by showing or hiding variables as needed. A simple Next button can control the pace at which information is added or removed from a visualization.

More intelligence is being built into software. It’s early days still, but some programs aim to look at your data and be able to suggest a chart type to you—not unlike the way the streaming platform Netflix will now just play a show it thinks you’ll like. If it works, this could be a powerful prototyping advance. Software is also trying to build story into its structure, helping you to find and build multiple charts that work together.

Visualization is becoming fundamentally more interactive. I look forward to the day when we’ll take for granted that decisions about what to show or where to focus—decisions you once had to make ahead of time and commit to—can be handled in medias res, often by the user. And those decisions will be alterable. Users will control the pace of the storytelling. Depth and complexity will become on-demand services. Show me more. Show me less. Show me just this. Show me only that. In a presentation, a manager will display a good chart and then filter and adjust it when the CEO asks, “What does that curve look like if we exclude the younger demographic?” A new, good chart will immediately appear on the screen. “Now just show me how women responded.” Presentations will become conversations, exploratory dataviz in the boardroom.

We’re starting to see such functionality in a tool like Flourish, which is evolving to make good visualization with presentation-worthy design into deeply interactive storytelling. First, I see an overall picture; then that picture breaks apart into a series of small multiples that represent each variable as a separate chart (animated well). Then I zoom in on one of those small multiples to talk about that one variable. Then I add another variable to compare two. On and on. I can do on-demand prototyping, exploratory visualization, and declarative visualization in one space. All I have to do is find the idea I want to convey, the story I want to tell, and iterate until I have it.

In short, visualization tools are evolving to make everything available but not always visible. That cracks things wide open. It changes a visualization’s essential nature from imparted to shared; from a transaction—something you present or hand over—to a collaboration, which you work on and adjust with others.

It’s not near perfect yet. And doing it well, as ever, requires training and time (which you’ve started with this book), but it’s time well spent for anyone who wants to be a good visual communicator.

Charles Hooper is a dataviz consultant who works mostly with Tableau these days, but he used to work in Excel and remembers using Lotus 1-2-3, Harvard Graphics, and a program called Brio. Before that, he hand-drew his visualizations, transferred them to acetate, and displayed them with an overhead projector. “I’m turning 70 next week,” he declares. “And right now, I’m telling you, this is the most exciting time, because it’s getting easy to try things. When it’s not easy, people just follow the specs. But you make it easy, put it in the hands of the masses, give it to businesspeople and not just specialists like me, and they come up with really innovative ways of looking at things. I learn something new every day from people trying out visualization.”

Software will continue to improve, in ways we can already see and in ways we can’t yet imagine. But what it won’t do—what it can’t do—is intuit your specific context. And context, still, is everything. Visual thinking and visual communication will become no less relevant no matter what features are added to software programs. If anything, the better the software gets, and the less you need to stress over the number of ticks you put on your x-axis, or even what chart type to choose, the freer you will be to focus on bringing into high relief the ideas you want to communicate. The process of setting your context, finding your main idea, and visualizing it persuasively—that is, the guts of this book—will still be the most critical skills you can develop.

And still—despite Hooper’s (and my own) excitement about the tools and where they’re going—I insist that you can develop those visual thinking and communication skills with little more than paper, some pencils, and someone to talk to. I believe as strongly as ever that the craft is in the thinking. That the feelings behind their eyes which your good charts create don’t come from software.

They come from you.

Good luck.