October 22, 2007

...Learn TDD with Codemanship

You Are All Crap (And Other Dashboard Faux Pas)

Aside from getting burgled last Friday - which is a lot of fun, I can tell you - I have also been suffering from an outbreak of dashboards.

The purpose of a dashboard, according to the Concise Dictionary of Things Jason Has Just Decided To Make Up a Definition Of, is to provide an at-a-glance picture of the state of some more complex entity - like a car or software project, for example. This is usually for the purpose of control.

The basic idea is that we take some action, then the dashboard gives us easy digestable feedback as to the consequences of that action, and - based on that feedback - we take another action, and get more feedback on that. And so on.

This only works, of course, if:

a. The feedback is both reliable and meaningful, and
3. The feedback is timely

A badly designed dashboard can cause all manner of shenanigans. Imagine a dashboard designed to help you manage your lawn, for example. You might want to measure the length of the grass. The might want to measure the greenness of the lawn. You might want to measure the coverage of the grass - how many blades per square foot of lawn.

But being told in late August that "your lawn is dead" won't be of much help if you really needed to be watering it in July to prevent that from happening. Or being told that your lawn is 127m above sea level and has a surface temperauture of 290.2 K, no matter how timely that news might be.

To be of practical use then, a dashboard needs 3 things:

1. Cognitive Simplicity - you should be able to digest the meaning of it in a matter of seconds
2. Timeliness - the information should, as much as possible, be a reflection of the reality now
3. Actionability - (yes, that's a made-up word) - you should be able to take some kind of action to correct any problems revealed by the dashboard

But there's a lot more to dashboard design than that, too. You also want a dashboard that is friendly - being viewed as helpful, unthreatening and, wherever possible, constructive. The dashboard in your car is probably like this. When you're running out of gas, a friendly little light might blink on to alert you, for example. And it will probably be drawing your attention to a picture of a petrol pump, thus highlighting a potential solution, too. You might be less comfortable with a dashboard that tells you that "you are a crap driver" or that "you're going to get stranded in the middle of nowhere!"

Shamefully, many project dashboards I've seen lean far more towards the "you are crap" or the "PANIC NOW!" school of feedback - neither of which is especially informative or helpful.

So, I need to add two more requirements for a good dashboard design:

4. Constructiveness - it should point you towards practical improvements, rather than just damning current performance
5. Approachability - it should not be threatening or put people off seeking feedback

And finally, we have to think of practical considerations. Maybe the perfect metric for our dashboard is number of elephants in Africa currently facing East, but how much hassle and expense would be involved in collecting that measurement every week?

In my experience, a dashboard that takes a team more than 20 minutes a week to run - including taking the measurements, capturing the data and producing the friendly visual representation - is one that's likey to end up being dropped as soon as more pressing work arises.

Which adds one final requirement to our list:

6. Practicality - a dashboard needs to not be a burden on the people who manage and use it
Posted 13 years, 1 month ago on October 22, 2007