Stephen Few's remarkable book, "Information Dashboard Design," does many things. It's an elegant exposition of the design issues that drive dashboard usability and an exposition of the "grander" purpose of the visual display of information. It's a beautiful compendium of visual examples, snippets of wisdom and design FAILs. In other words, it's a great book that practices what it preaches. If only most dashboards shared some of these qualities...
As part of a series of posts examining this book in light of the startup universe, I figured I should start, naturally, at the beginning. In the second chapter of his book, Few begins to develop his taxonomy of dashboards. He breaks it down by a number of dimensions:
Role (Strategic, Analytical, Operational)
Type of Data (Quantitative, Non-quantitative)
Data Domain (Sales, Finance, Marketing, Manufacturing, HR)
Type of Measure (Balanced Scorecard, Six Sigma, Non-performance)
Span of Data (Enterprise-wide, Departmental, Individual)
Update Frequency (M, W, D, hourly and Real-time)
Interactivity (Static, Interactive)
Mechanisms of Display (Graphical, Text, Hybrid)
Portal Functionality (conduit to more data, no conduit).
In his view, the strategic dashboard ought to be static (to be extremely usable by the corner-office types) and to be set at the "strategic" time-level. That is, strategic decisions in a business are made over multi-year time frames. Their information displays should accommodate that type of thinking. The operational dashboard, on the other hand, ought to be real-time (expect a post sometime in the future on the role of "real-time" in business dashboards) and very amenable to immediate exploration. I see his view of the analytical dashboard as somewhere between--splitting the difference. Either way, it's clear this hierarchy describes an enterprise level state-of-affairs and not a young, fluid company.
The startup dashboard doesn't care (and shouldn't) for some of these distinctions. On one level, the data domain is blurred simply because those functional departments probably haven't yet been fully built out in the young company. So sales data might sit side by side marketing data (without the granularity of a fully-formed sales team). The VP of product might be moonlighting as the VP of marketing. Software that rigidly separates those domains is bound to do a disservice to the startup team.
On another level, the data frequency should be rather malleable in the startup setting. Sometimes, when running all-hands meetings, longer term views, wider and more contextual slice of information are best. But in the day to day, very fast and near real-time (or real-time) data is a must. The startup team wears more than 500 hats--it has multiple personalities. It must excel at strategic, analytical and operational thinking. And then even those distinctions aren't as clear in the startup rumble.
Finally, I don't even know why "interactivity" is even in question. Unless you're pdf'ing a report, it should be interactive. A good design will make that interactivity subtle and non-intrusive. But in the days of AJAX, it's folly not to at least include it as an option. It's like giving someone a nail without a hammer.
In the next post, I'll explore some of the theory behind the visual perception of information and business decision making in view of dashboards. Should be fun!