Evolution of a dashboard design

You’ve built your application and launched it. Now you need to know what’s happening. Google Analytics will tell you who has been to the site, and if you know your stuff you’ll have set up goals and events so you can see how your sign-up process works. Beyond that, general purpose analytics packages begin to fail. As the web has evolved, page views have become less relevant. Unfortunately web analytics as we know it is rooted in the assumption that page views are the atomic unit, and that they mean something to the application. This is simply no longer the case. There are hacks; you can augment every line of code in your application to create virtual page views or trigger events so you can catch whats happening, but this results in dirty code, unreliable data, and a really messy way to measure your application’s progress.

Building your app dashboard

It’s difficult to build a dashboard, without needing one first. This is why I think it’s a waste of time to build one before you have any customers. Inevitably you end up over-designing something that is impractical and showing you the wrong data. Once customers start using your application, you’ll have a much better idea what’s relevant and how often you need to see it. Even when the customers roll in, I’d still advise against building anything too fancy too soon. Here’s roughly how I see your needs and thus your dashboard evolve…

1. One step above select COUNT(user_id)

For your first month or two you usually don’t have enough data to gather any insights or make any predictions. The early stages of growth are too easily skewed, you might get some love on twitter one day, followed by a popular retweet the next. It’s difficult to call this growth, especially when you’re offering a free trial. Often I read about entrepreneurs calculate the percentage difference between day 1 and day 2 as if it’s significant. Spare yourself the Fisher-Price statistics and focus on getting the data that matters

At this point I’d go with a simple day-by-day dump of your key indicators. It’s silly to just count #signups as that alone means nothing. What you need are engaged active customers, otherwise they’ll all cancel. You need to measure what are good indicators of activity. For a project management tool this might be number of projects created, number of invites activated, number of messages posted. You should be happier with ten very active users, than with one hundred zombies who logged in and left.

2. Aggregation

At some point over the course of a few months your dashboard will (hopefully) become too much to digest. You’ll no longer be able to simply eyeball the data, so you’ll need a way to digest it quicker. Simple totals and medians will show you what you now need to know to measure progress more effectively. I say medians for a reason, the median is a far more relevant number to look at. As Hans Rosling said, the majority of us have more than the average number of legs. You need to know what most people are doing, without letting one heavy user skew your data.

3. Trends

These days when people think dashboard, they tend to also think infographics, sparklines, and tightly kerned bold Helvetica all that stuff that Smashing Magazine loves. Luckily it doesn’t need to be this fancy, unless you have pots of VC cash to burn this quarter. As you approach the end of your first year you’re now looking for at-a-glance information showing your growth (or lack of) over a period of time. Highcharts is an excellent piece of software for getting you usable readable charts without difficulty.

4. Insights & actions

The dashboard we’ve designed thus far shows us the “What”. What’s great to know here is the “Why”. That’s where real power comes in. It’s all well and good seeing stylish spikes, but what you really want to know is why. Once you can see that advertising on the Deck failed, or a mention on StackOverflow attracted tonnes of signups that can inform your next actions, whether it’s to advertise more, blog more, or simply just participate in a community that’s talking about you.

The purpose of a dashboard, above everything else, is to surface actionable information. What’s happening and what can I do about it? Google Adwords “Ideas”, shown below, does a great job here by presenting you recommendations implementable with a couple of clicks.

5. Making Projections

A complete dashboard can help create predictions about the future, and offer you some level of confidence about the predictions. There is real power in being able to answer questions such as “When can our application afford a visual designer” or “How long does it take us to re-cycle our marketing budget”. There is integration work required in getting this far, that’s why it’s most definitely something you build later down the line.

There is lots more you can do with your business dashboard, but the above is my recommendation for what to build, and more important when to build and in what order. The good news is you might not have to build these tools for much longer however.

Dashboard As a service

I’m sure in time a service will emerge to kick Google Analytics from its drunken slumber. In particular I like Mixpanel for it’s easy ad-hoc configuration, Chart.io for it’s direct connection to the data (no code tagging), and StatsMix and Geckoboard for their “integrate with anything” approach. There will be many more to come, if you’re building one please let us know on hacker news.

Real time or Fake Time

Right now, “Real Time” is where it’s at for this space, it’s one of the most frequent feature requests you read on Hacker News. The caveat I’d offer here is that real time is only useful when the company is in a position to make significant changes in real time. More often it’s a vanity metric, the modern site site counter, which people gaze at for hours, before realizing that a daily total is probably more useful. There is a woeful irony in an application owner obsessing over his/her “real time” page views but taking three days to respond to its customers. Don’t be that guy.

Follow @destraynor on Twitter, or read the Follow up post: Infographics and Data Visualisations