What are best practices for BI reports?

by Dan Power


Structured, periodic reports remain at the center of data-driven decision support for managerial decision-making. The reports may be in portable document format (PDF) and the reports are probably web accessible, but we still create and use reports. Twenty-five years ago, one would see piles of computer printouts in a manager's office. Today reports include graphs in color with professional looking tables, but we still print reports. Managers and IS/T staff need to know how to design reports.

Why do we print reports? Managers can quickly scan a paper report while multi-tasking and many managers are reluctant to read reports online. Reading emails is already a burden.

Many reports are hurriedly constructed, repetitive and create information overload. Managers think they know what they want in reports and that and more is what they get from an accommodating IS/T staffer. After all, the IS/T staffer doesn't know exactly what information a manager needs, and when, to help manage the business. Also, most IS/T staffers have not been taught how to design decision relevant reports.

IS/T keeps hoping reports will "go away" with web-based end user access to data. What is happening is that some managers and staff are creating reports that must be printed to disseminate them.

Report training is focused on technical capabilities in report writers and report wizards step a manager or staffer "through creating simple reports without writing any code". So most reports are page after page of data. Too many fields are often displayed, table headings are cryptic or field names from the data store, basic context information like date of the report, who prepared it, and a title that suggests the purpose of the report are forgotten, and gratuitous charts and cross tabulations are included because it is easy to do so not because of user needs. Many reports slow decision making rather than increase decision effectiveness.

Both periodic and ad hoc business intelligence reports may be primarily informational, analytical or comparative. The informational reports summarize what has happened for a time period and may focus on key performance indicators and critical success factors. Analytical reports do more than summarize, such reports emphasize averages, deviations, trends and cross tabulations. Comparative reports usually focus on internal comparisons like actual versus budgeted or sales by category compared to a prior quarter or year. Some comparison reports include external data.

Some periodic reports are generated in the operational data-driven DSS automatically. These reports often answer the "what is happening right now?" question. Other periodic and ad hoc reports are intended to answer specific decision related questions. Pre-defined reports are usually still developed by the IS/T department in response to a user request. With easier to use report generator tools, many users generate their own reports. Neither IS/T nor most users do much report planning. The tools make it so fast to get the data into a report that the objectives, purpose and best design for the specific report are often forgotten.

The message is clear that we need to teach people who create reports how to do it better. Reports will not go away!

Microsoft Technet notes "Report design is usually a two-part process that consists of defining data and arranging items on a page. ... A report consists of three main areas: a page header, a page footer, and the body. ...The placement of report items in a report is completely freeform." In reality, report design is a three-part process, and the first step is defining the objective of the report, then one can move on to "defining data and arranging items on a page".

So what are some "best practices" guidelines for designing reports used to support decision making? We have more guidelines for email and website usability than we do for business intelligence reports. But we don't want guideline overload, "Website Usability -- 144 guidelines for improving the design" or "Email Newsletter Usability -- 165 Design Guidelines for Content". The following is my short list.

1. Keep it simple and short! Shorter is better and for performance monitoring a one page report is ideal. Don't create complex, hard to understand reports.

2. Charts and graphs should add value and convey a single message. Just because it is easy to create charts doesn't mean you need them. It is true that a chart often conveys a lot of of information in a decision compelling way, but a chart needs annotation, descriptive title and labels.

3. Don't overload the user with too many numbers. Pages of detailed data is not a report. Some managers want all of the detail in a report. That's usually because they don't trust the accuracy of the summarized data. After some period of time, the manager may gain trust in the data and request more summarization. Then a real report can be designed.

4. When possible use color, shading or graphics like arrows to highlight key findings, discrepancies or major indicators. In a paper or web-based report you cannot rely on color alone to convey differences in charts or tables.

5. Create and follow report design guidelines. Educate people who create reports about effective reporting.

6. Talk to managers/users. Discuss report design with the person who requests the report and be willing to help end users who are creating ad hoc reports.

7. Make the context of the report obvious to anyone who sees the report. Use a text box at the beginning of the report to quickly state reporting objectives, authorization, important background facts, and limitations of the data. Always include in the header the date and title of the report. Use page numbers and specify restrictions on distribution and confidentiality.

8. Make a plan. Sketch tables and charts and plan the order of information that is included. Decide what data to put in each report section and decide how to arrange the detail data. Make decisions about titles, headings, and data formats.

IS/T need to work with the managers who will read and use the reports, the problem of bad or ineffective reports is usually "people-related" not "technology-related". Great reports lead to better and faster data-driven decisions.

As always, your comments, questions and suggestions are welcome.


Guide to designing Microsoft Access reports at

Welcker, B., C. Hayes and D. Steinmetz, "Report Design: Best Practices and Guidelines," June 1, 2005, Updated: November 15, 2005, at URL .

Last update: 2007-11-15 10:47
Author: Daniel Power

Print this record Print this record
Show this as PDF file Show this as PDF file

Please rate this entry:

Average rating: 1.13 from 5 (285 Votes )

completely useless 1 2 3 4 5 most valuable

You cannot comment on this entry

DSS Home |  About Us |  Contact Us |  Site Index |  Subscribe | What's New
Please Tell Your Friends about DSSResources.COMCopyright © 1995-2015 by D. J. Power (see his home page).
DSSResources.COMsm is maintained by Daniel J. Power. Please contact him at with questions. See disclaimer and privacy statement.


powered by phpMyFAQ 1.5.3