Publishing . . .

What Do I Need to Consider When Publishing Reports?

We complete the suggested reporting requirements, broken down by Technical Architecture, Publishing Environment and User Experience:

User Experience

  • Navigation - Report users need to be able to select one report out of a larger set. If you have more than, say, ten reports it is not sufficient to just present a great big list of titles and invite users to click on one. You will need to implement a navigation mechanism, such as a nested heirarchy. Figuring out a sensible way of doing this (eg. grouping by function, department, report type, user type) is an art in itself. Also, you may need to provide some sort of search facility, since users may have access to more reports than they can really comprehend. This leads to the question: search by what? Title? Subject? Date?
  • Report Parameters - Depending on the contents, users may expect to be able to select different parameters of the same report. For example, they may wish to modify start and end dates, or include/exclude certain regions. When allowing users this functionality it is important to ensure that all possible combinations of parameters are valid (won't break the system) and meaningful (won't mislead users). Also, at some point parameterisation and navigation can become blurred and confusing for novice users.
  • Preferences - Sometimes users may require the ability to modify how information is presented to them for a particular report. For example, changing the column order in a table, or the colour of line on a chart. While this empowers users, it can also be abused by report designers by absolving them of the responsibility to find out about the underlying user needs. In understanding why a user wants to reverse-sort a certain table by date, a report designer can better support them in their work.
  • Fault Reporting - Let's face it: any real-world system of even modest complexity is going to have faults or failure. You need to have mechanisms in place to capture these events and track them over time. This will help prioritise repairs or changes, gauge the impact (extent and severity) on users and, ultimately, the success of the initiative. In addition to the usual system-level logging and exceptions that modern IT environments provide, you also need to consider those failure events which, by their nature, cannot be logged. Depending on scale, automated "user-experience" monitoring by bots may be a good idea. But there's no substitute for keeping your ear close to the ground and listening to their concerns directly. Hence, formal (or informal) user surveys are the way to go.
  • Change Request - It would be overly optimistic to assume that the reports will be perfect on the first go. Or that reporting requirements won't change over time. To recognise this reality, you need to have a process to allow report users, data suppliers and other stakeholders to lodge change requests. This should include (at least) the following elements: reason for change, impact analysis, agreement on who's going to pay for it, cost estimate, priority, roll-back plan, notification/approval plan. Changes can be politically fraught when multiple users access the same report eg Making subtle changes to the business rules used to derive a key business metric. In this case, a clear understanding of who owns (and pays for) the reports is paramount. Remember, he who pays the piper, picks the tune.
  • User Training - An often overlooked element. Users need to be explicitly told - or even better shown - how to access their reports and use the navigation and other features to get the most out of the reporting application. It would be a travesty to waste a large amount of your organisation's time and money on a project only to see it fail for the sake of a few hours of instruction to the people meant to use the reports. Beware project managers or vendors who deny the need for training on the grounds that the interface is "intuitive" or "just like the last system". The correct response in this situation is "oh good - then the user training will be a breeze."
  • Usability - Many people, especially in the finance and accounting community, neglect the usability of their reports. This may be because they have "standard" ways of preparing and diseminating information that is so in-grained that any problems outsiders have interpreting it is regarded as "their problem". The danger is that important information is misunderstood or its significance is lost on a wide-range of decision-makers. Hence, there's no substitute for a properly conducted usability study. Ensuring that subsequent reports comply with usability guidelines and standards is the best way to monetise this investment.