2
min read

Exceptional Reporting Using Exception Reports

by Martin Ho , 04.06.2012

This article is re-posted from User Centric’s blog.

Optimizing how people view and consume data is not new to the field of UX design.  Effective methods to enhance the consumption of complex data include the use of a wide range of data visualizations.  There is plenty of literature on creative and powerful ways to represent data but far less on what I will consider exception reporting.  Exception reporting is opposite from the general practices of presenting data in whole; it is about only displaying data points that are exceptions to rules for the purpose of empowering users to make critical decision and/or actions.

Traditionally, users sift through extensive reports and large sets of data and information in order to identify problem areas.  The reality is that users are typically searching for a specific pattern in the data or for numbers that are above or below a specific threshold.  Exception reporting is about flagging key data points and minimizing the manual searching through traditional reporting methods.

Exception reporting is not a new concept.  Credit card companies use exception reporting for fraud prevention and protection.  You’ve experienced this if you’ve ever taken a road trip and swiped your credit card to make a purchase only to find the card flagged and funds frozen. This is the credit provider’s algorithms acting on anticipated spending behavior. Non-profits and fundraising organizations also use exception reporting to identify likely candidates for donors. Even athletes use exception reporting to determine what variable(s) factored into their latest personal record.

What does exception reporting look like, and how is it different from traditional reports?  Let’s imagine that a company anticipates spending $100,000 per month on corn with a variation of 10-percent given market volatility.  A traditional report would look like an annual forecast, with some months within the plus/minus 10-percent, while other months will be above or below this amount.  What does the user do with this report?  The user will likely sift through the many numbers to identify the numbers that exceed $110,000.  An exception report simply displays the months that are above or below the 10-percent threshold, thereby eliminating visual scanning and optimizing the overall user workflow.

Some might argue that simply color coding exceptions within a more detailed report would accomplish the same end user behaviors.  However, the end user still has to decide the difference between the colors.  The numbers within the normal range (the non-exceptions) simply add noise and should be removed. Often, I provide report users the ability to view non-exceptions, but default to an exception-only view.

Perhaps the strongest case for using exception reports is when systems allow users to define their own threshold(s) to determine exceptions.  The ideal report is a hybrid one, where organizations provide initial guidance on threshold levels and users make adjustments based on their individual needs. This gives report users the power to say, “Here’s what’s important to me…”  The system then ‘does the work’ for the user and reduces workload.

I view exception reports as the front line of any reporting tool.  Whether on a dashboard or a report portfolio, exception reports are the starting point from which users dive deeper into the data for more information.