A few weeks ago, I posted a lengthy three-part series on building good infographics. To kick off the new year, here’s an infographic that I designed to illustrate the key concepts of that series. Enjoy!
A few weeks ago, I posted a lengthy three-part series on building good infographics. To kick off the new year, here’s an infographic that I designed to illustrate the key concepts of that series. Enjoy!
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.
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.
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.
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.
Understand the nature of edits, who’s making them, and why. Too many edits can be a result of:
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.
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.
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.
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:
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:
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:
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:
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:
You can create an infographic that shows this easily:
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.
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:
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.
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.
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.
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:
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.
A friend recently asked me, “how do you choose the right chart?” I thought about it, and essentially sent her a list of the sites that I have bookmarked, along with a few comments. This is by no means an exhaustive list, and it’s meant more for a layperson, but here’s the list, nonetheless. If you have more suggestions, I’d love to hear them.
I’ll follow up with a future post illustrating a few of these, and summarizing best practices and my experiences (a post which my toddler recently published in draft form–word to the wise, never let your toddler near your blog
In the meantime…
Limited to basic charts but half the time, that’s all you need.
For more traditional graphic designers (not coders) seeking to make the move to data visualization and understanding both the mechanics and the theory behind visualizing information, a crash course in handling data in Adobe Illustrator is helpful. Lots of terrific designers never get the chance to interact with data in Illustrator, so that’s not unusual.
Many Eyes: Many Eyes was developed by IBM labs. It’s a phenomenal tool for quickly visualizing a ton of information in a few seconds, without spending much time on having to learn how to format the data. Just copy/paste from Excel and you’re set. To start, first create an account. Then on the left under the “participate” heading, choose “create a visualization.” That takes you to the “upload data” screen, into which you can simply paste in your data. Then in that same screen go to step 4 (you can ignore the rest) and give your data a title (e.g., “test). Hit “create” to go to the next screen. Click the “visualize” button and then choose a format (bar chart, etc). What’s great about this is that each format has a “learn more” button, which explains in simple terms what each graphic type is best suited to do. At any rate, once you’ve chosen a format, you can see what the viz looks like. At that point, I just take a screenshot and exit, because I don’t wish to publish the data—I just need help with visualizing it. But you can click “publish” to do so.
Tableau: The “Tableau public” version is free, though you do have to publish what you use, I believe. There is definitely a learning curve to understanding how to format the data–different than Excel and not intuitive if you’re expecting an Excel experience. But very powerful once you get the hang of it.
The Guardian’s list on free data visualization tools: This article by the Guardian also mentions the above and a few other tools, most of which I’m sure you know about (Google maps, Google Fusion tables and Google charts) but also a few others that I haven’t tried.
There are three absolutely phenomenal articles by Enrico Bertini.
Many designers choose to export data from Excel into Adobe Illustrator’s charting tool. A few months ago, we found ourselves scratching our heads over a request that we received. The internal client had lots and lots of data on personal income and wanted to show this data as a scatter plot graphic, divided into quintiles. They had already created a basic version of this graphic in Excel, but needed the designers to redesign it to make it easier to understand and to add the visual polish and presentation for which design software is better suited.
We took a look and determined that our biggest task was simply learning how to create a scatterplot graphic that could handle the large volume of data the original Excel file contained–1,043 rows of data.
Our goal: Show intensity and data patterns across five categories (quintiles). Keep the data “live” in order to be able to quickly update the graphic with new data.
Our approach: Use Illustrator’s scatter plot tool to graph the data. Customize the graph to create a heat map in order to show intensity/concentration of data.
Our tools: Adobe Illustrator’s graph creation tool and Illustrator’s transparency settings to create a heat map
Take a look at the graph below. I recreated something similar to that which my team designed (update: because we haven’t yet published the data, this graph shows widgets instead of the subject matter of the original graphic). This hypothetical graph shows costs of production (money) spread out across four categories (quartiles)–a bottom quartile, a second quartile, a third quartile and the top (fourth) quartile. The darker the color (the heat map effect) the greater the intensity of those data. In other words, where the color is darkest represents a large number of widgets that with that cost of production. Where it is lightest represents a smaller number of widgets with that cost of production.
Needless to say, we learned a lot about Illustrator’s scatter plot capabilities in six hours.
Before I begin, I’m assuming a basic level of understanding with Illustrator (we were using CS5, but I believe all CS levels should work for this example) and its graph creation tool. If you’re not, search for Illustrator graphs and you’ll find plenty of tutorials. Better yet, FlowingData has a good basic tutorial on Illustrator graphs here. And so does Adobe. If you’re a designer, you probably already know the basics.
To better explain all of this, let’s first start by building a more basic graph, a scatter plot graph.
As you can see from the example above, the graph contains four category rows (labeled “Category 1,” “Category 2,” etc. In the real world, these categories could be years, quartiles or however you wish to divide up your data. Each category shows a row of data points associated with it (Category 1 shows a gap in the values between 6 and 15, for example). Keep an eye on Category 4′s outlier, the number 20 in the top right. More on that later.
Half the battle is learning how to enter or import this data into Illustrator. Essentially, think of your data as a series of columns that alternate. The first column has your “Y” axis values (your categories); the second column has your “X” axis values (the data associated with each category).
In my example, for Category 1 to appear first on my “Y” axis, I entered“1” in the first column (repeating “1″ as many times as I had data for that category). In the second column I entered all the data associated with Category 1. Repeat, and you’re all set.
Take a look at these first two columns in the data table to see how simple this is: [FIGURE 1].
As a final step, once you are finished working in the data table, click the checkmark button in the top right corner to output the graph. Then right-click on the graph itself and select “Type” from the menu. From the resulting “Graph options” dropdown in the dialog box, select the “Value axis.” In that dialog box, make sure that “Override Calculated Values” is checked. This is how to format your values for those fields:
Here’s the resulting graphic that Illustrator will produce at this point (I added the color manually). The blue row in the graphic represents column 2 in the data table. Remember: the reason Illustrator knows to put those blue points under the row labeled “1″ is because you labeled them as 1s in column 1 of the data table. You can later change the name of that row from “1″ to “Category 1″ (as an example) in the graphic itself. [FIGURE 2]
As an aside, if you’re not familiar with scatter plot graphs, here’s a quick explanation of how to interpret this one. Take a look at category 4 (it’s the green square in the top right of the graph shown in Figure 2, in the data table in Figure 1 it is the last column). Do you see how Category 4 has ten values, each numbered as 20?
But on the scatter plot graph, you only see the number 20 represented once (green square). Scatter plot graphs won’t show you data points when they overlap exactly–a line graph will, however. Here’s the same data in a line graph. Category 3 (green) now shows you each data point that is numbered as 20. [FIGURE 3]
Back to the scatter plot graph, you can customize the labels in the graphic itself once you’re finished with the data view. For example, you can change the category numbers from 1,2,3 and 4 to specific category values that reflect how the data is actually organized (e.g., by quartile, by year, etc.). More importantly, you can customize further with fonts, colors, stroke widths, etc., some of which Illustrator will retain if you return to data view and change the data. Which ones, you might ask? That’s a post for another day. [FIGURE 4]
You can create a graphic that looks like this (this is not real data, of course): [FIGURE 5]
Here’s a look at the data. You’ll notice that the setup is identical to the basics that I outlined earlier. The figure below shows you a snapshot of how each row is set up. [FIGURE 6]
I promised you a heat map, and here it is. Remember that a heat map essentially shows areas of concentration (or lack thereof) in data–intensity.
To show intensity for those data points that overlap (like the repeated series of 20s that I mentioned in Figure 2), simply select *all* the points in a category with your direct selection tool. (If you’re familiar with the “Select Similar” feature in illustrator, use your direct selection tool to choose just one data point, then choose use the “select similar” feature to automatically select all of the points in that row.) Then apply transparency to them all at once. Because transparency has a cumulative effect when layered on top of something else that is transparent, you are essentially creating a heat map effect. [FIGURE 7]
Well, that’s it. Please let me know if I’ve left anything out. Remember, this tutorial is meant to show how to customize Illustrator’s scatter plot graph tool. Just because you can, doesn’t mean you should! Once we publish the actual graphic, I’ll post that as well.
Came across an interesting post by Andy Kriebel on pie charts. He essentially deconstructs the decision-making process around how to choose the right format for showing change in a few variables over time. Sound simple? Yes, then no. What starts out as a simple exercise…
…turns into a practical, instructive seven-step journey through different formats. As designers, we’ve all been through this process of trial-and-error, pros and cons. But it’s very helpful to see the breakdown of what you gain or lose by each format.
It’s pretty clear (at least to me) that the consensus is this: pie charts are good for one thing, and one thing only: showing the relationship of the parts to the whole. They are not good for showing a gazillion slices of data–they are good for showing two. Or three. They are not good if they make you squint. And they are useless for an apples-to-apples approach.
And donut charts? Forget about it. The white circle in the middle makes it impossible to see where the angles meet, undermining a user’s attempt to size up slices and make comparisons. EagerEyes cites research showing the readers focus on the center, where the angles are formed and the lines meet.
As EagerEyes points out, human beings are terrible at gauging anything other than 90 and 180 degree angles–we can discern halves and quarters but beyond that, not so much. That’s where bar charts and other formats come in. Stephen Few tells us to save pies for dessert.
(Pssst… I’m still going to make donut charts now and then. They’re pretty.)