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:
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.