Dashboards as To Do lists

As a programmer, it’s easy to think of a dashboard in a few ways:

• Enough charts and numbers until it feels about right;
• A deliverable you need to produce because a manager or client has asked for it;
• A chance to show off your graphic design skills;
• A chance to impress with the wealth of data that you command.

I think these are all unhelpful.  I prefer thinking about a dashboard as a To Do list for someone.  Strictly speaking, it probably adds tasks to someone’s To Do list rather than being all of their list, because the person probably also get tasks from elsewhere too.

The user looks at the dashboard, interprets what they see there and as a result has tasks that they need to do.  Sometimes the dashboard might not lead to any new tasks because all is well, or it will change existing tasks rather than create new ones, but in general the dashboard will change what they need to do.

It’s worth digging into this a bit, as that can expose some useful ideas.

If a user will never have tasks to do because of the dashboard, and no existing tasks will be changed, then what is the point?  Maybe it’s targeted at the wrong person, or showing the wrong information or showing information in the wrong way.  It might not even be needed at all, so the work of the engineer is up front, to clarify the request for a dashboard.

One sign that a dashboard is working well is that the interpretation that produces tasks is as quick and easy as possible: Here are the tasks, here is their relative priority, and here is the context you need to work on them.  It’s as if the total work of turning data into tasks is an iceberg – the bit below the surface is done by the dashboard engineer ahead of time, and the bit above the surface by the user when they look at it.  You want as much to be below the surface as possible.

A key bit of information that helps with reducing the interpretation effort is understanding the user.  Who are they, what’s already on their To Do list, what’s important to them etc?  (I go into this in more detail in Visualisations and the stories behind them.) A dashboard having a single user is a special case; more likely is that several people look at the same dashboard.  How similar are they?  If they are too different to each other then their needs might not be met well by a single dashboard, and you need to specialise things into two or more dashboards to fit the sub-groups of users better.

Instead of building a dashboard that leads to tasks, can other (non-dashboard) code be built that deals with things automatically so that no-one gets a task?  For instance, instead of reporting the errors thrown up by a process that now need someone’s attention, you might be able to adapt the process so that errors are prevented or handled automatically.