>They also employ UX techniques that dates from a time where the only UI component you can use was a light bulb. If that red thing is critical, can’t you tell me right away what it means?

This annoyed me a little bit. A check engine light is the perfect component for what it does. If it's on it means that something may be seriously wrong and that you're probably too stupid or ill-equipped to fix it.

If it was something simple, easily detectable and fixable it would have its own light, ie the door is open, you're running out of gas.

Most articles are shitty, this is an example of one.

Most technical articles are written by someone blinkered by their specific experience which they feel is so wonderful that they should share with the world.

Save the internet from such dross and write it on a piece of paper, roll it up and shove it up the ares your talking out of.

There seems to be an attitude throughout the article of "users are too stupid to understand dashboards", and maybe this is true to some extent, but that's really not a good reason to dumb-down interfaces (which seems to be what it's calling for.) E.g.

You have no idea what your users will decide based on the data you are showing them. But you somehow assume your users will know.

My eternal gratitude to anyone who can tell me what to do with session duration at the hourly level. “People at 4:53AM on Monday stayed longer on the site than at 11:36AM”? So what?

Just because you don't know what to do with the data doesn't mean the same applies to everyone else...

I recommend two resources on creating dashboards, both from very experienced practitioners:

1) http://www.kaushik.net/avinash/digital-dashboards-strategic-...

2) Information Dashboard Design by Stephen Few - http://www.amazon.ca/Information-Dashboard-Design-Effective-...

Am I the only one that doesn't get the joke about what's wrong with "Last 14 days" and "Last 12 months"?

Not all dashboards are shitty or useless.

New Relic comes to mind, and it's a tool I've found hugely useful.

While it doesn't instrument full system monitoring (though it's getting there), it provides numerous system and site metrics, monitoring, and a useful degree of logging, that's hugely useful.

One of the biggest gains for us came when it implemented JVM heap monitoring. This is possible through jconsole, but jconsole is a steaming heap which if it were actually made of sht would be useful as it might provide fertilizer. It's a Java app itself, has no persistence, must be running to tell you what you need to know, presents its own security vulnerabilities (if you can attach jconsole to your JVMs other JDK hacks can as well), and more. Given the critical nature of heap and GC operations to site performance, having the insight through NR, and not having to rely on desktop jconsole sessions (for each member of the admin team individually, oh yeah, forgot that one) was a huge boost.

And the NR team both understands the tech they're monitoring and works with clients. So many of the stats provided are* actionable.

Srsly, this article seems littered with so many assumptions it's hard to decipher the actual point.

Tachometer has no use? Tell that to professional drivers.

Real time stats are worthless? Not unless you expect a spike in your server load (?) and need to react to it immediately.

If you can't find a use for some number, others may. That's what controls are for. You take the set of data your app (or whatever) has to offer, then you toss in some controls (your job is to make them intuitive so user does actually use them without tears) that can operate on and present the data and then everyone gets to choose what they see.

Bottom line is that the only way you can figure out that something is right for each individual is to give them a choice. The whole no one needs X seems far-fetched (to say the least). Sure you need to talk to users, but they most likely will express different opinions.

Also, don't build more dashboards. What? So we shouldn't improve on our mistakes, right? The concept is so bad that we shouldn't even try because no one (again, assumptions) can build good dashboard. C'mon..

I was hoping for an article that would explain how to design a good dashboard. This isn't it.

>"Corollary: No one needs real-time"

If you've ever run service where you're anticipating a large traffic spike and you need to monitor server stats, real-time statistics are invaluable.

>"Most KPIs (traffic, revenue) are too volatile on a daily basis to be useful. Yet “last 30 days daily” is more or less the default option."

YES! If you're building a dashboard, don't answer the question "what data do I have?" or "what does the brass say this should be?" But instead, get out and talk to users, find out what data is most important to them, think outside the box, throw some different ideas out there and see what sticks with users.

> Or because the exec team somehow thinks “we need a dashboard”.

I think many have recognized the demand for dashboards and sprung a cottage industry around it. That is demands often are perverted and sometimes it just comes from an exec wanting to see some "action" or gaining "visibility". They have VC money to spend and will spend money for moving "realtime" colors on the screen.

For the dashboard creators, that is all they need. If someone buys is it. They will keep making it.

On other hand, to disagree with the author. "So what?" People want shitty realtime moving colors because they look cool. Heck, have you seen the crap people pay for in app stores, farmville type games on Facebook and so on. One can criticize the providers and consumer of that crap. Yet they are happily transferring money and product between each other.

From a product perspective, dashboards are pretty much expected and required. If you're building something in the 21st century, people expect a central thing that tells people what's going on. If your answer is 'hey dashboards are shitty', customers can use your competitors shitty dashboards and at least feel like they have more insight into whats going on in your product.

Dashboards are a visualization and interactive tool and like any tool have better and worse uses.

While the OP hits lots of points squarely, I strongly disagree about the "no one needs real time". In particular, any service that does onboarding or signups would be really well served to track new users through the getting started process.

I live in the custom dashboard that I built for my startup.

Screenshot: https://www.evernote.com/shard/s16/sh/c8cdeadc-643d-4028-b58...

It tracks every single signup from provisioning through to successful setup. It lets me easily see if people are flailing trying to get things working and if it looks like they are I send them a personal email like: "It looks like you might be having some issues with picking an email approver address, can I help?"

Having this real-time insight into customer issues lets me provide much better support and from an ROI basis is incredibly worthwhile.

The actual service: https://addons.herokuapp.com/expeditedssl

> Yes, back-end applications need ways to show their users that they’re working

This is probably the only reason many dashboards exist. They're not there to be useful, but to provide proof that the gears are turning behind the system.

> My eternal gratitude to anyone who can tell me what to do with session duration at the hourly level. “People at 4:53AM on Monday stayed longer on the site than at 11:36AM”? So what?

This is so arrogant. If your customers are not interested in target demographics then ok. Generalising this to everyone is not ok.

I agree 99% of the time.

That said, I have an amazing PM who has customized the living heck out of our TFS Dashboard such that it is useful.

Most fun of all is seeing our "daily bug resolved as fix rate" and "daily bug incoming rate". Seeing them as flat numbers in boxes is, IMHO, more useful than seeing them as on a graph.

But yeah, the dashboards I see other teams using? The worst is a bug tracking dash that is updated once every 4 hours. During crunch week, it serves to do not but spread chaos and confusion.

"Take care dashboards for example. They use vast amount of real estate to display information that is useless 99% of the time. How often do you need to know the RPM on an automatic car? Can’t you just take that stupid dial out and put something useful instead?."

Assuming the author meant car, this would be very dangerous (i.e. irreversible engine damage): http://en.wikipedia.org/wiki/Redline

Nobody mentioned astrology or dilution of responsibility?

Dashboards are an astrological tool. Here is an elaborate and complicated process you don't understand to generate numbers that are devoid of meaning, to dilute responsibility when you make a decision that turns out to be wrong.

The article misses this point entirely. A good dashboard from the end user perspective can be used as numerical backup for any arbitrary decision at any time. The author just doesn't get it. Thats why the author is confused by the "just keep adding stuff until I can always use it to justify whatever I want to do".

This is how dashboards are used in practice, this is their actual reason for existing. This is why money is spent on them.

The article is like a debunking of astrology, "well see here, based on the gravitational constant and the distance to this orange vs venus, the square results in ..." and the boss replys with "shut up I don't care about reasons I decided to go to war with eastasia and we've always been at war with eastasia and my astrologer always had my back, and apparently you don't, so lets discuss the effect of all this gravitational formula stuff on your career prospects vs backing me up which you're paid as a yes man to do..."

So, has anyone a constructive article/site/book for good dashboard design? e.g., how you should deal with the mix of daily and monthly data?

I've found that replacing a fancy dashboard of key stats with a simple daily email with 5-10 key numbers is far more valuable.

The dirty little secret of the business intelligence / dashboard industry is that no one logs into them.

A daily email helps with this problem, as people tend to read emails, even if its only a glance.

What are people's favorite examples of good dashboards?

I rail at Google Analytics dashboards all the time. You'd think I would be interested in today's or this week's or this month's numbers, yet there are no options for this in the calendar widget. People who write these things not talking with people who use these things in a meaningful way is a classic type of fail.

My main gripe is with "static" dashboards, i.e. dashboards that don't let you drill down (e.g. to investigate an interesting spike), and has disconnected widgets (i.e. applying a filter to one widget doesn't affect the other widgets).

I completely agree. Most information is nice to know but not actionable at all. It's the reason why we don't have any dashboards. Just periodic updates (weekly and monthly) in static PDFs.

Nothing real time, no dashboards, static data, but customers love it.

I suspect the author is probably right but didn't glean much actionable from the post.

Data Scientist here. Can confirm, most dashboards are shitty. Usually you don't need a dashboard, you need a human who knows how to analyze data to get useful information out of it. A dashboard is not an end goal, an informed decision is.

Read Lean Analytics: http://leananalyticsbook.com/

It mentions the OMTM, One Metric That Matters. When you focus your effort to one number, things get much better.

Dashboard in 1950's GMC trucks is solid. Just two dials. One for speed, the other displays 4 types of engine data.

http://i.imgur.com/g9RUbiF.jpg

Important take-away I've found from building monitoring software: find a way to determine what data your users don't care about and de-emphasise or all-out hide it.

Any examples of great dashboards that people love?

Jira dashboard is actually useful. At least when you choose the right widgets.

Tableau is an awesome data aggregate and dashboard program.