Friday, May 25, 2012

telling multiple stories (part 1)

When it comes to data visualization, I often emphasize the importance of identifying the single most important story you want to tell and crafting a visual to support this. But how should you approach the visualization challenge when there are multiple stories you want to tell with the same data? How can we do that in a way that holds our audience's attention and is effective?

I conducted a workshop at Google recently, where this challenge was presented. The group (and I apologize for the intentional vagueness that I will have to use throughout this example due to the sensitive nature of the content) had recently given an informational presentation internally where they wanted to show a visual and then multiple different takeaways that the audience should know from each visual.

Here is one such example:


In the above, the details have been hidden/generalized to preserve the confidentiality of the information. But generally, we can see there are multiple comparisons trying to be made: first, how the metric of interest (graphed along y-axis) varies across different categories; second, how the metric varies by country.

I have two main issues with this visual: 1) the comparisons are difficult to make visually, and 2) I'm left to try to determine what's important on my own - there are no visual cues or descriptions to help me out
and tell a story with the data that is shown. Where should I focus? What is interesting about it? Why should I care?

Here's a recap of the lessons we can apply here and a peak into my thought process as I consider and play with the data:
  • Determine the best chart type: I initially thought that a horizontal bar chart might be easier to read, but a quick check showed this was not the case: it was harder to orient the words in a way that was legible. The vertical bar chart also fits on the page/screen better. So I elected to keep the basic chart the same.
  • Determine the primary comparison you want the audience to make: In the initial visual, this wasn't clear - because roughly equal visual attention was drawn to each (to category through spacial separation, to country by color), neither comparison was very easy to make visually. In my makeover, I decided category would be the primary comparison I wanted my audience to make. Note that country is still there, but less attention is drawn to it, so this becomes a second-order priority visual comparison; I know it will take my audience a little more work to do and I've decided I'm ok with that.
  • Order the categories in a way that makes sense: I knew I wanted to order the categories from greatest to least - this provides an overall framework to the visual that makes for easier interpretation than haphazard category order. (Note that I could have also chosen to order from least to greatest, depending on how I wanted to frame the story to be told: keep in mind that, all else equal, most people's attention will go to the top left side of your visual first, so you generally want to put the most important parts there.)
  • Reduce visual clutter: The black background underemphasizes my data and overemphasizes things that aren't so interesting like gridlines. I stripped out everything I didn't think needed to be there and pushed some of the remaining things that need to be there but don't need to draw a lot of attention to the background by making them grey or smaller. As part of my clutter reduction, I also made sure that I was using color with a distinct purpose (getting rid of red titles, etc.).
  • Tell a story: Finally, I wanted to use words to describe what is interesting about the visual and give my audience a sense of where they should pay attention and why. Note how the comments are connected to the data they describe through both proximity and color linkage.
Now that I've described what I did, here's the unveiling of the madeover visual:



In this example, we looked at how you can tell multiple stories with the same data in a single visual. Stay tuned for the next post, where we'll continue this topic and look at an example that illustrates the benefit of repetition and how the strategic use of preattentive attributes can help you to draw attention and build a story around different parts of a robust visual.

Sunday, May 13, 2012

creating a visual story: questions to ask

One observation made to me after a recent workshop was that, beyond data visualization, the class was useful for drawing attention to an important part of the analytical process that is sometimes skipped: what are we trying to say with what we show?


Often, it seems, people want data. Sometimes, this desire is in absence of a specific purpose. But part of our job as an analyst (and if you are reading this and aren't an analyst by title, I encourage you to put on your analyst hat, which, if you ever touch data you have somewhere in your closet) is to help people to understand why they want data, to uncover what it is that the data can help us understand to drive some sort of action. Within the context of communicating to an audience, my personal belief is that showing data in absence of a specific purpose and call to action is lazy (I'm being intentionally provocative here) and that showing no data is better than showing data that hasn't been well thought through.

In terms of thinking things through, I was recently asked for a list of questions to use when forming a visual story with data, so I've taken a stab at that here:
  • Who is your audience?
  • What do you want your audience to know/do? Why should they care? What's in it from them?
  • What data is accessible to you that will best reinforce this message?
  • What context is essential? Think about this both in terms of words (did something significant happen that needs to be explained?) and in data (is there a comparison point that's important to show?).
  • What is the story you are trying to tell? Does the visual that you've created do this?
The questions above aren't linear - you should find yourself asking repeated versions of these throughout the analytical process: to determine what data to gather, to determine what data to show, to determine how to show it, to determine how to build a story around it.

After you've gone through the process, there is an easy way to tell if you were successful: seek feedback. Often, the most useful feedback will come from someone who is unfamiliar with the information (as we become familiar with our work, we lose the ability to see things that don't make sense to someone less familiar, and any audience is going to be less familiar with our work than we are): find a colleague, a friend, a family member, give them your visual and have them talk you through what they see. There is useful information in where they focus and what questions they ask that will help direct you as you iterate and refine your visual story.

Are there other questions you find yourself asking when you create your data visuals or when you are interpreting those made by others?

Tuesday, May 8, 2012

visual editing

This week, I have the pleasure of presenting to three audiences on the topic of storytelling with data. Thank you to those who attended (and those who soon will) for your interest in the topic, example visual submissions, attention, and thoughtful questions and comments.

After today's session, one participant made an insightful observation: the process I teach for making effective data visuals is very similar to the editing process for the written word. When I paused to think about it, the parallels are striking. Here is a sample:

  • Make your point crystal clear. When possible, state it up front.
  • Remove things that are ancillary or detract/distract from the core message.
  • If you can say the same thing with fewer words (or visuals!), do so.

The list of similarities goes on. With a day job as an editor, in addition to this observation, the participant noted a challenge he often faces. While with the written word, there are clear rules guiding and providing rationale for critique - it's difficult for someone to argue with feedback when a word is misspelled or grammar is incorrect - we don't seem to have agreed upon rules or language to use when it comes to visuals, which can make convincing someone to take editorial feedback in this area difficult.

The specific question posed was: what language can I use to justify editorial feedback on data visualizations?

I think this is one of those areas where there is no single right answer. I can talk for hours (and have a couple times in the past two days) about why the things I teach are important and show empirical evidence on the impact of well-designed visuals time and time again through examples. But is there an easy, quick, universally accepted way to convince someone of the 'right' way to visualize information? I think it's in part because there isn't a single right way - there aren't so many rules when it comes to data viz, and even in cases where there are accepted best practices, they aren't widely taught - that this is a challenging space.

Though many of the ideas are, the language itself that experts use in this space isn't pervasive or consistent (perhaps because data visualization draws from a number of different fields, each with their own language: statistics, design, computer programming, journalism). Nancy Duarte discusses maximizing the signal to noise ratio. Edward Tufte focuses on ridding visuals of chart junk. I personally don't use consistent language: in one sentence I'll talk about identifying and eliminating clutter, while in the next I'll discuss the "crud" 3D introduces or being aware of adding items to your visual that are taking up space or attention but aren't adding informative value. I found that my answer to the specific question posed focused on reducing cognitive load, which may be fine for helping to convince some audiences, but fall flat with others.

Because I feel I'm still thinking my way through a good answer to this question - how to convince someone quickly of the value of drawing attention to the important parts of your visual and stripping out the things that don't need to be there - I will pose the question here in hopes of gaining some wisdom from the crowd:

What language do you use to convince yourself and others of the value of the visual editing process when it comes to data visualization? 

Leave a comment with your thoughts!

Tuesday, May 1, 2012

I like camembert, but I don't like pie charts

Earlier today, while reading a brief NYT article on William Playfair and the genesis of pie charts (link), I learned a fun new fact: in France, pie charts are referred to as le camembert.

I suppose it's not so strange that the hard-to-read visual we named after a sweet circle dessert in English is described by a savory dessert in France. But I still find this wildly amusing (yes, I am a dork; I take no shame in that). So much so, in fact, that I almost didn't believe it at first. But a quick minute in Google Translate confirmed it for me:


Alas, if only pie charts were as effective of a visual as pies or cheese are as tasty desserts. (personal diatribe)