Visualizations 1

When I started as a research assistant many moons ago, the head of the research department at my old job, explained:

Every chart must be completely self-explanatory.  If the piece of paper that the chart is on was lost and separated from everything else, and a complete stranger found it on a public bus two years from now, that stranger should be able to figure out exactly what the chart means.

Tall order.  But even with the explosion of visualization technology we have today, the same expectation applies – the point of the chart is to communicate information efficiently, clearly and responsibly.  And that is what this series of posts is about. 

Before we get to actually pulling tables and graphs together, we need to start at the beginning.  Here are some things to consider before you start:

• What do you want your audience to learn from the table or graph? What is the story you want them to walk away with?
• Is a table or graph the best way to communicate your ‘story’?
• Are your data squeaky clean and ready for prime time?

Even after almost 30 years of crunching data, I still start my tables and graphs the same way.  Once all of the analytic work is done and I know what I have learned from the data, I sit with my head in my hands and a blank piece of paper in front of me.  All I want to figure out is how to ‘tell the story’ of what I learned.  That should be easy, but it isn’t.  And then I start to scribble.  A couple scribbles from one of my head-in-hands sessions are shown here, just for fun.

After I know what needs to be said, I start building the data presentation.  Sometimes I continue to work on paper for some time and only turn to the computer once I am finished.  Other times, I go straight to the computer after sketching a few ideas out. Don’t get worked up about doing drafts, expect it. Things get better when you work on them.

Another thing to keep in mind is your audience. For someone who has worked with statistics all her career (and I suspect financial experts are like this, too), graphs are nice, but typically pretty uninformative. Give me a good table any day. It not only tells the story that a well-designed graph does, but it has enough information that I can double check the story with some quick math, and maybe find some additional substories.

 

Further, sometimes a single table can replace six graphs and tell the story much more effectively.  Other times, the opposite is true.  Take the pie chart example below from my own work.  It tells a much cleaner and quicker story than a table would.  So it is important to use tables and graphs judiciously, keeping both your audience and your message in mind. 

A couple things still slip me up:

If my presentation is confusing and complex, usually my thinking is still muddled.  In that case, it is better to spend time getting unmuddled than continuing to play with the presentation.  

If the type of table or graph I am struggling with is new to me and I am not sure if I am being clear, it is helpful to look through journal articles or online for a similar data presentations for inspiration.

Finally, we are often under time pressure.  The result is a poor presentation and a confused audience.  Or worse, they are misled – the worst sin an analyst can commit.  This does not help anyone.  My strong advice is to clear your desk and give your presentation the time it needs to be done right the first time.  Hurrying does not save time.  Or, as my wonderful old boss would say, ‘Quick and dirty usually just means dirty. Don’t succumb!’

 

---