Reporting vs. Dashboarding
In this chapter, we’ll look at who needs this data and how, or should we give it to them?
We’ll review strategies for collaborating with stakeholders to prevent disappointment and exceed expectations.
We’ll try to transform data into tangible wisdom, showcasing the good, the bad, and the ugly aspects of reporting and dashboards.
…and review why an apple is not always an apple.
Steady yourself for invaluable insights as we navigate the complexities of data demands and unlock the power of genuine wisdom (not mine, yours).
9.1 – Who Wants Data
Is a dashboard a report, or is a report a dashboard, or are they just the same? Does it matter? This fundamental question drives much confusion around the delivery of data and insights – even around the nature of dashboards: does a dashboard have to be built in a tool like Data Studio and auto-update to be a dashboard, or can it be a collection of graphs and metrics in Google Sheets or static in PowerPoint?
After years of building reports and dashboards for many different stakeholders, I’ve learnt that it is always best to clear this up before starting anything. Here’s my understanding of the issue and the various types of reports and considerations to ensure everyone has the right level of information.
A dashboard is a visual display of all your must-have data. Think car dashboard. While it can be used in various ways, its primary intention is to provide information at-a-glance, such as KPIs. A dashboard usually sits on its page and receives information from a linked database or API.
A report is a specific form of writing organised around concisely identifying and examining issues, events, or findings that have happened in a physical sense, such as events that have occurred within an organisation or findings from research investigation.
So, a dashboard, by definition, is not reporting; it’s something you might report on.
The key considerations are to plan and agree on before building a dashboard or writing a report:
Frequency – how often does the audience need access to the data? And over what period does enough data accumulate for the insights derived to be significant?
Complexity – how complicated and detailed is suitable for the audience? Do you need all those metrics crammed into one master dashboard?
Accuracy and Reliability – how important are the accuracy and reliability of the data and the method? This usually links to the importance of the question you’re looking to answer and the seniority of the person you’re looking to deliver it to or give access to.
Audience – the most crucial point. Who is this going to be for? The wider marketing team, the CMO or CEO, the head of the department, a colleague, or a customer? How much time and experience do they have to interpret the information you put forward?
DIKW – Data, Information, Knowledge, or Wisdom. What level of detail and/or formulated conclusions are expected? This can take time and resources and is not always possible. Just because you dig for gold doesn’t mean you will find it.
We need to tailor our delivery to each requirement. To do that, we need to ask lots and lots of basic questions and sometimes explain to our audience why what they think they want is not actually what they need. Let’s start with the DIKW Pyramid.
