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.