Some Takeaways from Effective Data Storytelling

Communication

Author

Alex Zajichek

Published

January 14, 2023

I’ve been reading through the book Effective Data Storytelling: How to drive change with data, narrative, and visuals by Brent Dykes and just wanted to document some thoughts/takeaways.

1. Importance of domain knowledge

One of the biggest (and obvious) takeaways is the importance of domain knowledge is being able to craft an effective data story. You can have all the technical skills in world (e.g., math, statistics, programming, etc.), but if you aren’t able to relay that back to how it can impact things people care about, in simple terms, you’ll have trouble getting buy in. Thus, it is essential to be able to (i) acquire business knowledge and intuition for yourself, (ii) asking the right questions, and (iii) have subject matter experts (SMEs) who can partner with you to problem solve together. Domain knowledge is also incredibly important in the technical aspects as well (e.g., construction of useful statistical models generally requires assumptions about the context of the problem you are solving).

2. Organizational culture and support

I think in order to put data professionals in a position to be able to craft effective data stories, there needs to be some level of forethought into the data culture and structure of the organization. Just from a logistical perspective, it would be very difficult for someone to be able to take the necessary time, delicacy, rigor and sophistication needed to truly create an effective data story (e.g., using the right data, in the right analysis, with the right methods, with the right communication of results) without the support of foundational data infrastructure, data governance, process/project management, defined roles/responsibilities, overall strategy, etc. These things should be in place (or at least working towards it) to be able to apply the appropriate amount of rigor and detail required in an efficient and timely manner.

3. Tailor communication of results to your audience

I often build analyses in the form of HTML documents (via R Markdown) where the intention is to lay out a story of the data in a particular order, such the the end-user would read through the document on their own to gain the messages of the analysis with interactive figures and tables (I believe the idea of “scrollytelling”). However, I would often get asked by stakeholders to instead present/explain the material for them instead of them (understandably) reading through the whole thing on their own. So I would attend a meeting, bring up the document, and begin walking them through the document. I quickly found that this didn’t work. The intention of the document was to be read, not presented, and so people would get bogged down/distracted by the narrative in the document while presenting. It just felt uncomfortable. This is exactly something that is talked about in the book of what not to do. So, before sharing with stakeholders or presenting, I started converting the information in the document into a slide deck, pulling out the most useful information that was tailored to the way I would present it. Also, recreating graphs, tables, and/or figures that point out just the most pertinent data, instead of using the exhaustive summaries built in the exploratory analysis. These strategies proved to be much more effective and satisfying both for myself and the stakeholders.

--- title: "Some Takeaways from Effective Data Storytelling" author: "Alex Zajichek" date: "1/14/2023" image: "feature.png" categories: - Communication format: html: code-fold: true code-tools: true --- I've been reading through the book [_Effective Data Storytelling: How to drive change with data, narrative, and visuals_](https://www.effectivedatastorytelling.com/) by Brent Dykes and just wanted to document some thoughts/takeaways. # 1. Importance of domain knowledge One of the biggest (and obvious) takeaways is the importance of domain knowledge is being able to craft an effective data story. You can have all the technical skills in world (e.g., math, statistics, programming, etc.), but if you aren't able to relay that back to how it can impact things people care about, in simple terms, you'll have trouble getting buy in. Thus, it is essential to be able to (i) acquire business knowledge and intuition for yourself, (ii) asking the right questions, and (iii) have subject matter experts (SMEs) who can _partner_ with you to problem solve together. Domain knowledge is also incredibly important _in_ the technical aspects as well (e.g., construction of useful statistical models generally requires assumptions about the context of the problem you are solving). # 2. Organizational culture and support I think in order to put data professionals in a position to be able to craft effective data stories, there needs to be some level of forethought into the data culture and structure of the organization. Just from a logistical perspective, it would be very difficult for someone to be able to take the necessary time, delicacy, rigor and sophistication needed to truly create an effective data story (e.g., using the right data, in the right analysis, with the right methods, with the right communication of results) without the support of foundational data infrastructure, data governance, process/project management, defined roles/responsibilities, overall strategy, etc. These things should be in place (_or at least working towards it_) to be able to apply the appropriate amount of rigor and detail required in an efficient and timely manner. # 3. Tailor communication of results to your audience I often build analyses in the form of HTML documents (via [R Markdown](https://rmarkdown.rstudio.com/)) where the intention is to lay out a story of the data in a particular order, such the the end-user would read through the document on their own to gain the messages of the analysis with interactive figures and tables (I believe the idea of _"scrollytelling"_). However, I would often get asked by stakeholders to instead present/explain the material for them instead of them (understandably) reading through the whole thing on their own. So I would attend a meeting, bring up the document, and begin walking them through the document. I quickly found that this didn't work. The intention of the document was to be read, not presented, and so people would get bogged down/distracted by the narrative in the document while presenting. It just felt uncomfortable. This is _exactly_ something that is talked about in the book of what not to do. So, before sharing with stakeholders or presenting, I started converting the information in the document into a slide deck, pulling out the most useful information that was tailored to the way I would present it. Also, recreating graphs, tables, and/or figures that point out just the most pertinent data, instead of using the exhaustive summaries built in the exploratory analysis. These strategies proved to be much more effective and satisfying both for myself and the stakeholders.