Reporting is an important part of your product. It can help to analyse trends, identify issues, and track performance.
Reports come in many shapes and sizes. Let’s look at some of the different types, and which ones you should think about using.
Types of reports
Summary reports or stats can give a quick snapshot of recent activity and the health of your product.
Transactional reports can give a more detailed breakdown, such as a list of all recent orders.
How will reports be used?
To plan the reports you need, you’ll need to look at how they will be used. Think of the following examples:
- A sales director who wants to see a weekly summary of sales across a range of products so they can understand sales performance.
- A financial analyst who wants a daily list of transactions so they can import it to an accounting package.
- A back office user who wants a summary of accounts requiring action so they can stay on top of anything awaiting their attention.
I’ve written those statements in a similar format to user stories. By understanding the person affected, what they want, and why they want it – you’re well-equipped to look at the right solution for each scenario.
Don’t build every report
Is a user asking for a report that they want to run regularly – or is it a one-off? Would other users benefit from the same report?
Building every report directly into your product is overkill. Every report you add – and indeed every feature – has to be supported. Having too many similar reports will create confusion for users.
Allowing users to self-serve commonly requested reports will save time in running reports for people, but be wary of jumping too quickly to building your way out of a request.
Could users run their own reports?
Having some core summary stats in your product can be a useful snapshot for users. But users may then wish to understand how those stats are generated. They may want to drill down into the list of accounts showing for each stat, or modify the query slightly.
Similarly, one user may be happy with a report, but a different user may want additional fields included.
This is where it might be worth exploring tools such as Tableau, Databricks, or PowerBI – perhaps as pre-built dashboards, or to give users the ability to build their own reports.
You’ll need to take a pragmatic approach to decide what’s a “core report” that belongs in the product itself – and what could be “farmed out” to an external reporting tool.
Examples of reports
Stats summary
By showing a quick stats summary in your product, relevant users can see a snapshot of information without needing to run a report every time. Below is an example from one of my projects – Switch Scores.
This shows the total number of review scores (or links) in the database, along with the split of Ranked vs Unranked games.
Action list – Stats
If a user needs to look out for things requiring action, the stats summary can be linked to an action list. Here is another example.
In this case, all of the stats listed require manual intervention before they will go onto the site. By grouping these together on a single dashboard, the user does not need to jump between multiple screens or run a manual report to find this data.
Detailed list
One of the other action lists in this project is to show games that are unranked. This list is split in a few ways; one of which is to show games that have 2 reviews. A ranked game has 3 reviews, so an unranked game with 2 reviews needs the least amount of effort to become ranked. Below you can see the first part of this report.
If any of the games listed gets a 3rd review, it will disappear from the list.
Summary
By including reports in your product, you’re providing useful insights and helping certain types of users to identify things that need action. Finding a careful balance between reports in the product, manually running queries for users, or giving users access to build their own reports, is important to make sure you are spending your time on the most worthwhile activities.
Photo by Lukas Blazek on Unsplash
