Example of dashboards…good idea! I’ll see what I can find to post. In the meantime I think the question about how dashboards drive behavior is a good one and is tightly linked to design. I think it’s most useful to back into the answer, however. In other words, rather than designing a dashboard that will drive the right behavior, the right behavior needs to be defined in order to design the dashboard.  The easiest way is to ask:

“What decisions will be made from this data?”

Decisions made from data are usually some version of ‘course correction’ or ‘go/no go’ decisions. So a dashboard that drives behavior is one that provides exactly the right data to inform those decisions.

The other necessary moving part is knowing what warning thresholds to set so the data is properly displayed. If the possible scale of responses on a fictitious measure is 1 – 10 (where ten is perfect, and one is complete failure) the dashboard design needs to accommodate the warning threshold. If the target for that fictitious measure is 7 (of a possible perfect 10), then there may need to be a warning when it reaches 8. Thresholds are highly subjective and need to be tailored to the dashboard user. In that example, a warning at 8 may be sufficient, or it may be appropriate to set the threshold at 9.  In all cases, it comes back to the ‘what decisions will be made?’ question and more specifically asking what action will be taken on the threshold warning. So if 7 is the target, what action will  be taken when the score is 9? If none, I would recommend trimming the warning threshold closer to the target (8).

The obvious comparison/metaphor is that of an actual stop light. The timing of a yellow light has some relationship to the speed limit on that road (I assume). On a road with a 25 mph speed limit, a four second yellow light is probably sufficient. On a road with a 60 mph speed limit, a four second yellow light probably doesn’t allow sufficient time for a course correction (slow down and stop).

*Side note* In an incredibly festive example of using your data power for evil instead of good, here are some stories of cities that deliberately shortened yellow light times and then installed traffic cameras to ticket red-light-runners as a way to increase revenue! Brilliant! (although unethical)

So those are my convoluted thoughts on dashboards that drive behavior.  In short:

• Define what action will be taken (or is expected) from data and model the data display to that action.
• Clearly define the warning thresholds
• Avoid (at all costs) data for its own sake.

~Geek~

Right now I have two projects for completely different clients that are both dashboard projects. Also interesting is that the development and delivery of the dashboards is all happening at exactly the same time. So literally, I have to sometimes look up at the logo on the dashboard to see which project I’m working on. I haven’t messed it up yet, and think I’ll remain safe.

But, I’ve gotten the chance to think (and read…thanks Stephen Few) a lot about dashboards lately and have had to bring some dashboard prototypes  to non-data stakeholders and get their feedback and approval.  This has been a great experience at executing a useful design when there are so many conflicting opinions.  Here are some learnings:

One-page dashboard – Everyone seems to agree that a best practice is for a dashboard to be viewable on one page. Dashboard design goes from data collection to design at this point. But I haven’t found anyone yet talking about the reality of this requirement. I work in three places: my home office, my client’s office and on my laptop. Each one has a different screen size. My stakeholders all work  on a combinaton of laptops and desktops some with widescreen monitors, some without. Add to that, one of my stakeholders (like me) keeps her screen resolution relatively low so she doesn’t have to squint at the damned screen, so that changes it as well.

Short answer is that I’m designing based on where my primary stakeholder mostly will look at the dashboard, realizing that there will be some times where scrolling or excessive whitespace will be present. Whatever…I’ve moved on.

Linkages - Although not part of Stephen Few’s book, but present in lots of other methodologies (particularly Balanced Scorecard), is the design choice to illustrate the linkages between activities and key performance indicators. In regular reviews of the dashboard, my recent designs encourage the user to start with the KPI on the left and track along to the activities that are supporting that KPI.  At the speed of business these days, initiatives come and go so quickly that you barely remember at the end of the month what was keeping you up at night at the beginning of the month.  So the greatest value in displaying this linkage is getting to ask yourselves and your team how your activities are driving the key performance indicators of the business. This allows the team, in times of scarce resources (hello recession), to prioritize activities to those that will directly drive the business. So more than just a read-out of data, the dashboards I’ve designed recently really illustrate the link between activities and bottom line results.

Working document – We’re all awash in reports. Reports of status, reports of progress, reports of re-forecast (when status and progress aren’t what was planned). These are one-time outputs of data in order to tell a story and are important for that reason. The stories we tell about our work environments help us make decisions. But these are rarely working documents. What I mean here is that a dashboard (in this example) should inspire conversation, present questions, stimulate thinking…and it should also morph and change as the needs of the business change. One of the most useful conversations with my stakeholders on these two projects has been to ask them whether they wanted to use the dashboard as a reporting vehicle outside their organization or to use it as a decision making tool within their organization. Given that both folks were looking for decision making tools, the dashboards I’ve designed for them are meant to grow and change as their organization and priorities grow and change. The challenge was to develop a streamlined product that also lent itself to easy updates.

The good news is that both of these dashboards are nearly complete for version 1. The even better news is that at least with one of these projects, I’ll be producing the dashboard monthly and getting direct feedback on it’s utility so I’ll be able to make design changes that meet the stakeholder’s needs for up to a year. I wonder how different the dashboard will be in a year from where it is today! This should be a time capsule posting that I look back at in 12 months to see what’s changed.