In one of my regular attempts to scan news articles about data visualization, on February 21 I ran across an interview with John Kopcke, the CTO of Hyperion Solutions, written by James Murray in IT Week. In response to the question “What…innovations are encouraging enterprise wide deployment of reporting tools?” Kopcke responded: “Role based dashboards that only present information the user needs to perform their role are a key development.” I couldn’t agree more. In fact, in my opinion, anything that calls itself a dashboard but doesn’t specifically support the information needs of a particular person, group, or role doesn’t deserve the name. Too many organizations are getting into trouble by trying to develop “the corporate dashboard”, as if a single dashboard could support the information needs of an entire corporation. A dashboard is only as useful as its ability to support the real information monitoring needs of one or more real people doing real jobs. To do so, a dashboard must be customized to support individual roles.

I was disappointed, however, when I read on and found Kopcke advocating an approach to the development of role-based dashboards that I find untenable:

Traditionally, if you wanted to deploy role based dashboards you may need 2,000 different dashboards which would take forever to put together. But the way we do it now is to have a library of dashboard components and you pull those components together to create the dashboard. We could extend that model to an on demand basis so we provide the components to the customer and allow them to assemble the dashboard so they get the uniqueness required and we keep our costs down.

I doubt that any company has ever tried to deploy hundreds or thousands of dashboards without using some method that involved reusable components. Dashboards are still in their youth and as such lack a legacy of primitive methods. This is beside the point, however, for my primary objection to Kopcke’s vision is that information consumers–the people who use dashboards to do their jobs–rarely know how to design dashboards. Based on what I’ve gleaned from frequent visits to dashboard vendor Web sites, even the so-called experts don’t know how to design dashboards that result in clear and efficient communication.

Providing people with a library of dashboard widgets, one for every possible data display that they might need, would present them with an overwhelming set of choices. Even if end users could navigate these choices, they wouldn’t know how to assemble them on a computer screen in a way that didn’t end up looking like a disorganized, cluttered mess. The visual design of a dashboard requires a set of design skills that must be learned. They certainly aren’t intuitive. Someone must be part of the process who has the expertise to design an aesthetically pleasing dashboard that is visually arranged to support varying levels of importance, meaningful comparisons, and a sequence that matches the way the data will be used. Think about this the next time you board a commercial jet, grateful that the pilot didn’t design the cockpit based on a library of dials and gauges that he had to arrange himself.

For years BI vendors have been promoting the self-service nature of BI. Those of us who have actually had to implement these systems, however, know what a pipe-dream this will remain as long as the tools are clumsy to use and the users lack the data analysis skills needed to use them knowledgeably. The plug-and-play approach to dashboard development seems a lot like the familiar self-service dream of BI–a nice idea with good intentions, but simply not practical.