avoid unforced errors
Coincidentally timed with the Australian Open, I’ve been playing a lot of tennis lately. It’s a sport I enjoyed in high school (mixed doubles was my primary event), but haven’t played consistently since. When I do play, I still have fun, but—likely due to my intermittent participation as an adult—I’m not particularly good. I understand the mechanics, but can’t always execute them beautifully. If I step back, though, I have started to see some general improvement due to my regular practice as of late.
A thought struck me on the court recently: there is an interesting similarity between playing tennis and designing graphs and slides.
When my partner misses a shot, I can clearly see the issue. He was too close to the ball, didn’t move his feet, or his racquet was facing down. Unfortunately, while pointing out his issues is easy (in my head, I try not to say them out loud), knowing how to adjust and not make the same mistakes myself is more challenging.
A similar phenomenon happens with graph and slide design. When you see someone else’s graph or slide, it’s easy to point out where they’ve gone wrong. Too many words, too much color, the point is unclear. Even knowing this, it’s not always so straightforward, however, to not stumble with the same missteps in our own work. Here, as in tennis, we may understand the mechanics, but we can’t always execute them beautifully. Moreover, just like tennis, practice helps.
Let’s consider a concrete example. Imagine you work for an advertising agency and have been asked to assess a recent six-week ad campaign for a client. The data you are focusing on is “incremental reach,” which you measure per 1,000 impressions. You have a colleague who did a similar analysis for another client recently, so rather than start from scratch, you’ve updated his visuals with your data as a starting point. From here, you plan to edit and refine. Here is the slide you’ve created:
Make an assumption about whether you will talk through it live during a meeting with your client or send it to them to review on their own. In light of the way you plan to use the slide, what improvements would you make?
Hold onto your thoughts—there are a couple of upcoming opportunities where I’ll invite you share them:
Tuesday January 24th 1PM–2PM ET: slide makeover practice session. Join me virtually for an engaging, hands-on session. I’ll share my top 5 slide snafus and what to do instead, plus guide participants to make over the preceding less-than-stellar slide (and show how I would approach it!). This is open to premium members in the SWD community (bonus: we’re offering special perks to those who sign up for premium before January 31st!).
February #SWDchallenge. Stay tuned for the upcoming monthly challenge in the SWD community, which will also focus on this example. We’ll provide the data so you can makeover the slide, share in the community, and exchange feedback with others on their redesigns. I’ll share mine then, too! (In the meantime, consider tackling the current challenge, which is to visualize your quantified self.)
If the preceding example looks familiar, it may be because it was drawn from Exercise 5.6 in Storytelling with Data: Let’s Practice! (modified slightly for use here). That book, by the way, is an excellent place to turn for guided practice to refine your data storytelling skills. Also check out the exercise bank in the SWD community. Happy practicing!
