During my career as a Software Engineer/Report Architect, I have defined several rules for designing automated reports. I always follow these rules and get positive feedback from the report users. I hope these rules will help you in designing an ideal report.
Rule 1: Actionable Report
A report should be actionable. That means that after reviewing the report a report user should be able to make decisions to correct an identified business problem. Also, the report is considered actionable if it helps to identify areas for further investigation.
Review the report example below that supports a real-estate renting business. The report calculates the count of every weekday per year. Potentially years with most weekends would bring bigger rent profit for the business.
Year Su Mo Tu We Th Fr Sa Days Year Su Mo Tu We Th Fr Sa Days 1999: 52 52 52 52 52 53 52 365 2015: 52 52 52 52 53 52 52 365 2000: 53 52 52 52 52 52 53 366 2016: 52 52 52 52 52 53 53 366 2001: 52 53 52 52 52 52 52 365 2017: 53 52 52 52 52 52 52 365 2002: 52 52 53 52 52 52 52 365 2018: 52 53 52 52 52 52 52 365 2003: 52 52 52 53 52 52 52 365 2019: 52 52 53 52 52 52 52 365 2004: 52 52 52 52 53 53 52 366 2020: 52 52 52 53 53 52 52 366 2005: 52 52 52 52 52 52 53 365 2021: 52 52 52 52 52 53 52 365 2006: 53 52 52 52 52 52 52 365 2022: 52 52 52 52 52 52 53 365 2007: 52 53 52 52 52 52 52 365 2023: 53 52 52 52 52 52 52 365 2008: 52 52 53 53 52 52 52 366 2024: 52 53 53 52 52 52 52 366 2009: 52 52 52 52 53 52 52 365 2025: 52 52 52 53 52 52 52 365 2010: 52 52 52 52 52 53 52 365 2026: 52 52 52 52 53 52 52 365 2011: 52 52 52 52 52 52 53 365 2027: 52 52 52 52 52 53 52 365 2012: 53 53 52 52 52 52 52 366 2028: 53 52 52 52 52 52 53 366 2013: 52 52 53 52 52 52 52 365 2029: 52 53 52 52 52 52 52 365 2014: 52 52 52 53 52 52 52 365 2030: 52 52 53 52 52 52 52 365
The report shows that the years with maximum weekend days are very rare – they are at least 28 years apart: see the years 2000 and 2028. That means the potential profit difference is insignificant (less than 0.5%). What actions or decisions can we make based on the data from this report? Have we identified a problem for further investigation? No! This report is nice since it shows information not known before, but it is completely useless for any real business. Sometimes the reporting requirements only appear to be solid. Identify and retire useless reports.
Summary: Design each report to support actions and decisions. Avoid showing “nice-to-know” but useless data.
Rule 2: One Objective for One Report
Design every report with only one objective to reflect aspects of only one major business area. A very complex business area may be covered by several reports linked to each other: the main report shows the summary of the business area and a few sub-reports present various aspects of that area.
Enhancing an existing report to support unrelated reporting objectives may decrease the report’s ability to serve its main objective. As report users get familiar with their reporting solution they start requesting new features and enhancements to the existing reports. Most of these feature requests hide new reporting objectives. Carefully analyze all incoming requests from customers and try to identify new business areas that deserve their own, separate report.
The report “Warehouse Status” shown below is an example of fitting too many objectives into one report. This report presents a list of products with related information: price, return policy, and next arrival details.
The report shows useful information in a clear format, but different customers will have problems with using this report as the report design has an issue. The report tries to cover the use cases of three different departments responsible for product inventory, order processing and shipment logistics. Since the report space is used to fit unrelated data there is simply no space left to provide all important details to make the report actionable in any of these areas. For example, employees responsible for logistics don’t need return policy data, but they need more details about the next arrival. We should split this report into three different reports based on the requirements of three different departments.
Summary: Design each report to describe only one business area.
Rule 3: Report Readability
A well-designed report should be easy to analyze on a computer screen or paper when printed. Simple techniques such as graying every second record in a table, rendering table headers on every page, aligning numbers to the right, providing legend to every chart/graph and many more – all these techniques improve the report readability. Not all techniques should be implemented in every report, but all of them should be considered during the report design phase.
The best advice is to learn all those techniques. Read a few books for designing web pages and printed materials. Most topics described in the design books apply to the reporting industry as well. You will learn which font suits best for titles, headers, and descriptions; and how to choose colors to highlight report elements; the same color could mean completely different concepts in different cultures.
Organize a usability study to prove that reports are easy to read and understand. If your budget is tight show the reports to your colleagues, customers, or friends and think about their feedback. Remember about accessibility. People with eyesight disorders, such as color-blinding, may struggle with badly designed reports.
Summary: Know your report customers. Learn the design techniques.
Rule 4: Amount of Data
A report should contain a certain amount of data to be actionable. Too much data hurts readability while lack of data makes the report less actionable. It is difficult to define the “ideal amount” of data, so the example below helps to describe this rule.
Consider a report that shows information about products stored in a warehouse. The report shows all the products with their 20-30 properties and descriptions. Information about one product fits in half of a printed page and provides all the needed data to warehouse administrators about a particular product. The problem with this report is that it shows a long list of products that, if printed, may spread across hundreds or thousands of pages. This report is not possible to use without computerized search/filter functionality or without a “table of contents” if printed. This example describes the product catalog, not the actionable report. Don’t be confused by used technology, the same technology can be used to implement catalog systems and reporting solutions.
If your reporting solution contains this type of report don’t throw them away, add filtering parameters, table of contents, or interactive navigation. Add new actionable reports to the related business areas.
If your report contains details that are shown on multiple pages consider adding short summary to the first page of the report. See the example below:
Summary: Avoid very long reports.
I hope reading this article was useful. Now try to design your ideal report!
Please share your rules in the comments below.
Leave a Reply