Do You Like Dashboards?

Not much happening lately, what with the holiday in the US and the obsession with bargain hunting on Black Friday and Cyber Monday.

A while back, Paul (@ppedrazzi) and I were sharing our mutual unhappiness with application dashboards. They always seem like a good idea for quick and easy information consumption, but inevitably, dashboards are messy to develop and ultimately ignored by users.

I had a revelation over the long weekend, while reading How We Decide; there’s too much information for the brain to capture.

I know, obvious.

Jonah Lehrer discusses the classic assertion that the brain can handle only seven data points at once, which I believe influenced the American phone number sequence, among other things.

And even seven is a stretch, as thinking power seems to decrease dramatically as more data are introduced.

But it isn’t as obvious when you’re designing a dashboard.

Photo by Wayne Silver from Flickr used under Creative Commons

Typically, the requirements for a dashboard are numerous, and since your target user is likely a decision-maker or executive, you want to account for as many as possible.

This is where the problems start because a dashboard needs to present the most relevant information, but accommodating more functionality means decreasing how much the brain can focus on, important or otherwise, rendering the entire dashboard useless.

Couple this with the fact that many users don’t really know what is really important beyond a handful of functions.

Therefore, a dashboard with a bunch of information quickly gets overwhelming.

Think about the cars, the original dashboard. Aside from speed and a fuel gauge, what else about the car is critical. Probably engine temperature, an area for warnings, maybe RPMs. What about time and direction?

That’s already seven pieces of information.

But modern cars go well past seven. If you watch Top Gear, you’ll see how overly complicated cars frustrate their users, and it seems the amount of dashboard information is directly proportional to the cost of the car.

All the really hard work goes into boiling down the many, varied requirements for a dashboard into the no more than seven really important ones.

And that’s really tough.

So, what’s the answer, or do you love dashboards the way they are?

Thoughts? Find the comments.

AboutJake

a.k.a.:jkuramot

15 comments

  1. dashboards in the BI world are probably what you describe. A bunch of reports/graphs/charts/whatever all contained on a single page. I like it, but that doesn’t mean the executive would like it. Of course I’m thinking in terms of web pages.

    What would be kind of cool is to have 7 monitors up on the wall that show a single unit of work/graph/chart/report/whatever. Other than that…without talking to the executive in question or bringing in a true UI designer, I would be hard-pressed to come up with a solution.

    Interesting though.

  2. I wonder if there are two conflicting priorities here.

    On the one hand, we want a dashboard that only provides us with the most critical information.

    On the other hand, perhaps because of the inability to define “the most critical information,” we want to display ALL of the critical information so that we don’t miss anything.

    There may be another issue at work here. If Steve’s dashboard tracks 7 items, and if Bill’s dashboard tracks 14 items, then there’s the underlying assumption that Bill’s job is more important than Steve’s job, since Bill (supposedly) has to track many more things. While some people may praise the focus of an executive with a two-item dashboard, there are others who would regard that executive as simplistic, or even simple-minded.

    (Also see the “my application has more features than your application” debate.)

  3. There’s that mythical executive everyone cites as the dashboard user. I’ve never met an executive who actually uses a dashboard. They push that stuff to managers. If anything executives need less information splatted on a screen and a smarter system that can answer specific questions.

    I’m talking about any dashboard that attempts to consolidate information, including any number of administration consoles. It’s too much.

  4. Almost right, what we want is the critical information, not the dashboard. How the data are delivered isn’t a requirement. But yeah, you got the inability to determine the critical bits right.

    If you read How We Decide, you’ll find that more information pertaining to complex problems actually leads to worse decisions. One example used in the book is buying a car; there are too many attributes to compare, which overwhelms the decision-making parts of the mind.

    Experiments cited in the book show that a distraction can refocus the mind. So maybe, we need to build a dashboard with a built-in distraction feature.

  5. I agree with you. I have come across executives who can parse huge amounts of data and spot outliers, but they always use huge Microsoft Excel spreadsheets! Lol. Even stuff like My Yahoo! I strip down to the basics. It’s just too cluttered with all that stuff going on.

  6. something along the lines of a Single Unit of Work?

    Executives/Managers, both the same to me really. It’s in the visualization though, I’ve seen very few (if any) dashboards that truly work.

  7. Yeah, dashboards and consoles are underserved bc relatively few people use them.

    I think the executive/manager use case rolls downhill until someone finds a way to get the actual data out of the system. How often does this person use a dashboard vs. a hack?

    I’d love to build a Q&A interface instead. I’ll bet execs/managers would actually use it, plus you could put all that BI eye candy/visualizations behind it.

  8. Dashboards are a could do vs. do problem. Pretty much every use case for a dashboard is conditional, could do, might do, etc. No one actually does though.

  9. Looks like a ’58 Vette dashboard. Note that you can’t see the tach in that photo. In the ’63 model year they redesigned it so the spedometer and tachometer were next to each other and the same size. I’ve had several generations – the ’92 was like a jet plane cockpit. Yet, I never had an issue with being overwhelmed with information, and appreciated being able to get to so much of it. In a race car or airplane, there’s all sorts of information, and it requires a lot of training to be comfortable with it. That’s not generally a bad thing, though it can be notorious when it is. Same thing with medical devices, it becomes newsworthy when two devices have opposite interfaces and someone gets messed up.

    I certainly believe in the limited amount of information being beneficial, but the details of the presentation control how the limiting works. You don’t want to be drilling down to find the frickin’ stereo controls while at high speed in the rain (as some German cars especially are known for).

  10. Whether or not you were overwhelmed isn’t really the issue. How valuable were each of the controls? In a jet, very; in a ‘vette, it varies.

    Even so, a physical dash is constrained by physical costs, materials, testing, regulations. In software, the dash isn’t constrained, which leads to too much. Plus, people’s attention spans are shorter and divided. In a car, there’s much less to distract you, and you’re captive.

    Can you tell I don’t like the metaphor either 🙂

  11. Yeah, I’ll bet it would work, but implementing it the right way would be very hard. Plus, no one would take it seriously bc work is serious business, not fun.

  12. Nice article. I stumbled across this when I was researching for a similar topic- a post entitled “Which chart should I use and when? A guide to dashboard charts”. You may be interested in reading it considering your interest in this area. I would welcome your thoughts on it too. You can access it here: http://bimehq.com/data-visualization/which-chart/

  13. Wouldn’t say you stumbled across it, since it looks like you actually wrote the post and work for the company 🙂

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.