Dashboard Roles

"Dashboard" is an interesting name for a UI component, one floated in any discussion about user interfaces today. The trouble I have in understanding dashboards is the same trouble I have in understanding "cloud" — what do they do? Is there a generic version of the dashboard that I could take and apply to the UI I'm working on right this moment? Or, does "dashboard" simply capture the idea that important user information needs to be available to the user, at all times? Still, we're left wondering how to go about providing this dashboard component for application X because we don't necessarily know what information is important to our users, and what information needs to be monitored, collected, and presented to the user in real time.

As a first step in attempting to figure out the dashboard dilemma, evaluating whether your application needs one or not is a likely first step. And an important one for that matter. Why bother with a dashboard component if the very nature of your application doesn't justify having it? If you're working with a single user, or just a handful, maybe a dashboard is overkill. Or maybe there are a ton of users, with frequently changing data — but this data doesn't mean anything to the user. It's mostly about asking the visibility and information value questions that determine whether to include a dashboard in a user interface or not. The visibility question is really just about what information can the users of my system see? We should already know the answer, since we've probably built several other components of the application that require visibility constraints, but asking it repeatedly puts us in the user's shoes. What am I allowed to see? This leads us down the path of summarized, or aggregate information. We could present the user with a science experiment in presenting summarized data that means precisely zilch to them. But again, if we were to put ourselves in the context of actually using the system and thinking about the first thing I would like to see, we get a better sense of what constitutes valuable dashboard data, and more importantly, what can be excluded.

Having decided to include a dashboard in your user interface, the next step is to think about the dynamic aspect of the information presented. Not necessarily a moving line graph showing how the aggregate data changes on a per-second basis, but making a decision as to what gets put on the dashboard in the first place. In other words, not the chart data, but the chart itself. The dashboard is the first thing the user looks at — that's the whole point. It's up to the dashboard to produce the front-page headlines of what is happening. What we generally see with dashboards, instead, is a largely static structure of the same charts, the same lists, and so on. I'd like to see those change. I'd like less content on the dashboard if it meant it was more relevant to me.

But these aren't trivial decisions for the software to make — to try and guess what information will prevent me from having to do more work. And by work, I of course mean, going past the dashboard and sifting through the other components of the user interface to figure out what I'm looking for. The dashboard does the legwork. But it isn't doing any legwork if it constantly produces the same type of information. And maybe that's all that's needed in the vast majority of circumstances — a static structure that simply shows fluctuations in the same class of data. The data types we expect. Looking forward, however, I think legwork of looking for potential issues in software systems isn't going to be an inconvenience, but a real problem. We're so complex with our information structures, that there will be cases where we simply cannot figure out what is happening in a realistic time frame — good or bad. Let's instruct the software to figure that our for us, not entirely, but by taking baby steps to producing more meaningful dashboard information. This information gives us clues, and that's all we really need. The clues only work, however, if they're relevant to the current state of the system, and aren't buried in a mountain of other dashboard data.