Building good infographics part 2: Know your data, know your story

In the first article of this series, we discussed how good planning and team dynamics can make or break even the best design ideas for an info graphic.

In this second article, you’ll learn how to bring together your data and your story into a solid sketch that you can later present.

Part 2: Get to know your data

Try to get to know your data in the beginning, but recognize that, when working with a lot of data, you’ll likely have to keep going back to the numbers as your sketch evolves. Essentially, you’ll need to ensure the numbers support your headlines and story. If you’ve already created other products which this graphic will be promoting, presumably you’re familiar with the data and how it was illustrated for these other pieces–that’s a good starting point. If you’re creating a standalone graphic, you may be staring at Excel files for the first time. Regardless, get to know the data with fresh eyes.

To start, go over the basics. At first blush, what are the most apparent patterns and trends in the data?

To start, go over the basics. At first blush, what are the most apparent patterns and trends? I write mine down on a scratch pad or white board (in red ink, if you’re wondering). For example, is widget use going up or down? Are there geographic or demographic patterns (use is up in the south, down in the north; younger people use more widgets, etc.). I usually do this with my designer, at least for the big-picture stuff.

Then, dig a little deeper.

I like to look at data two ways: if I can, I’ll review the original “raw” data. Typically, when working with large sets of data, much of it it used to create calculations that produce the final data (the stuff that makes its way into Powerpoint, reports and graphics). But sometimes the original data can show interesting things. This raw data (if I understand it) allows me to see parts that were left out of other products (cutting room floor stuff) but that might help serve up a good infographic. Once I review the raw data, only then will I review graphics (if they exist) created from that data for other pieces.

For me, this order works because starting from the raw data helps keep me from forming a bias in favor of things already illustrated when, in fact, there could be a goldmine somewhere in the original data that better serves my graphic’s audience and story. Sometimes (depending on the quantity of the data) the former isn’t remotely possible for a layperson. Many professionals out there use statistical modeling software such as R or SAS  to be able to understand complex data sets. For the purposes of this article, I’m assuming that, like me, you’re the average layperson with a basic understanding of math and Excel.

Talk to your number crunchers with your designer to help both of you understand the data. If you have access to these folks, don’t be shy about going to them and asking them to explain/simplify things you don’t understand. (Often, inscrutible headings and data (likely spit out as a query by a technical person working with a database) can be rewritten and hidden (respectively) to spit out what you need to know. Having a good conversation with your database, IT or researcher is important. Tell them what you want to say, and who you want to say it to. Share a sketch with them so that they can understand the output goal. Oftentimes, they can be a tremendous resource by helping you mine your data. But they can’t do that if you don’t share the big picture with them.

Part 3: Executing the concept

You’ve pitched the concept to your team and now you’ve got the green light. You’ve identified your data sources and are familiar with overall patterns and trends. You’re reasonably confident that those patterns support the key messages that your audience wants to hear.  Congrats. Tank up on coffee, sharpen your pencils, turn off your e-mail notifications and get started with your designer.

Let’s begin by mapping out the actual content. This will eventually lead you to an outline that does two things:

  • Allows you to “read” the content at a high level, which mimics the way most consumers scan (they scan headlines, they scan graphics, etc.).
  • Allows you to begin exploring format–is the content and data best suited for a static graphic or an interactive?

Get the story right from the beginning by chunking out your content into essentials via a paper and pencil sketch. Here, you’re essentially developing a content outline (or several). I usually ask designers to sketch something in pencil rather via computer.

Sketches have a way of relaxing people–they level the playing field, so to speak, by presenting information in a low-key, low-tech manner that is specific enough to give you the gist of the story and data, yet not so specific that stakeholders are led astray into conversations about wordsmithing, color, fonts, etc.

In my experience, there are also designers who, once they spend time “drawing” on the computer, begin to take immediate ownership of that particular design. This can needlessly bias them against the feedback of the team. In my opinion, paper and pencil sketches allow everyone to keep an open mind and focus on the essentials–the rough findings, the order and the data. Leave the wordsmithing and the design to later–get the story right first.

Chunking out your content–how to create a proper sketch. A good sketch chunks out your text into major findings/rough headlines, and illustrates and annotates the order and flow of all of your major graphics and illustrations.

List out your major findings/sections. Start with a large piece of paper and write out the main findings that you want to show in the graphic. These will eventually become succinct headlines, thought-provoking questions, etc. Regardless of what format they ultimately take, they will organize your graphic into major sections (many people call this “chunking out text”). Your goal for these sections should be so that, if the reader reads nothing else, strung together, those headlines would tell your story.

Say you’re selling widgets to engineers. Keep your audience in mind (the audience likely to read your graphic) and write down 3-5 findings:

  • Widgets are taking over the world.
  • Widgets are cheap to produce.
  • Widgets are available near you.

You can turn these points into headlines later. For now, they tell you that your graphic will be divided into three key sections for which you will need to have the basics:

  • headlines
  • brief explanatory or persuasive text that follows/explains each headline
  • illustrations and/or data graphics that support the headline
  • sometimes accompanying text that further highlights the main finding of each data graphic or illustration

Map out the data that supports your findings. You and your designer can use your understanding of the data to pare it down into simpler graphs that show the findings. Your designer can suggest the format, and you can provide the audience’s perspective of whether the designer’s suggestion does two important things:

  • Does the graphic and the numbers support the claim (e.g., widgets are taking over the world)?
  • Does the format (bar chart, pie chart, etc) make it very simple to understand the data?

You can make the graphics complex later, but for now simply draw them so that they show the gist of the data. This pared down graph is what goes into your sketch below each headline. Again, you don’t need to ask your designer to draw the graph with each data point, merely a simple representation of what it will ultimately show.

For example, in your sketch, your first “chunk” of text reads “Widgets are taking over the world.” Let’s say you have data showing how 14 of the 20 most developed nations are using widgets more than thingamajigs. This is where you put more effort into data review than you do into illustration.

Remember, just because you say it doesn’t mean you can show it. Review your data to make sure the numbers support the claim.

Remember earlier when I mentioned that you’ll likely need to keep going back to your data to confirm that it supports your content? This is one of those times. Go over the data very, very closely and confirm that, indeed, the data does support your message. It’s one thing to say that most G20 countries use widgets more than thingamajigs, but how *much* more? Therein lies the rub, folks.

In a sentence, you can get away with throwing around words like “most” and “more.” But in a graphic, you have to illustrate that sentence and if the visuals don’t support the claim, you’ll have a disconnect–your headline says one thing but the data show another.

Here’s an example. Say that widget use is just barely eeking out a lead in each of the 14 G20 countries where widgets are used more than thingamajigs. Trying drawing a bar graph of the data. It won’t look very compelling–you’ll have 14 bars showing widgets and thingamajigs almost neck-and-neck. That’s fine, but remember that your message was “Widgets are taking over the world.” It seems hardly appropriate now, doesn’t it?

That type of examination is a phenomenal reality check to ensure that message and data support each other. Based on the above scenario, you can now revamp your claim (“Widgets gaining ground over thingamajigs.”). You can add more data and tweak your message (“Widgets gaining ground over thingamajigs–expected to double by 2020.”)

Format is everything. Next, have your designer explore the best format to show each graphic. If I’m designing something (depending on complexity), I might have my first sketch be two things–an outline of content and data findings along with concrete examples of how I’d like to design the data (e.g., a bar graph here, a piechart there, a map over there). Or, I’ll create the sketch in two passes: the first showing the content outline and using a barebones format for all graphics (e.g., I’ll use a barchart for everything and tell the team that later I’ll come up with the specific formats). If the infographic and data are simple, I’ll do both in one iteration.

Regardless, use the sketch as your opportunity to create (especially on the second iteration) graphics that are reasonable facsimilies of what readers will ultimately see. Format is everything. If you have 7 categories of percentages for one year and would like to show how those percentages changed the next year, it is probably not wise to put these data into two piecharts and ask people to compare change over time. So why draw that into the infographic? Draw it the way you’ll illustrate it (as two stack bar charts, or as a line graph that simply shows change in percentage over time, for example).

Annotate your sketch. Next, put in brief notes about each graph or illustration. For now, think of these explanations as easy to understand notes for your team and reviewers to help them understand the point or findings of each graphic (e.g., this graphic shows how sales of widgets will double over the next 8 years). Later, you can repurpose those notes as “chatter” that you incorporate next to each graphic.

And your designer will likely turn some of those annotations into visual elements. For example, for a graph that compares the cost of widgets to thingamajigs, you can annotate the graphic with the findings: “Widgets now cost half as much to produce as thingamajigs”. Your designer might see the word “half,” ask you what the actual number is (say, 53%) and create a design element around it. You never know where these bits of information will take you (that’s the designer’s job) but try to annotate each element with what you want the reader to remember or learn. This makes it easier for your team to understand the sketch and, again, can be turned into copy or design later.

You can use this same approach for illustrations–you can choose to either write in references to them quickly (e.g., draw boxes next to each graphic that say “icon of widgets will go here” and “country flags here”). Or you can illustrate them. I prefer to illustrate concepts that I’m not sure the team will understand–it forces the issue early and visually–and generally prevents me from spending time later killing myself over the design of an element that the team ultimately rejects.

Explore formats–static, interactive or other? I mention this close to the end of this section, but in reality you should, in the back of your mind, be evaluating the emerging sketch for possibilities that it presents for interactivity. You may have decided early on (due to budget, technical or time constraints) that you’re set on a static graphic. That’s fine. But recognize that certain stories and data lend themselves better to specific formats. Your sketch will allow you to determine the best format or, if you’ve settled on a format already, how to better present the information so that it is suited to the best format.

How do I choose the right format for my story and my data? I work with lots of 50-state data and 50-state maps, so–for me–this question comes up frequently. Here are a few examples that show you how your data can be shown in both a static and an interactive format, ranging from the simple to the more complex:

Let’s say you want to show widget use in the 50 states. You want to show:

  • -Which states have widgets today (this is a yes/no question).
  • -How widget use across the states has increased or decreased over the past 10 years (each state has a percentage associated with it)

You can create an infographic that shows this easily:

  • Create one map for “which states have widgets today” and simply color code the yes/no values (states that use widgets are green–those that don’t are read). Done.
  • Create a second map for “Increase/Decrease in Widget Use: 2002-2012.” Take the percentages in Excel, sort them from largest to smallest, and split them up into groups (for example, into thirds). Now you have a list of top third states, middle third states and bottom third states. Assign each category a color (top third = dark green, middle third = medium green, bottom third = light green) and apply those colors to your map. There’s your infographic.

But look at your data carefully. You have actual percentages for each state which you left out–you simply lumped those numbers into groups and color-coded the states. You could sneak in those percentages into each state (difficult to do depending on real estate and whether you want to also put state abbreviations into the map). Maybe you can use icons to denote specific values (e.g., the top 5 states). You can put callouts close to the map which talk about interesting states and their data. You could put a table with the data below the graphic. Or you could eschew the data altogether because it’s not important–lots of possibilities.

Whatever you do, the advantage of the above approach is that the information is sticky–people can compare two simple things on the screen at one time. If this is a priority for you, then static (in the example above) could be the way to go. It’s low-tech and concise, and easily allows users to compare two similar concepts.

But what if real estate is an issue? What if you do want to show more data (those percentages, for example)? And what if, for your audience, comparing side-by-side is less of a priority–the data is what you need to show?

Then you might be looking at an interactive that allows people to view one map in two ways (I’m oversimplifying here to make a point–there are many more possibilities). Give people a choice between two views: show me which states use widgets (map changes to green/red states). Now show me how widget use has increased/decreased over the past 10 years (map can show each state color-coded and when you mouse over you can see the percentages, for example. I almost hesitate to offer this example because there is so much more that you can do, but hopefully it’s helpful to see the difference, albeit over simplified.

Here’s another thing to consider: motion graphics. What if the data you have is a chart that is complex? You can split up the chart into several charts and spend considerable time explaining (annotating) each one, and (as important) writing about how one chart is related to the next one. Or…you can produce a motion graphic. These have been increasingly used lately (the New York Times is doing lots of them) and I’m not yet a huge fan of the treatment. Too many producers are essentially creating videos with a lot of talk and graphics that flit about the screen for effect. I’m a fan of what I call “explainers”–people who walk you through a complex graphic or set of data. Check out Hans Rosling’s video to see what I mean.

Because this post is about how to plan for visualizing information, not necessarily about the merits of static versus interactive graphics, I’ll stop here. I really haven’t done much justice to the complexity of the decision-making process. That’s for a later post. If you’re interested in reading more, Column Five recently wrote a nice article on interactives.

But I do want to point out that your sketch and planning conversations are exactly the right point to start the conversation about format. If you find yourself running out of room, explaining too much, or creating very repetitive graphics that show the same data in different ways, stop and ask yourself if you’re considering the right format.

Okay, you’ve got your sketch in hand and recommendations on format. Let’s move on to the final article in this series, which will explain how to share the concept to your team, manage expectations, and execute the rest of the design process.

 

One thought on “Building good infographics part 2: Know your data, know your story

  1. Pingback: Building good infographics part 1: Just because you can say it doesn’t mean you can show it. | viewtific

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>