The purpose of reports is to convey information. A report converts underlying data into information.

There are a number of things you need to consider when designing reports, all inter-related. One important thing that’s often overlooked is that your opinions, as the report designer/developer, don’t really matter. You won’t be using the report every day, it’s the consumers of the data that matter. One of the key skills is trying to find out what the report consumers actually want to see. Quite often you’ll find they don’t really know what they want to see, they’ll think they know but when it comes to it they actually only have half an idea. What questions is the report meant to answer?

Your job as the report designer is to make the report users life as easy as possible. If they want to know a metric ideally they’ll only have to click a button or two and the answer will be there. Generally you’ll find if they have to download data, put it into Excel and then manipulate it then usage of the report won’t be good. You’re actually creating work for the user where a report is meant to answer questions speed up processes.

To create a report you need to think about the following:

Audience

The first thing you need to consider is the audience. You can’t decide on the type of report or the software to produce the report until you know who the audience is. The marketing department will want to see something different to the board. It’s likely the further down the chain of command the more detail and more flexibility will be required in the report, while board level reports are likely to be a dashboard showing trends, allowing simple comparisons and get a general feel for how things are performing.

What to display

Once you know who will be consuming the report data you also need to know what way they want to be seeing the data. Are they wanting to see trends? Do they want raw data?

You need to find out what questions they’re trying to answer and why they’re trying to answer them. By asking these questions you should be able to think of the best way to supply the data to make their life as easy as possible.

What ‘reporting level’ should this report be? That’s a question you as the report designer should be able to answer based on the audience and what questions they’re trying to answer. See my earlier post describing the report type needed to tailor a report to the audience.

Performance

A report should be quick to return information – consumers of the report don’t really want to be waiting long to get the information. How long they’re willing to wait obviously depends on the organisation, the history and the audience. An organisation that previously had no information (it does happen for more than you’d think) is likely to be happy to wait 10-20 mins for the information to load. Organisations with robust and established business intelligence/reporting departments are less likely to be tolerant of large waiting times for information.

If you find that performance is slow then you need to find why and whether anything can be done to speed things up. It could be you’re querying a large table in a database that’s poorly indexed for the data you’re retrieving. Perhaps there are server/hardware improvements that could be made. Maybe the code you’re using to pull the data could be optimised. In the worst case situations it could be the database architecture may be completely inadequate for what you’re trying to achieve. I’ll cover this in a future post as I’m currently managing a project to design and build a star schema on  an established data warehouse which wasn’t created for reporting.

Intuitive

One thing I like in my reports is that they’re intuitive for a new user. Labelling must be clear and consistent with other reports in the same family. If using colour it’s also best to be consistent between reports as to what the colour displays if this is possible. For example if showing product category in a number of different reports make each product that same colour in all of the reports. It’s good to put a guide/help section on them to explain anything that might not be obvious for someone looking at the report for the first time.

I’d suggest you ask someone new to the company or unfamiliar with the reporting area what they don’t understand, they’ll tell you where you need to improve the in-report messaging.

Iterate

To reiterate what was said at the beginning, your opinions as the report designer are not important. What matters is what the report consumers want. You’re creating a report to supply information and make their job easier – if they want changes you need to see how they can be incorporated.

There is almost no chance the initial report will be the end report, I would usually expect to go between 3 and 5 iterations until the report consumers needs are met.