A Few Words About Dashboards
Living the contractor life as I am now, I get to work directly on client projects in ways that I never got to when I was a salaried employee and truth is…I love it.
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.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Would love to see some examples of what you consider to be “good dashboards.” So many that I’ve come across are poorly designed or don’t fully capture the information needed. It would be interesting as well to hear your thoughts on how dashboards drive behavior. At the executive level? The Developers? The Customer?