1. Translating technical results
In the previous lesson we talked about data storytelling.
2. Data storytelling
It captures the audience's attention,
provides meaning and context,
and helps retain insights,
and therefore leads to better-informed decision-making.
It also helps persuade change-resistant stakeholders.
3. Tech or non-tech approach?
Now that we learned why designing a story is important, we should look into the next piece: defining how technical our audience is. We will simplify this into technical and non-technical for better understanding,
but technical knowledge is a continuum and it's up to you to assess your audience's technical proficiency - the Director of Analytics is likely more technical than the People Ops Generalist.
In general, data professionals like to talk about their methods.
Less technical audiences however typically just care about what the result is and what the implications are.
4. How technical?
For example, we may need to explain
why low accuracy predictions affect the business outcome to supply chain specialists and how better data entry on their end could help.
They won't care about our model or hyper-parameter tuning.
They will care that if data entry is improved and taken seriously, predictions will be radically better and they will have to deal with a lot less returns and shipping problems.
5. Translating technical results into stories
This requires translating results into
easy to understand stories that
can engage a non-technical audience.
Stakeholders will understand our results, telling stories with simple terms can facilitate decision-making processes and,
eventually, drive change.
There are different strategies to communicate our insights and results effectively. Let's explore them.
6. Awareness
The first thing is considering our audience.
What is their background? What do they know?
Understanding our audience helps us adjust our story content to each stakeholder.
So instead of explaining how our model works,
they should understand the impact and limitations of our predictions.
How much do they need to understand to meet our goal?
We should explain the results with enthusiasm and be aware of any questions they have.
Explaining why we chose the variables to predict is not useful for a non-tech person,
we should explain the context in which our model works.
What information do they need?
Our story should help the audience understand what our project is about.
Listing the correlation coefficients could be overwhelming,
it's better to explain the interaction between customer traits.
7. ADEPT
The ADEPT technique, as recommended by Kalid Azad, can be pretty handy.
We need to use analogies, so the audience can relate new things they are not very comfortable with to other things they understand well already.
We also need diagrams, to help visualize.
The illustrative power of examples is always efficient.
8. Analogies
As an example,
instead of explaining how a neural network works with forward and backward propagation,
we can say it learns like a child does, by getting feedback on what is right or wrong, what works and what doesn't.
9. Technical jargon
We also need to pay attention to our choice of word.
Acronyms, for example, should be used with caution. They help communication if everyone understands them, but hurt it otherwise. At Space X for example, acronyms have to be approved by Musk.
It's good practice to introduce an acronym's meaning the first time it's used.
Similarly, we should limit the use of jargon.
and instead translate the terminology into simpler and familiar terms.
Including a reference guide or definitions in our report is good practice as well.
Again, we should take our audience into account: the data manager might now what EDA means, but the HR specialist might not.
10. Focus on impact
Even if we are interested in showing the technical details, a persuasive story usually focuses on impact rather than process.
If we are talking about adopting a new technology,
we should focus on the impact that technology has on the technical team's time and deliverables.
Or if we are explaining how our model predicts an outcome,
we should focus on the benefits, such as financial benefits.
11. Humility
Lastly, we should be aware that not all technical details can be removed. In that case, we should make our audience comfortable
demonstrating receptiveness to questions,
proactively asking if it's clear or if there are any questions after an explanation,
and be prepared to explaining concepts again using different strategies.
12. Let's practice!
Now, it's your time to select how to translate technical results given the situation at hand!