Building good infographics part 3: Design and execute

December 16, 2012By carlainteractives

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 the second article, you learned how to bring together your data and your story into a solid sketch.

In this final part, I’ll cover presenting the concept to your team effectively, managing expectations, and executing the rest of the design process so that your designer doesn’t fire you.

Part 4: Pitch the concept sketch to your team.

Schedule another meeting. Buy more donuts. Bring your designer. Keep it low-key if you can.

Get buy-in and set expectations. Now is the time to present to the team. The nice thing about sketches is that they appear to be so informal that you can share them with people quickly–they allow you to reach out individually to take the temperature of the team if needed and make adjustments as you see fit. This iteration helps because, when you get down to the formal presentation of the sketch, you’ve already established a bit of buy-in (team dynamics permitting, of course).

Before you launch into the sketch, start with a step back to cover the major points from the kick-off meeting.

It may seem repetitive, especially if you just met a few days ago, but it helps ensure that everyone’s on the same page and, if not, identifies those issues quickly. There is nothing worse than launching into a presentation only to find out later that not everyone shares the same goals for the graphic.

Reiterate what you’re creating, who it’s for, how you expect they’ll use it, what they’ll likely want to hear, and how the graphic will support that. Sometimes, this is where things can really get bogged down. The meeting that you had a few days or weeks ago (you remember the one–everyone nodded and seemed to be in happy agreement) suddenly becomes a distant memory as stakeholders, faced with a concrete presentation and decision point, decide to begin reevaluating the goals, objectives and purpose of the graphic. Well, better now than later. When this happens to me, I’m grateful for it, to be frank. It’s pretty much a hallmark of busy teams (you can’t get them to focus until you have something in front of them) or new teams (those who haven’t worked together before, or who haven’t created data viz products before).

Sometimes the difficult conversations tell you more about the team than anything else. At any rate, it’s valuable.

If this happens to you, try to relax and take it in. Sometimes the difficult conversations tell you more about the team than anything else. At any rate, it’s valuable. It’ll give you a sense of the red flags to watch for later in the process. If the team is too indecisive, bring in senior managers, if you can, or summarize the issues they raise and simply state that decisions need to be made before moving further. Don’t be discouraged if you’re suddenly back to the drawing board. These things happen. A lot.

If the conversation is moving smoothly, it’s helpful to talk about the data.

Talk about the things that you expected to find that you confirmed (likely they’ll expect those things also). For example, “I knew that widgets were gaining ground in G20 countries.” And talk about the findings that surprised you. “We talked about widgets gaining ground in our report, but when we looked at more data we saw the lead as slight, which belied our key message. So, to soften this, we added data about projected use for the next 8 years and were able to keep the message of increased widget-use.”

Sell your stakeholders on the problems and solutions that you encountered before getting into the nitty gritty of a sketch.

In other words, ensure that you have shared expectations about the graphic, then sell your stakeholders on the problems and solutions that you encountered before getting into the nitty gritty of a sketch. It’ll inform them and give them good perspective as they review. This sounds like a lot, but it’s important. In my experience, it can take anywhere from a few minutes with an experienced team to more than an hour.

Now, show the sketch(es). Pitch your concepts. Listen. Get people excited. Be open-minded (or, hell, just fake it). Listen, listen, and listen. When you’re not listening, ask questions. Have your designer on hand to participate with you.

Weighing the impact of team recommendations on scope and timing. Once the show and tell is over, talk about the production and design cycles in a general sense and, if you’re able (you’ll have to think on your feet), how the group’s feedback might affect the schedule and scope of the graphic.

Don’t speak for the designer if the designer is not there.

Be careful here–particularly if the designer (for whatever reason) is not part of the conversation. Don’t make assumptions about how easy or difficult it will be to implement a particular suggestion. What looks easy to you may take a long time to illustrate. What seems like a no-brainer idea may not be supported by the data. What seems like a good suggestion may have cascading effects on the design that only the designer can spot. When in doubt, be noncommittal.

Part 5: Keep iterating.

Once you’ve had these conversations, you can keep iterating the sketch as needed. Easy peasy, right? Sure. I usually allow for about 2-3 iterations of a sketch. More than that, and I like to put in a hard stop to bring the team back together to ensure that we’re not going off track. Each iteration should be more refined and have fewer issues. If you find yourself or your team continually revising or revisiting the same things, this may not be a good idea to execute as a graphic.

Part 6: Start illustrating and designing. When do you move from paper and pencil to design?

For me, once the structure, content and data are mostly locked down (this is what we want to say, in this order, this is the data we want to show, and this is how we want to show it) it’s safe to move to design.

Before you start designing, confirm that the data is final. Really, really final. Your designer will love you, you’ll save time, and you’ll make fewer mistakes.
Once in design, keep your design cycles lean and tight.
Remember all the work you put into the initial presentation discussions? Keep referring to the commitments that your team and reviewers made in terms of who sees what, when and how they’re allowed to influence the graphic. (Good luck with that.)
Follow best practices. Don’t force your designer to unnecessarily embellish in order to add visual appeal.
Again, if you find yourself or the team going through too many edits, stop. Revisit whether this project is feasible.

Understand the nature of edits, who’s making them, and why. Too many edits can be a result of:

Too many writers involved (or the wrong people suggesting edits).
Team members brought in to give feedback who were not made aware of the original goals, audience and dynamics of the project.
People (including the designer or project lead) who lack the necessary skills or experience.
Not enough of an overall direction given to team about what the graphic needs to accomplish, for whom and why.
Decision-makers not focused appropriately enough to give careful feedback (I notice this a lot when working with people who are very, very busy. You might see a lot of edits and back-and-forth when these folks aren’t able to focus on the product as a whole, and consequently keep “catching” things with each iteration.
The data changes.
Rushed timing. Assumptions are made about how long an graphic will take to produce by the wrong people.
Wrong assumptions made about how “easy” it is to create a graphic from repurposed content.

Part 7: Lessons learned.

No matter how successful or unsuccessful your first efforts, you can learn from them. How you impart those lessons to your team is the subject of another post. But suffice it to say that you should keep a close eye on what worked and what didn’t, and get at least an informal sense from all team members involved in order to refine your process and your team for the next time.

Well, that’s it. Go forth, enjoy, and make things easy to understand for the rest of us. And be nice to your designers.

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

December 16, 2012By carlainformation

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.

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

December 16, 2012By carlainformation

Every few months, I receive a call or an e-mail asking me the same thing: I want to set up an inhouse infographics team/process that spits out all the cool data we have sitting around on the cutting room floor. My response is usually the same: grab a cup of coffee, sit back, and be prepared to walk away with more questions than answers. Inevitably, at the end of an hour-long conversation, I hang up the phone and walk away thinking–”oh, I wish I’d said that.” So, this post is prompted by all the things I wish I had said, and all the things I wish I had known as I was starting out. Apparently I missed a lot, because this article is divided into three separate posts:

Planning and team dynamics (this post)
Putting together data and story effectively into a solid sketch
Pitching your concept and executing a damn good graphic

After all that work, there’s gotta be a good infographic in there somewhere.

Often there are misperceptions about how “easy” infographics are to create–they’re often thought of as a quick way to piece together data from long reports or collections of data that “seem” interesting or “seem” to drive home a specific point.

Many times, the client, marketing or communications perspective is derived (understandably) from a key message that the client wishes to drive home. That’s understandable… we tweeted it, we facebooked it, we posted on google+… after all that work, there’s gotta be a good infographic in there somewhere.

As I’m sure you know, the devil is in the details and there’s no better place for him to stir up confusion than between a team of eager communicators and designers. To many, data visualization may seem like a relatively new type of product (the marriage of data, writing and technology), but the way to wrangle it is the old fashioned way–good communication. Much of this article is about just that.

Are you equipped with the resources to produce and/or manage data visualizations? Do your expectations realistically align with your resources? Before you embark on your project, ask yourself this: what does information design mean to your team?

Do you have writers and editors who understand how differently people consume static or interactive graphics? Do you have someone who can understand the data? Do you have a designer experienced enough to use best practices (no pie-charts showing 12 categories, please) when visualizing data and can push back when necessary? If not, do you have someone who is seasoned enough to be able to guide the designer effectively? As a designer, I can tell you that I’m embarrassed by my early (and ongoing) missteps as an information designer. And (to me) most important of all, do you have a good track record working as a team with your designers? A good track record isn’t as subjective as it seems. Can you build a good visual product? Are your stakeholders satisfied? Are your designers empowered to do their best work? Is your writing and design process flexible enough to be iterative but firm enough to avoid design by committee? The answers to those questions for past products can point to your success with new ones, such as information graphics, even if you haven’t yet been creating them as a team.

But we all have to start somewhere, and this post is as good a place as any.

Background before starting the process.

First, a bit of background for you before you bring your team together.

Audience, goals and outcome. Be aware of how your audience can (and will) shift as your graphic passes through different distribution channels (social media, blogs, more traditional marketing streams, etc.).

One of the first missteps (you’ll hear me mention this often) is to assume that the infographic is simply a larger or longer version of something you’ve already produced. It’s not. Who is the consumer of this piece? What types of graphics (interactive or static) do you think they typically read and pass on? Is there any content or style those graphics share? How does that information affect the tone and style of what you’d like to design (e.g., do you want to stand out or blend in)?

If you’re developing a graphic to promote a product, ask yourself how the consumers of your graphic may be different than those of the related products which you are promoting. For example, if you create a video to persuade engineers to buy your widget, you may consider your target audience to be engineers. But if you create that video and an infographic to promote it, and one or both go viral (blogs, Facebook, etc.), your audience has broadened–and changed. So should your approach.

Data visualization: What you want to say is not always what you’re able to show.

But knowing your message and understanding how it will change for different mediums won’t help if your team assumes that you can easily “lift” some core headlines and “repurpose” a subset of the data into a new graphic.

What works for the goose doesn’t always work for the gander–and visualizing data is no exception. A long piece of content (say, a web article) can have the luxury of nuance and a more complex message. Carrying that into an infographic can be impossible. What sounds compelling in 500 words can take on an entirely new meaning when boiled down to a few headlines. When a series of graphs are woven together to support a key message in a longer piece of content, they do just that–support the message together. But in an infographic, where often neither the attention span nor the space is there (and with a potentially different audience) you necessarily need to pare down both your data and your story. And when you do that, sometimes you find that the two don’t complement each other as well as they did in other products.

And sometimes the answer is no. This information does not make a good infographic. There’s no magic to this discovery–it can happen in the beginning or later in the process. But one of the things that I like to do is to use it as a checkpoint at each major step or whenever I hit a roadblock–why is this happening?

Did we hit a roadblock that can be solved (people, process, content, data or design)? Or is does this idea simply not support an info graphic/interactive?

One of the smartest things you can do is to approach messaging and data as a new animal that must be reconceptualized from the beginning, and not make assumptions about its feasibility.

This helps you avoid assumptions that will lead you and your designers down the wrong path–affecting your deadlines, your creativity, your product and your stress level.

So, steps to designing an infographic or interactive? Start at the beginning.

1. Rethink your audience, your message and confirm that your data supports it. Do your research–what are your competitors doing and who are they reaching out to? How do their infographics differ from their other pieces of content? You don’t have to copy your competitors, but you can learn from them.

2. Next, be prepared to invite the team to a kick-off discussion to settle on audience, purpose and expectations.

3. Review your data and make sure it gels with the content. Confirm that the graphic or interactive is feasible. Start working with your designer to make initial sketches of the graphic, and to begin determining format (static, interactive, motion, etc.). More on all of this later.

4. Pitch the concept with specifics.

5. Iterate, iterate, iterate.

6. Begin design and execute the design, editing cycle. Publish.

7. Learn from your mistakes.

Part 1: Kick-off meeting

Bring donuts, coffee, and call a meeting. Get your designers, editors, writers, researchers, and marketers at the table (try to keep this lean, but not so lean that major influencers will be left out). If you’re working with a small team, consider yourself fortunate–you’ll likely avoid the pitfalls of the dreaded design by committee syndrome. Regardless, keep reading to learn more about things to consider discussing.

“Should we even do this?” Start by reiterating that the the conversation will explore feasibility first, and that the questions you’ll be exploring will help you determine this.

Reality check: Should we even do this? Depending on the dynamics and size of your team, this is something you can tease out gently, or something you can start with upfront. It can be the hardest thing to say, because sometimes all or most of the people involved assume an infographic is a done deal. They’re simply waiting for you to tell them how to get it done.

What are you creating, for whom and why. Discuss what you’d like to create, who it’s for, how you expect they’ll use it, what they’ll likely want to hear (not what *you* want to tell them). A colleague once shared this with me (she uses it for her students) and I’ve been using it ever since:

(X product/project ) is an (X description of project) that provides (X What) for (X audience) in order to (X value proposition).

Talk a bit about the graphic’s relationship to other products (e.g., this is part of a package of [x]) and how the graphic will support that.

Discuss how the message, tone and style of the graphic are different (if at all) from other products, while at the same time reassuring stakeholders by bringing back those differences in support of the overall product package or message. If the audience, their needs and expectations (how they consume information through a graphic, how quickly people read and share on Facebook, etc.) are different from those of other products produced by the team, note how the graphic will addresses those needs. This (for me anyway) is a reliable way to acknowledge biases and preconceived notions while gently opening up the sky for more possibilities.

Once stakeholders get excited about a graphic, it can be easy for editors, writers and reviewers to get carried away with wordsmithing and micro-managing the designer (this is known as “design by committee”) and many designers would rather draw on hot coals than endure it. I’m kind of in the middle. You can’t always avoid it, but the more experienced you are the better you can side-step some of the pain.

Design by committee: If the stars align and you manage to hold on to your sense of humor and faith in the human race, you can turn the good intentions of micro-managers into useful feedback that is redirected to the appropriate stage of the design cycle.

Hopefully this article will help you avoid some of those pitfalls. As a designer who does a lot of hands on design and as a manager who manages other designers and consultants, I’ve experienced this from many angles. Though it’s not easy no matter where you sit, the better you handle expectations up front about reviewers, roles and design styles the more your designer will be free to add value and expertise to the process.

Avoiding design by committee: questions to ask regarding review and feedback.

If you think, for whatever reason, that your team thinks they can design your product better than your designer, you’re in for a world of hurt unless you begin managing the process at the outset.

The designer’s role. Who is your designer? Do you trust them? Do you feel that they understand you, your message, your brand and your audience? Do you really, really see them as adding value and expertise that you don’t have or, in your heart of hearts, do you secretly think: dang, if I knew how to use that funky Illustrator software, I could bang this out in an hour. I’m being serious here, folks. You really do need to assess the designer’s role and your perception of their skill set (and confirm your team feels similarly) because that’s where roles can break down. Things are the way they are. But if you think, for whatever reason, that your team thinks they can design your product better than your designer, you’re in for a world of hurt unless you begin managing the process at the outset. Good communication, respect for each person’s expertise and understanding of roles does wonders to establish trust. Work hard to get there and you won’t be sorry.

An informed designer is a good designer.

And don’t forget to to ensure that your designer is part of the larger conversations about the direction of the graphic–the more they know and hear at the outset, the better equipped they’ll be to do their best work when their time comes to design. And giving them multiple opportunities to learn the message, the data and ask questions will pay off in the end–a good designer is an informed designer.

Process and team roles. Who will be reviewing the graphic? Will they be sharing it with other teams or people? I can’t tell you how many times I thought I had a design nailed down when one of my reviewers comes back to me with more edits or comments (often good ones) because they share it with a (friend/manager/colleague) who wasn’t part of the process. Don’t get too grumpy about this–sometimes the outsider perspective can be invaluable–but ensure that it has a time and a place and that you’re aware of it. In other words, corral it up front.

What will each team member’s role be? A long time ago someone taught me the RACI model (Responsible, Accountable, Consult, Inform). Since then, I’ve used this concept to map out the (sometimes) difficult task of determining the various roles that reviewers and influencers have in a project’s life cycle (typically a content outline, a few sketches, a few design drafts and one or two final versions if you do it right).

Try to determine how much influence and decision-making authority each reviewer has, and work to ensure that they’re aware of it. Determine who has approval authority and how you need to work with them through the design cycle. Make sure they understand the big picture. Know up front (go ahead, ask them) if they will be weighing in on specifics (colors, fonts, commas, piecharts). Yeah, I know–that’s design by committee and they shouldn’t do that. But (reality check) sometimes they do and there’s not a damn thing you can do about it. If that’s the case (and hopefully you’re seasoned or lucky enough to know the difference) you’re going to have to do your best to manage it.

One person alone cannot, and should not, review and give feedback on everything. Group review assignments and delegate accordingly.

In my experience, infographic review is comprised of the following, usually iterated/produced in a series of drafts that grow progressively more refined along each of the points below:

Big picture stuff: message, tone/style (brand) and claims
Visuals: major things (look, brand, fonts) and the details (are things aligned, are the graphics built well)
Headlines and subtext: How well do the headlines thread together? Are they coherent? Does your supporting text (“chatter”) read well? Are graphic headlines clear enough so that if the reader doesn’t look at the graphic, they understand the major findings?
Quality control: Commas, spelling, fact checking

Which team members review content? Findings? Design comps? Who handles fact checking or quality control? Who sees every draft versus major drafts? Plan for it and work as closely with them as needed. Give them touchpoints for approvals. Others you’ll simply consult (hey, what do you think of this?). They may have opinions, but you’re not bound to to abide by those–simply to consider them. And others you simply inform. They need to be told (timing milestones, etc.) but aren’t there to weigh in on design. Trust me if you don’t already know this. Hone your diplomacy skills and try to set these expectations up front.

Design and timing. Next, talk about design and timing expectations for the graphic. Discuss products related to the graphic and how (or whether) the graphic should visually tied in to those. Make it clear that a literal one-to-one match in terms of colors, fonts and styles (depending on the product) is not always wise. Everything depends on the medium. For example, print uses different fonts and space/composition differently than online content. And interactives are designed differently than infographics.

And here’s another opportunity to set expectations up front. You want to discuss, at this point, the overall tone, look and feel (e.g., it should tie in to [x] brand/product, etc.) just enough so that later on, when the team is presented with a design, there are new things to show them but no major surprises (um, since when did we start using Comic Sans and magenta as a brand color?).

Build a rough schedule of the milestones. Allow for 1-3 rough drafts (sketches) and 2-3 (sometimes more) design drafts.

Think of the design cycle as an inverted pyramid. In the beginning, the number of reviewers will be many, as will the scope and quantity of edits and changes. In the end, it will be the reverse. Fewer (and more senior) reviewers and fewer changes that are smaller in scope. At the very end, you should have the designer and one person worrying about errant commas and moving a line or two by a few pixels. That’s about it.

Think of the design cycle as an inverted pyramid. In the beginning, the number of reviewers will be many, as will the scope and quantity of edits and changes. That’s okay, because you’ll be working with a document meant to accommodate this–content outlines and rough sketches. This is exactly where changes should occur–where the level of effort to make them will be the lowest.

I can’t say this enough. I wish I had invented the concept:

As you move forward with more detailed sketches and, later, illustrated design concepts, the level of effort to make changes will be higher. Thus, the number of people reviewing should be smaller (and perhaps more senior in the decision-making process) and the amount of edits and changes–as well as their scope–should be smaller.

Know when your data will be final, and plan accordingly. I can’t underscore this enough. Changing data can do just that–change. Everything. Your words, your scope, your design. Your sanity. Remember that awesome headline or tagline that rocked your world? Don’t get too attached to it if your data has changed. It’s a no-brainer, I know. Even though I’ve been doing this for a while, I can’t tell you how many times I get so excited by the design that I simply forget to nag the team about the data, only to learn that it has changed. And with it, the design concept that I was working so hard on. Life happens.

Plan for it and check in frequently with your team if you think this will be a possibility. For example, say you’re working on a story about widget use around the world. You review your data–awesome. Widget use is skyrocketing, according to data that you pulled for the past ten years. And last year’s data is coming out next week. So, in anticipation, you pull the team together, work up some sketches, move forward with designs, and leave a simple placeholder for 2012 data that you know is coming. Then you receive the data and–widget use has leveled off. Why? Well, not only does that require some explaining, but it also changes your story somewhat. You can prevent much of this from happening by talking, up front, about what the data is and, if you’re expecting more, getting good intelligence on what those numbers are likely to show. If you work in a company where numbers are your bread and butter–likely you’ll be surrounded by professionals who already know this. But if you’re embarking on this for the first time, keep that in mind.

Time to move on to the second article, where you’ll learn how to bring together your data and your story into a solid sketch that you can later present.