The Demise of the Personal Dashboard

TL;DR: When building consumer applications, favor simplicity over complex personalized dashboards which bombard customers with information.

3 minute read

I was recently asked how I would architect a personalized dashboard experience for visitors to a large, customer-facing site. My response? I wouldn’t.

A dashboard in a car or airplane makes sense. It’s not as if I could click “speedometer” while driving or press the “altimeter” button while flying. I simply need everything at all times. But virtual interfaces don’t have that same limitation. In fact they don’t have any limitations. A dashboard can have as much information as the most ambitious engineer can dream — and that’s exactly the problem.

Put it in context: Google recently announced the retirement of iGoogle, it’s own personalized dashboard, and I second their nomination to induct dashboards into the #doingitwrong hall of fame, joining the likes of internet portals, splash pages, and well, basically anything involving ActiveX or Flash.

Dashboard were a fun user interface experiment. They really were, especially compared to the static pages they evolved from. That was the whole point of Web 2.0, wasn’t it? Personalization? I mean, it was really cool to drag and drop widgets, and build a virtual command center to monitor my little corner of the internet, and that was fine when there wasn’t much internet out there to monitor. But the web collectively hit a tipping point a few years back. From push notifications to always-on email, in more ways than we imagine, we now bombard ourselves with more information that we can physically process at any given moment. Quite literally.

Think about it this way: when customers come to a site, they’re not looking to solve 10 problems. They’re looking to solve one. They don’t want all the potentially relevant information thrown at them all at once; they just want what they need. And they want computers to make that determination for them. But hey, this isn’t the first time those who predict our user experience needs have erred on the side of moar is better.

So that’s it? That’s the end of simultaneous streams? Far from it. This once-disruptive technology now has a long journey down the Technology S Curve as it becomes the go-to solution for all the business intelligence and project analyst types that stumble across it, in other words, the late adopters.

Don’t get me wrong. I’m sure guilty of building a dashboard or two in my day. I’m not saying that they’ve never had a place. What I’m saying is that today, not even the most complex dashboard could give you an accurate snapshot of its genus’s future. If not dashes, then what? Beyond turning everything into a ubiquitous search box (a la gov.uk), I’m far from for a UI/UX expert, but I tend to think that startups generally have a pretty good sense of what’s next. They have to. If they don’t get it right the first time around, they tend not to have a second try. So what do we see?

Activity - Social apps like Facebook, Twitter, Foursquare, even GitHub are all built around the concept of activity. Whether its a news feed, recent check-ins, or even commit activity, the question I come with is “what’s going on?” and it gets answered as in depth as I care to scroll through, not as in depth as an engineer arbitrarily decided I needed a few years back. It’s linear. It’s inverted pyramid. It’s customized by whom or what I follow, not by what I add or (re)arrange.
Minimal – Productivity apps like Gmail, Google Reader, even DropBox don’t summarize for me how many emails, unread posts, or free MB I have as soon as I log in, and with the exception of a few labs features here or there, don’t even give me the option to have anything more than a bare-bones inbox, unread feed, or directory listing. In fact, GMail and Google Reader were recently criticized for going a bit too far in this direction. But the lesson is the same: just give me my stuff and get out of the way.
Immediate - Transactional apps, like Uber or Square focus on action, not the past (or even the present). When I open the Uber or square apps, I’m immediately presented with the ability to request a vehicle or swipe a card, not my top tasks, not an arbitrary array of options or metrics, not with recent news about the product or popular add-ons. The app simply stands at attention, awaiting orders. I actually had to dig a bit to find my transaction history and related business analytics, and I’d argue that’s a really good thing.

Think about the last time you’ve used a drag-and-drop dashboard: If you’re like me, it’s going to be either Google Analytics or WordPress, and if that’s the case, it’s simply known as the screen you see after you log in, but before you can do what you need to do. It’s wasted pixels. It’s cruft from a bygone era when clicks were expensive and developers were left wondering “how can we fit more on a page”.

Options are a crutch. It’s the natural tendency of any engineer to over engineer a system, and that tendency is even stronger in a risk-averse, top-down culture like government. But your job — as an engineer, as a product manager, as user — is to push back, to fight that urge, to make decisions, not options. Not convinced? That feature you can’t bring yourself to cut? Expose it through your API and see how many users complain.

It’s no longer a question of “is this possible technologically?”. It’s no longer a matter of “can you expose me to that information 24/7?”. Ever since the advent of Zombo com, the only limit is our imagination. We’ve figured out the hard stuff. It’s not centralization and personalization. It’s decentralization and interoperability. Simplicity is the new black.

Originally published July 10, 2012 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit