More often than I like to see it, I receive sample reports (usually as part of a bug report) that makes me feel sorry for the poor souls receiving the resulting documents.

Reporting is as much about numbers as it is about conveying a message effectively. Yes, it is possible to just send out a flood of numbers in a 100+ pages document and let the receiver mine for the right information. But in most cases, such reports simply never get read.

Remember: Data is not information.

Data is just random facts thrown out into the world. Information is data put into a context that makes sense to the receiver. Don’t send out data, send information.

A simple way of doing this is to begin from the end. Don’t think about what data you can push out, think about what information the receiver of your report needs and what they are supposed to do with it. And then either cut out everything that distracts them from the core message. Or, if you are required to put all your raw data into the document for legal or organizational reasons, at least produce a short summary with information and put the data into an appendix.

Choosing the right data for a maximal informative report is only one aspect of making good reports. The important parts need to be properly emphasized. Your reader needs to be guided by layout and structure. Your report must be understandable – hopefully at the first glimpse, or it will be filed under “read later”. And ‘later’ never happens anyway.

Good design is not a magical thing and you don’t have to be an expert to make a report that looks decent. Most design guidelines are rather complex and not necessarily practical. This video here is.

Idan Gazit’s talk “Design for developers: Making your Frontend Suck Less” contains some very basic (and extremely helpful) design advice. Even though he talks about web-applications, the majority of his advice can be easily applied to the design of reports.

Idan Gazit’s talk “Design for developers: Making your Frontend Suck Less”