So the Analytics people has to be the ones that simplify the decision making process. They 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, like I mentioned in “How to make self explaining reports“. But making the long story short, the person that analyzes the data goes through a 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.S. or Personal Information Sense). It doesn’t matter how good the analyst is, it’s almost impossible to transfer all the generated context to the report.
On the other hand the person that receives the report doesn’t have all that context so it fills the lack of context with personal inferences. This is really bad and risky.
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 personal 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 looks like:
What are your thoughts about that Dashboard? Don’t be that bad. It can like you or not, but the main problem of 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 ok for people in operations because the day by day work gives them the required context along with granularity, which is an important “Feature” when you are operating something.
The situation is completely different when someone that is not involved in the operations (a leader, head, director, and people from other areas that need to connect their information with yours, or evaluate your performance) get in touch with this type of Dashboard. It’s almost impossible not just to make a decision, but to make an opinion on it.
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 that 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 basin their decisions in a source they can or cannot trust. The dashboard certainty is key to help improving it. Every time a person closes the dashboard they should receive two questions: 1) Have you action based on this dashboard lately? 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 generate a story flow that can drive people to the right 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 that makes simple to everyone linking what the widget is displaying and the question that you are 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 get a feedback from them. 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.
- Note: The note is an editable field that allow the person that is analyzing the report to build the story. Since the dashboard is alive, the story will be changing all the time, also based on the selected time period. It has to be a 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 the final example. Let’s convert insights into actions!