Analytics people have to be the ones that simplify the decision making process. We have to be the ones that help people consume the information in a way that is simple, it is not time consuming, it is not confusing and as univocal as possible.
Analyzing and reporting are two completely different things (more info here “How to make self explaining reports“). The person that analyzes the data goes through a mediate process of questions and answers that generates the layers of information that will give context to the reported data (What I call the P.I.C. or Personal Information Context).
It doesn’t matter how good the analyst is, it’s almost impossible to transfer all the context from the analytics process to the report.
The person that receives the report doesn’t count with that context, which will drive that person to fill the lack of context with personal inferences which is something that we really don’t want.
So we can say that the most important skill that an analyst has to have is to be able to tell a story where there is almost no room for subjectivities (If you want to know about mental models you can read about it in the post “Are you still struggling with data? Here is why”).
This is how a Dashboards normally look like:
What are your thoughts about that Dashboard? The main problem with that type of Dashboard (and not just this one in particular) is that you need a lot of context to understand what’s the story it is trying to tell. That’s acceptable for people in operations because they count with the context and granularity that the day-by-day-work provides them, which is an important “Feature” when you are operating something.
But when someone that is not involved in the operations (a leader, head, director, and people from another areas that need to connect their information with yours, or evaluate your performance) get in touch with this type of Dashboard, the situation can be completely different…negatively talking.
If a person with no context take a look at the dashboard like the one above, it can result in an interpretation that has nothing to do with the story the dashboards in trying to tell.
So my suggestion works with another type of Dashboard, the “Meta Analytics Dashboards.”
Here is a step by step guide to conquer the Meta Analytics Dashboards:
- Objective: This is not, as it normally works, the objective of the Dashboard itself but the objective we are trying to achieve as a company by the decision that we can make with this dashboard. It has to be something tangible, easy to understand by anyone that reads the dashboard. Don’t use things like increase value but things like reduce churn, increase sales, improve customer satisfaction, reduce delivery time, etc. I highly recommend to add a note on how this objective is linked with the company one. If your objective is reduce churn, explain how reducing churn impacts the company’s objective of making money. In most cases relating metrics is not as simple as in this example. In a Social Media Dashboard, the objetive can be to “Increase engagement”, so you have to explain that every X% of increase in engagement represents Y% increases in purchase intention, or in sales…
- Dashboard certainty: This metric is based in the follow up received by the people that use the dashboard and it’s very useful for the dashboard users to know if they are basing their decisions in a source they can or cannot trust. The “dashboard certainty” is key a key feature to help improving it. Every time a person closes the dashboard they should receive two questions: 1) Have you made a decision based on this dashboard ? 2) Was the insight right? If the person answer is “Yes” to the first question, we count 1 in the denominator, if the person answer “Yes” in the second one, that goes to the numerator. The Dashboard Certainty will be 100% if all the “generated recommendations” generated the “predicted” results. If not, there’s work to be done. The information has two main objectives, decision making and controlling. If you are not being able to do either of those things, the dashboard is useless.
- Story Stream: The story stream is the process you have to design in order to tell the story. Is like in every story, the parts are the setting, the plot, the conflict, and the resolution. Here is the same thing, you have to plan how are you going to create a story flow that can drive people to the right interpretations, decisions and actions. The key here is that the story works no matter what’s the output of each widget. It’s like those choose your own adventure books.
- Story Widget Title: Each Story Widget (part of the story) will have a specific question that has to be answered in order to generate relevance to the story. Don’t use regular titles like “Sales per month”. Use questions instead. That will make way easier for people to understand what the widget is displaying (what question is trying to answer).
- Widget: The widget is the only data support you will use in each part of the story. It’s really important that everyone can understand how that widget is answering the question. Share the dashboard to non-experts and see if they are properly understanding the story you are trying to tell . Remember that once the dashboard is finished, people won’t call you to tell you they don’t understand it, they will be making decisions base on what THEY BELIEVE the widget is showing. This can get as dangerous as it sounds.
- Note: The note is an editable field that allow the person that is analyzing the report to add context and build the story. Since the dashboard is alive, the story will be changing all the time (and off-course it will also change based on the period of time selected). Take this field as a twitter-140-characters type of message that should connect all the parts of the story univocally.
- Source: This is the last part of each Story Widget. It’s must refer (and ideally link) to the data source that feeds the widget in case further analysis is required.
Let’s see a final example. Let’s turn insights into actions!
