The report components you should never forget about

A lot of times report developers are working against a running clock to deliver the reports they are asked to produce as quickly as possible. As such, many times we end up with a multitude of reports with different looks and feels as this is usually a lower priority. Best practices ask for a consistency in your reports’ look and feel as it improves user experience. So let’s see what are the report components you should never forget about going forward.

Header

This is usually the first section of the report which your users will see. The following information is useful to have in this section.

Logo/brand name: If your reports are catered towards users outside of the organization, this is a must have component. Even if it’s catered towards internal audiences, you can use variations of the logo to denote specific departments or units.

Report title: It’s obvious, but this is sometimes overlooked. Recording the title of your report is important because it’s usually what the business users will reference and a clear indicator they are looking at the report they wanted to look at. Ideally you can determine a naming convention as well such as:

• Business unit or Enterprise level – Report title or Report title (Business Unit)
• Data domain – Report title or Report title (Data domain)
• Report category – Report title or Report title (Category)

There are of course other variations and the name format depends on the number of reports and what your accessibility policies are. For example, if business unit specific reports are not accessible across the enterprise, there’s no point to mention the business unit within the title itself. You can instead capture that information as part of your report inventory.

Date data is pulled on: I always like to make sure this is present on our reports. Having this date increases awareness in the validity and timeliness of the underlying data, especially if the report relies on a data warehouse or a data mart, where the data might have been produced, transformed, refreshed as part of a nightly or weekly job.

Data source(s):  This information should be made available to the consumer to again reinforce the validity and provenance of the underlying data. On the other hand, I also I agree that this is mostly useful for developers in order to have a direct way of differentiating between production data sources and those used for testing. I remember several cases where reports still under development found their way to stakeholders not part of the testing groups. They would follow-up with the Business Intelligence team to raise their concerns with the data presented. Having the data source present on the report quickly identified that the report wasn’t meant to showcase production data as it was still in its early development stages. Yes, I know you can also flag this in the report title itself or by using different colors, or a different logo, or place a watermark across the body of the report, but certain stakeholders want the test report to look as close as possible to its future state. I’m sure you can sympathize.

Report ran by: Having this on your report adds another level of accountability and compliance with your organization’s information security and privacy policies. Having your name on the report will make you more vigilant in ensuring the report is not shared with anyone you shouldn’t share it to, or accidently leaving a printed copy in a coffee shop.

Filters/ parameters: If the report is configurable to provide data or visualizations based on user selected parameters, make sure this criteria is displayed once the report is ran. For any report saved as a pdf, exported as an image, data file, or printed, the selected criteria provides background on the end result.

Report body

This is the main and most important part of the report and the reason why your users are looking at it. The type of content of this section varies based on:

• the message it will try to convey and the purpose of the report
• the underlying data
• the type of visualization selected to best portray the data

Do you need some data visualization ideas? These are the 5 graphs you should always use. 

Footer

Confidentiality statement: You should get this from your privacy office, but here is the template I recommend using as it’s broad and comprehensive enough:

© [Current Year] [Your Organization Name]. All Rights Reserved. This document contains confidential information.
Any use or sharing of this information, both within the organization and with third parties, must abide by all applicable organizational policies, guidelines and standards.

Page number: For multi page reports, always use a page annotation and provide the number of pages the report has. Ex: Page 1/4. This greatly improves usability.

Supporting page

I recommend having this as an addendum to each of your reports, even for those with only one page. It helps with onboarding, report adoption, and increases the user experience.

Technical contact: The contact details of the department or technical person in charge with the maintenance of the report, should you need to raise an issue, suggest improvements, or have questions which need further clarification.

Business glossary terms: Besides a link to your organization’s business glossary, here’s where you should provide a list of terms used in the report and their definitions. This could reflect the business term definitions and/or how certain values and totals were calculated, or if any assumptions had to be made. If you’d like to learn more best practices, know-how’s and how-to’s on business glossary terms, checkout this Business Glossary Online Course.

In a separate article I’ll provide you with a free template for the design guidelines of a report which you can use as a baseline and modify it to your own requirements.