As an Engineer, I am often confronted with presentations that attempt (sometimes more successfully than others) to tell a story using data. As a rule of thumb, I generally prefer the “KIS” method – keep it simple, when presenting to any audience that is not entirely comprised of subject matter experts on the information. Additionally, overly convoluted presentations can leave even the most expert team members confused, resulting in too much time spent explaining the charts and not enough time explaining the meaning behind the charts.
In Jim Stikeleather’s article “How to Tell a Story with Data” published in the Harvard Business Review, I think he makes a few good points with which I agree. The following are a few of his points that I think we can all learn a thing or two from:
- Find the compelling narrative. Along with giving an account of the facts and establishing the connections between them, don’t be boring. You are competing for the viewer’s time and attention, so make sure the narrative has a hook, momentum, or a captivating purpose. Finding the narrative structure will help you decide whether you actually have a story to tell. If you don’t, then perhaps this visualization should support exploratory data analysis (EDA) rather than convey information. However, for the designer of an exploratory visualization it is still important to spark the viewers’ imagination to encourage examining relationships among and facilitate interacting with the data – think gameification.
- Think about your audience. What does the audience know about the topic? Is it meant for decision makers, general interested parties, or others? The visualization needs to be framed around the level of information the audience already has, correct and incorrect:
- Novice: first exposure to the subject, but doesn’t want oversimplification
- Generalist: aware of the topic, but looking for an overview understanding and major themes
- Managerial: in-depth, actionable understanding of intricacies and interrelationships with access to detail
- Expert: more exploration and discovery and less storytelling with great detail
- Executive: only has time to glean the significance and conclusions of weighted probabilities
- Be objective and offer balance. A visualization should be devoid of bias. Even if it is arguing to influence, it should be based upon what the data says–not what you want it to say. Tufte found numerous charts that misled viewers about the underlying data, and created a formula to quantify such a misleading graphic called the “Lie Factor.” The Lie Factor is equivalent to the size of the effect shown in the graphic, divided by the size of the effect in the data. Sometimes it is unintentional-a number that is three times bigger than another will be perceived nine times bigger if represented in 3D. There are simple ways to encourage objectivity: labeling to avoid ambiguity, have graphic dimensions match data dimensions, using standardized units, and keeping design elements from compromising the data. Balance can come from alternative representations (multiple clustering’s; confidence intervals instead of lines; changing timelines; alternative color palettes and assignments; variable scaling) of the data in the same visualization. Maintaining objectivity and balance is not a trivial effort and is easily unintentionally violated. Viewers and decision makers will eventually sniff out inconsistencies which in turn will cause the designer to lose trust and credibility, no matter how good the story.
- Finally, Edit, Edit, Edit. Also, take care to really try to explain the data, not just decorate it. Don’t fall into “it looks cool” trap, when it might not be the best way explain the data. As journalists and writers know, if you are spending more time editing and improving your visualization than creating it, you are probably doing something right.
