Skip to main content
Erschienen in:
Buchtitelbild

Open Access 2023 | OriginalPaper | Buchkapitel

Data Storytelling

verfasst von : Craig Starbuck

Erschienen in: The Fundamentals of People Analytics

Verlag: Springer International Publishing

Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.

search-config
download
DOWNLOAD
print
DRUCKEN
insite
SUCHEN
loading …

Abstract

This chapter provides best practices for effectively communicating to stakeholders with data. Topics include knowing the audience, implementing a status taxonomy for analysis documents, and various structural elements of analysis presentations (e.g., TL;DR, purpose, methodology, results, limitations, next steps, appendix).
Like chapter “Data Visualization”, this chapter leans more art than science in the coverage of strategies to translate results of analyses into compelling stories that have a high probability of landing effectively with target audiences. One may build an impressive set of complex models and perform robust analyses, but unless the results and recommendations are clear to stakeholders, this is an exercise in futility. We need stories to distill analytical output down to a non-technical and logical organization of unified ideas that arouse the energy and attention of the audience.

Know Your Audience

First, we must remember that we are communicating for the audience, not for ourselves. To do this effectively, we need to know the audience—what is important to them (e.g., making money, reducing expenses, gaining market share, innovation) and how they define and measure success. Knowing what matters to those we seek to influence with information enables us to tailor content in a way that appeals to the unique needs of those who can ultimately authorize action and drive change.
A unique challenge for people analytics practitioners is that the audience is often non-technical folks in the people organization. The strategies needed to communicate effectively to this audience are quite different from those required to present an analysis to Finance, for example. Using technical jargon is a sure way to quickly lose a non-technical audience and sacrifice what could otherwise be a poignant and impactful call to action. Therefore, it is critically important to identify and understand the target audience before packaging and delivering results.
In general, it is best not to assume the audience knows what you know because chances are good that no one else has been as deeply immersed in the problem as you.
Several contextual questions are important to consider:
1.
What essential background information does the audience already have, and what additional context needs to be shared?
 
2.
Does the audience already have access to any relevant data that would strengthen or conflict with the messages we need to convey?
 
3.
Does the audience or decision maker have a known perspective on the topic?
 
4.
How should the content be messaged to proactively appeal to potential risks or biases the audience may possess that could create resistance to the findings and/or recommendations?
 
5.
What is the audience’s preferred format for content sharing (e.g., document vs. deck)?
 

Production Status

Prior to documents or decks being circulated to the target audience, there are generally several revs to refine the content and storyline in partnership with internal analytics colleagues and other stakeholders. If working docs are shared prematurely, it can result in the analytics team needing to address unnecessary questions that may compromise the project scope and timeline. Stakeholders will naturally have questions and ideas for further exploration, and we should always value their engagement and enthusiasm for more insights. However, unless there is a critical business need to venture down another path, the analytics team must protect the project scope and cite in the presentation the need to prioritize the additional analyses as a next step.
It is important to define a production status taxonomy to clarify content readiness. The framework below is one example:
1.
Draft: Working document/deck being prepared by the analytics team (do not share)
 
2.
Initial Review: Document/deck suitable for initial input from stakeholders
 
3.
Final Review: Document/deck reflects feedback from initial review and ready for final review and sign off
 
4.
Complete: Document/deck complete and ready for delivery to target audience
 

Structural Elements

Entrepreneurs pitching to VCs craft a concise elevator pitch that highlights the key features of their product or service complemented by data to support the unique value proposition and attractive upside of the business (e.g., market size and penetration, revenue growth trajectory). In the same way, a good early step in storytelling with data is drafting a short story and iterating on it until only the essential content remains and it requires no more than a few minutes to read.
When preparing a presentation, a general rule is to never begin with slides. The aesthetics and formatting are of secondary importance to the organization and sequencing of content. Begin by outlining the structure and organizing content in a way that supports and punctuates the key messages you wish to convey to the audience. The outline can then be translated into a presentation-ready deck or document, which will support a logical and effective flow of information.
While the structure and format may vary company to company, and across stakeholder groups within a particular company, there are some essential elements that will support the effectiveness of an analysis presentation.

TL;DR

A TL;DR (too long; don’t read) is an abstract intended to provide a concise synopsis of the research objective, high-level approach, key findings, and recommendations and next steps. The TL;DR is popular among tech companies, though the general idea is embraced by organizations in other industries under various names (e.g., Executive Summary).
Here is an example of a TL;DR for an analysis intended to support a solution to an organization’s location capacity issue:
Based on our strategic workforce plan, we will exceed the capacity at our HQ facility within three years. Labor market analyses indicate that by expanding our remote workforce, we can source from a larger pool of talent with the skills we need to maintain our competitive position in the market, decrease our average time to fill positions, lower our average cost per employee, and solve for the impending capacity breach at our HQ facility. A shift to remote-first hiring is recommended over the next six months to proactively address both our strategic workforce needs and location capacity constraints.
This short TL;DR led with the problem statement, highlighted a solution and associated benefits based on the analysis, and finished with a recommended next step and timeline. While this short summary does not provide the intricate details of the analysis, in most cases, it should be sufficient to communicate the high-level story to those with limited time. This short summary may also function to pique the interest of stakeholders who are initially unsure if the analysis warrants their time and attention.

Purpose

Studies show that our audience determines in 3–8 seconds whether or not to give us their attention based on what we have put in front of them (Knaflic, 2015). Therefore, it is crucial to let the audience know upfront what we are going to share with them and why it matters.
There is perhaps no more important initial question to answer than “what does a successful outcome look like?” To answer this question, we must be able to clearly articulate the problem statement. That is, why is it important to perform this analysis over the many other analytics opportunities aging on the team’s backlog?
If we cannot clearly articulate the problem statement and desired success outcome(s), the audience will likely be unclear about what we are asking them to do and why they should make it a priority. All content and messages should support what we want our audience to know or do; therefore, defining what success looks like is a prerequisite for outlining and structuring the presentation.
While the problem statement need not be dramatized, this is an excellent opportunity to arouse an emotional response that hooks the audience. Consider the following approaches to articulating the same problem statement:
  • Option 1: Our offer acceptance rate (OAR) has declined from 80% to 40% YoY in Engineering.
  • Option 2: To deliver on our strategic workforce plan and support our ambitious product roadmap, we need to attract the best and brightest Engineering talent. However, an increasing number of Engineering candidates are declining our offers (OAR has declined 50% YoY), and this presents a material risk to the guidance issued to shareholders during our most recent earnings call.
The severity of the situation is far more palpable with the framing in Option 2 relative to the terse and factual approach taken in Option 1. As a result, it stands to reason that Option 2 features a higher likelihood of the audience taking seriously subsequent content which supports a solution to this problem.

Methodology

It is usually appropriate to provide a high-level overview of the analysis approach. In doing this, it is important to know what level of information is appropriate for the target audience.
It is easy to provide too much information in this section. For example, does the audience need to know that we built a multilevel model with quadratic terms on time variables? If the People team is the target audience, there is a good chance that this level of information is not appropriate. Sharing that an analysis method was used that is well-suited for understanding drivers of the outcome being studied is likely sufficient, as the content and presentation should index more on the findings and recommended next steps than on methodological details.
Presenting results of analyses to a non-technical audience using technical nomenclature will at best be seen as hubris and create confusion; at worst, the important information you need to convey will be completely lost on the audience and the efforts to improve the employee experience will be a deplorable miss. In general, if information is included in the presentation, we should ask ourselves whether the audience really needs to know it. If the key points are likely to land without the information, eliminate the superfluous material. To paraphrase a quote attributed to Einstein: “Everything should be made as simple as possible, but not simpler.”

Results

Just as the methodology should not be presented to stakeholders on the People team using technical nomenclature, results of statistical analyses also need an appropriate translation for the audience. If you are operating in a tech company, it is possible that terms like modeling and n-count are broadly understood. This is again a case in which it is critical to know your audience to ensure the key messages resonate based on their knowledge, vernacular, and delivery preferences.
Tables containing the output of regression models, for example, should not be included in the main body of the document or deck. As we covered in chapter “Linear Regression”, regression lends to a highly intuitive interpretation—assuming relationships between predictors and the outcome are not modeled using complex transformations. Therefore, we can speak to the results using language such as:
“When controlling for alternative influences such as X2Xp, the average change in Y  for each one-unit increase in X1 is β1. The association between X1 and Y  is statistically significant.”
By replacing X2Xp with the names of control variables, X1 with the name of the main predictor variable, Y  with the name of the outcome variable, and β1 with the corresponding numerical for the average change, we do not need statistical symbols or technical jargon to communicate high-level results of regression analyses.
If data are visualized, this does not require them to be included in the ultimate doc or deck presented to stakeholders. Myriad visuals are often generated during the EDA phase of analytics projects to understand distributions, relationships, differences, density, and trends, but relatively few –and sometimes none– need to be shared beyond the project team.

Limitations

This is the section in which the limits of the study should be made known to the audience. There are limits to every study –even the most rigorous– and the failure of a researcher to report them does not change this fact.
Outlined below are some questions to consider in identifying limitations:
1.
Does the research design support causal effects?
 
2.
Were there confounding variables that may have compromised the internal validity of the research?
 
3.
Were there data quality issues that may have biased results?
 
4.
Was low participation a factor, and could feedback from nonrespondents materially change the results?
 
5.
Is the observation window in which data were collected recent enough to reflect current sentiments and behaviors?
 
6.
Were mitigating factors implemented to control for social desirability?
 
7.
Were strategies deployed to mitigate the risk of common method variance for self-reported data collection?
 
8.
Were employees incentivized to participate, and could this have influenced their responses or performance?
 
9.
Were data dimensions standardized and consistent across time, or were data imputation and/or mapping strategies required to support longitudinal analyses?
 
10.
Did time constraints require curtailing the project scope?
 

Next Steps

Presentations should conclude with recommended next steps that are likely to generate a productive and action-oriented dialogue among the stakeholders. Assuming there was a firm commitment to action at the outset of the project (see chapter “Getting Started”), there is a good chance the audience does not understand what was shared or is not sure what to do next if their only response following the presentation is, “That’s interesting!” Leaving the audience with clear answers to the following questions will help drive accountability for action:
  • What are we asking the audience to do based on the findings?
  • What are we –the analytics team– committed to doing as a next step (e.g., working with operations teams to improve data quality for future analyses, pre/post study on the efficacy of proposed interventions)?
  • When is an appropriate time to follow up to help remove any barriers to action taking?

The Appendix

Given the significant time required to wrangle, model, and analyze data, it is often tempting to include in a presentation details associated with every aspect of the analytics project of which we are so proud. However, nonessential details will likely detract from the key messages we wish to convey.
Including in the Appendix of a document or deck information that is superfluous to the main points ensures the details are available should they be needed in addressing the audience’s questions whilst ensuring the audience is focused only on the most important elements of the presentation. This may be tables containing metrics across various dimensions or results from supplemental analyses adjacent to the primary research objective(s).

Q&A

It is important to reserve time and be prepared for Q&A with the audience when delivering a live presentation. Despite our most earnest planning efforts, the likelihood is low that even the most effective presentations will address all the questions our audience has. Addressing questions or concerns in the moment, or by way of follow up in the case of an asynchronous review of a doc or deck, will increase the probability of action being taken on the recommendations.

Review Questions

1.
Based on research, how long do we have to convince an audience that what we plan to present is worth their time and attention?
 
2.
Why is there no one-size-fits-all approach to storytelling with data?
 
3.
What are some early contextual considerations as it relates to understanding the target audience?
 
4.
What is the utility of preattentive attributes in storytelling?
 
5.
What are some strategies for organizing and structuring content to support compelling narratives?
 
6.
What is a TL;DR, and what is its purpose?
 
7.
Why is it important to clearly define success?
 
8.
What are some features of an effective conclusion that supports accountability for action?
 
9.
What are some common limitations in people analytics projects, and why is it important to note them when presenting results of analyses?
 
10.
What are some examples of content that should be moved to the Appendix?
 
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://​creativecommons.​org/​licenses/​by/​4.​0/​), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Literatur
Zurück zum Zitat Knaflic, C. N. (2015). Storytelling with data: A data visualization guide for business professionals. Hoboken, NJ: Wiley.CrossRef Knaflic, C. N. (2015). Storytelling with data: A data visualization guide for business professionals. Hoboken, NJ: Wiley.CrossRef
Metadaten
Titel
Data Storytelling
verfasst von
Craig Starbuck
Copyright-Jahr
2023
DOI
https://doi.org/10.1007/978-3-031-28674-2_16

Premium Partner