For the past 10 years, I have seen and developed many reports that look great, incorporate all the features of the relevant tool, that offer that wow factor when they are first revealed, and that align to the requirements that were provided upfront by the business. However, I too often find these same reports to be:
- Highly utilised initially but then experiencing a sharp decline. Not the greatest of feelings.
- Sending people on fishing trips by overwhelming them with endless scrolling and analysis, which features like drillthrough, drilldown, and bookmarks don't alleviate.
- Failing to provide answers to business questions.
- Eventually being questioned about whether they provide the information actually needed by those who provided the requirements.
Okay, that's a lot to process. But in this blog, I really want to delve into some of the steps we can take to start creating reports that genuinely offer more insights—or at least get us closer to it. Understanding how to gather user requirements and integrating data storytelling has always been a topic I find most interesting.
Who's it for?
The number one issue I find with reports failing is the gathering of requirements from those who won't actually use the solution. Often, seniors or representatives claim they can provide all the information for the report's users. Sure, they hold decision-making power or may have some influence in the organization, but this doesn't mean they grasp the day-to-day challenges of the actual end users.
When I start on a report project, the first set of questions revolve around understanding who will be the audience, so, the actual users of the report. If I find that they're not involved in the requirements gathering, I point out the risks. Depending on where you are in your career, your role, and the company type, this may seem intimidating. Early in my career, I would have hesitated to push back, but I assure you, not speaking up increases the likelihood of failure. Also, when I see that too many audiences, like executives, operations, and HR, are involved, I again flag the risks. Trying to satisfy too many audience requirements can be just as detrimental as ignoring the needs of the actual end users. This puts us on the path of creating reports that are too busy and have no clear focus. Think about it, screen estate in most cases is an issue even with one audience (and no, changing the default canvas size is not a solution), let alone three audiences. My general rule here is, let's attempt it with more than one audience if they have the same purpose or a relatable one for the report.
If you step back and think about any other profession, being told that requirements are gathered from someone who won't be the main user or the most impacted seems absurd. It should be no different here. Also, I am a big believer in facilitating the right workshops for asking the right questions to help derive what is truly required. However. if you are faced with an audience that can't tell you where they are trying to go and what they are trying to do, I would highlight this as a major risk. I know this is tough and might come off as a rant, but if the people requesting a solution can't articulate their needs at a high level, they likely need to have an internal discussion. To summarise, step one in creating an insightful report is to gather the reporting requirements from the actual people who will be using it.
How do we measure the ROI
Once we've identified the audience, it's time to start collecting the requirements. As part of this, we must understand the value this report will bring. Over the years, when I've asked how do we measure the ROI of a report, the common response was to check the report usage logs. Now look, I'll be the first to admit, that I've also relied on this metric, however, it's not about how often the report is viewed; it's about how we use the data and the insights gained. To truly measure the ROI we need to derive a destination: 'Where are we trying to go?', which is part of a compelling data story which we will see further below. However, it's worth calling this out separately, as holding this understanding should enable us to measure the ROI. The where are we trying to go should be linked to an element such as boost revenue, mitigate risks, enhance efficiency, reduce costs, etc. Too often, we run away with a set of tasks and don't grasp the business value we intend to deliver. So, before spending time and resources on a project, it's important to identify the expected ROI.
I've noticed it's quite common for individuals to create reports that initially capture an audience's attention with their stunning design but quickly lose their appeal, resulting in people returning to what they previously used. For the past few years, I've emphasised that it's not about the technology. In fact, when we are discussing the ROI or the value we are hoping to gain, I purposely ask we don't speak tech. I know, it sounds weird, lets develop a report but not talk tech. However, the purpose of this is to really delve into the business challenges and vision. So again, where are we trying to go?
It's okay to ask why!
Is it necessary to ingest the last five years of data into the semantic model, include all 19 KPIs with variances, and to distribute it as a PDF daily? I know, there may be some cases where this is justified, but we should always step back and question the need. Why is five years of historical data required if our analysis is focused on this year versus last year? Do we need the all 19 KPIs and their variances on one canvas if they aren't all directly impacting our objective? Why should users receive this information via email rather than accessing it directly online? By asking these questions, we can better tailor our solutions to align with what the users truly need.
A lot of the work in building an insightful report begins before we even launch Power BI. As I mentioned earlier, we need to focus less on tech and more on the business challenges and the vision. Whether it’s for an internal stakeholder group or an external client, they’ve given us their time not just to hear that everything is amazing, but to receive recommendations on creating solutions that provide insights. To achieve this, we really do need to ask, 'Why?'
Tell a Story!
Data storytelling is not merely a dashboard. Yes, a data story can be integrated into a dashboard through a specific approach, but merely developing a dashboard by asking "What do you want?" does not necessarily incorporate the elements of a data story. Data storytelling is all about combining the data, visuals, and narrative. The key element here is the narrative, it's the story told to aid and steer the audience toward a definitive action. Hence, adopting a data storytelling approach when collecting reporting requirements enables us to craft reports that are more engaging, persuasive, and actionable.
Numerous methods exist for telling a data story, deriving actionable KPIs, and gathering requirements, many of which share similar features. Over the years, I've concentrated on four essential components of a compelling data story. I recall a report gathering workshop in late 2015 where we tackled three of these components. But nostalgia aside, the four elements of a compelling data story are: 1) Purpose—Where are you trying to go? 2) KPIs—How do we know if you are on target? 3) Causes—If you are not on target, why? 4) Actions—What can you do to fix it? Simply consider these as the beginning, middle, and end of any effective story. Also, recall the earlier mention of "Purpose"- where are we trying to go - which is important for gauging the ROI. Knowing our destination allows us to recognise when we arrive. And if we reach or even approach our destination, we can measure the ROI. Again, the where are we trying to go should be linked to an element such as boost revenue, mitigate risks, enhance efficiency, reduce costs, etc.
This is a subject that can be its own blog series and so much more can be shared, so please do reach out if you have any questions. To summarise, we should adopt a data storytelling approach when designing and building our reports. This is by facilitating a workshop with the audience, to ask the right questions, and to derive the four parts of a compelling data story on a storyboard. This can be done in person through sticky notes as I did many times over the years, it could be through PowerPoint, or better so, through a platform like MIRO. Remember, spending extra time and effort on this and not rushing ahead to designing and building a report, will certainly put you on the right path to creating reports that offer genuine insights.
Playback the Requirments
One additional step I want to share for creating insightful reports is playing back the results of your storyboard. I find many people may come back with a different opinion or thought after a day of thinking. After initially gathering requirements, make sure to book time with the audience of the solution. This is not only for them to validate what they initially said, but also to be held more accountable. As with any project, we want sign-off before moving to design and a build, hence consider this being that.
Hold up... Where is the DataViz?
Now please don't misunderstand me. I am not suggesting that DataViz lacks influence over a report's insightfulness. However, in this blog, I have concentrated on the steps we should take before delving into the creation of wireframes with tools like Figma or the trusty pencil and paper. Before we begin to determine which visuals will most effectively bring our story to life, before we select colour palettes, before we decide on the analysis features to use, I've focused on the steps to undertake before we actually launch Power BI Desktop.
Summary
Next time you find yourself on a reporting project, I would ask you dont rush to desinging wireframes, opening up Power BI desktop or whichever tool you use to create reports. But instead, spend more time on finding the audience, understand where they are trying to go, asking relevant why questions to any requirements provided upfront, collect the four parts of a compelling data story using a storyboard and offering time to validate findings. If you follow these steps, I am sure you will be one step closer to creating reports that offer genuine insights.