July
11
2006
At Emetrics, I presented on the topic of report design. For all two of you who read this blog, weren’t there, and are interested, I thought I’d put up the super-abbreviated version.
These are the basic principles that I apply to every report I ever author.
1
Design for Understanding
Reports, among many other important things are shortcuts. The viewer wants the report to ‘cut to the chase’ so that they don’t have to wade neck-deep through the data. So, I’m always looking to present data, KPIs, analyses, etc. in the most easily digestible way.
2
Design for Impact
Designing for understanding is just a means to an end. Our end goal is to get the report users to take action (the brass ring being the correct action). When designing a report, I am constantly looking for ways to make it impactful – ways to get the users to sit up and take notice of the information and insight it is delivering.
3
Design for Efficiency
The most beautifully crafted and fireworks-generating report will ultimately be doomed to failure if you can’t reproduce it quickly and easily. Because our business is iterative (design, test, measure…repeat) it is likely that the majority of the reports and analyses you produce must be updated on a regular basis. Therefore, if you can’t quickly update the data in the report and get it out, you’ll miss deadlines. If the report is a particularly good one and effectively drives change, then it’s actually hurting your business not to get it done on time.
By the way, these 3 rules tend to be interdependent – meaning that making gains on one often leads to losses in one or both of the others. So, it’s a fine balancing act to adequately meet all 3 rules. However, when it happens, you end up with an effective report design.
It might go without saying, but I’ll say it anyway, when you find something that works – a layout, a component, a color, etc – abuse it. Most of us have more work than we can possibly accomplish so we need shortcuts too.
Hi Clint,
The death and taxes chart seems to meet the first two principles easily. However, it looks like the efficiency principle isn’t met (the author is working on the 2007 version now.)
In your presentation you had many slides on Understanding and Action, but only 1 on efficiency.
How do you build efficiency into each chart you create?
Another way of asking this is, what are the top 10 techniques you abuse when building an efficient chart?
Thanks,
Dylan
Dylan,
Thanks for the question!
I actually disagree about the ‘death and taxes’ chart feeling that it also fails the undersanting rule, but that’s for a different discussion.
As far as designing for efficiency goes – especially for a chart…
This tends to be a tool specific strategy, but in general the basic rules I discussed in the presentation are effective:
1. Abstract the data from the presentation. I tend to use Excel for reporting because of its ubiquity in the business world, so for Excel this means that I keep the data in a seperate worksheet from the report presentation layer (including charts) and leverage tools like named ranges, offset, vlookup, etc. so that once the data has been refreshed in the data sheet, the rest of the report is automatically updated (i.e. I don’t have to update each component that uses the underlying data).
2. Behind that, in the data sheet itself, I use various ways (web queries, pivot tables, etc) to make the data itself a refreshable query.
Again, there are numerous tactics that you can use, many of which are dependent on the platform you are working from, but for efficiency (and your sanity) if you can design the report in such a way that updated data can be pulled/queried through some more or less automated procedure, you’ve won the battle.
It’s important to note that I generally have the luxury (as many of us do) where the data collection is more or less automated and then all we’re doing is querying against a data warehouse, data mart, whatever. In the case of the Death and Taxes chart, I would bet that the author has to compile A LOT of data manually, in which case it’s just going to take a serious manual effort to reproduce/update.
Not all charts are meant to be reproduced on a regular basis (Minard’s is another example, could you imagine if he [somehow - go with me here] had the availability to try and update that chart week-by-week during the campaign? How impossible would that be?)
Ok, long story short…
1. Abstract the data from the presentation
2. Use refreshable queries for updating data
3. Make sure the data is easily available via an automated process – if it’s not weigh the cost/benefit of making it so.
4. If it’s too costly to make the data easily refreshable, weigh the cost/benefit of manual updates
5. If it’s not worth it to manually collect/update the data consider alternative ways (that include points 2 and 3) to approach the same answer. If you can’t do that, then you either have to make the chart a one-off or consider lengthening the lead time (cycle) to each update.
That probably doesn’t answer your question fully, but as I stated at the beginning, the tactics used for efficiency, more than anything else tend to be platform-specific.
-Clint
[...] I’ve said before that bullet charts faced a tough road. Basically, they are different enough to require end-user training which violates my the rules for effective chart design. [...]