Visualization as Process, Not Output

"Please make me a visualization."

I get a lot of emails that say this or some variation of it. They tend to make me think of other requests that could be made in the same form, like:

"Please make me a roast beef sandwich."

Or:

"Please make me a scale model of the Eiffel Tower."

Roast beef sandwiches and scale models of the Eiffel Tower, in these sentences, are common nouns. Visualization, on the other hand, is a verbal noun. The word visualization encapsulates a process. And it's really that process that's the essential part, not the thing that results. A much more exciting e-mail — one that, sadly, I receive much more rarely — would be just use the verb. Something along the lines of:

"Please visualize our data."

The nice thing about this sentence is that it may result in many things. When I set out to make a roast beef sandwich, I almost always end up with...a roast beef sandwich. If we set out to visualize, instead of making a visualization, we can end up with any number of outcomes. In fact, many of those outcomes may not even be visualizations, but rather solutions, new ideas, and better questions. Any good visualization process is iterative. And if we allow ourselves to think more about the value of the branching points of that process than we do a single result, we leave ourselves open to many more possibilities. A verb-based approach to visualization also lets us think of it as a tool that can be used in many different projects; not only those whose results involve charts and graphs, or sticks and balls.

In 2009, I was asked by Jake Barton to design an algorithm that would place the nearly 3,000 names of victims on the 9/11 memorial in Manhattan in specific places, so that certain names could be near each other, per the wishes of their next-of-kin. This was a novel and difficult challenge given the number of possible combinations and the complexity of the personalization required — when I started, I wasn't even sure that it could be done.

The first step, then, was to get some idea of the scale and peculiarities of this particular problem. The data that I was sent was in a spreadsheet. Here's something that I've learned about spreadsheets: no amount of staring at one is going to teach you about the data. In order to get a sense of the data, and therefore the problem, I created a visualization. This simple graphic, hand-rolled in a tool called Processing, shows the pools of the memorial as circles, with each name arranged on the edge of the ring. The lines between those names are the requested adjacencies — names which should, as per the wishes of family members, be placed together:


Figure1.png
A visualization of the victim names and requested adjacencies for the 9/11 Memorial. Fall, 2009

I could have read the number of names and the number of requested connections from the spreadsheet. However, the key part of the problem ended up being in the physical distribution of those connections, which only showed up after sketching. This quick visualization also showed me that the connections were not evenly balanced between the two pools; indeed, they were heavily concentrated in one of the two pools. By building a bespoke visualization quickly, I put the data into a visual form that fit its structure specifically, and got to the core of the problem.

Getting this insight into the character of the data quickly changed my sense that developing an algorithm was impossible. I could now see that it seemed possible.

I think of these small visualization steps as 'sketch points.' I don't have to put too much thought into their aesthetics, as they aren't built for public consumption. I make my sketch points in some kind of expressive medium (like Processing) as opposed to a quicker but more constrained tool (like Excel or Tableau), in order to tailor them to the specifics of the data as closely as possible. In this fashion these stops along the way become low-investment testing grounds for new ideas and unusual approaches.

Here are a few sketch points from recent projects, each of which represented a turning
point in my thinking:

Figure2_dr.jpg
A sketchpoint from a 2011 visualization of 138 years of Popular Science

Figure3.jpeg
A sketchpoint from a the development of Cascade at the NYTimes R&D lab, 2009

Figure4.png
A sketchpoint from the development of a new visualization of ad placement networks, 2013

None of these is meant for public consumption. You're looking at my efforts to work out a problem, to see what I'm up against, and find in the sketches potential ways forward. By thinking about visualization as a process instead of an outcome, we arm ourselves with an incredibly powerful thinking tool. By splitting this process into small, bespoke sketch points, we can engage with the character of our data more specifically, and access a more broad and varied solution space. Data visualization becomes much more than just the end of a sentence.

This entry was posted in Leadership. Bookmark the permalink.

Comments are closed.