I nearly called this post ‘the curse of the weather widget’. It is an unwritten rule that once an interface reaches a certain level of capability, somebody adds a weather forecast to it. Your phone, your desktop, your smart TV, your voice-activated assistant. I’ve even seen it on the little LCD panel for an inkjet printer. The weather widget is symptomatic of a deep design challenge though: what is the right place to aggregate information and notifications about what’s going on?
One place to go is too few
The appeal of a dashboard is that it sounds like it gives a single place to go for everything. Many employees complain that they have too many things to keep track of, across emails, HR systems, collaboration tools, chat-tools and line of business applications. Asking for a dashboard is another way of expressing frustration at this complexity.
However, there are big challenges in executing the “one dashboard for everything” idea in practice:
- A dashboard should fit on a single page, but this is impossible with so much to cover.
- Removing irrelevant information requires a highly targeted approach which few organisations are able to manage
- A dashboard interface cannot be optimized for the range of tasks it must cover, so ends up just being links to more specialised interfaces.
If you think about dashboards in the real-world, they are rarely “one place for everything”. They tend to be very specific to a task, such as car dashboards, air traffic control or marketing monitoring.
Some claim that a single dashboard should be the role of an intranet, positioning it as a one-stop-shop, single ‘pane of glass’ or digital workplace hub (we’d probably say “portal” if that term hadn’t already been cashed-in). These tend to fail on several counts, not least the first issue: in covering too many bases they become too complex.
We need different kinds of dashboard
I’ve been trying to find a categorisation for dashboards and drawn a blank, so I’ve made one up. There are three kinds of dashboard:
A task-support dashboard is something you use when you are immersed in a task. For example, a sales manager may go to a dashboard showing sales performance by region and product to help decide where to allocate resources for the coming month. This kind of dashboard’s purpose is to pull together information together from multiple sources to help a specific decision.
An interruption dashboard needs get hold of you no matter what you doing. Think of how Google Maps warns of congestion on your commute before you even set off. It also needs to give enough context for you to decide how to act. For example, a security breach notification needs to indicate severity, proximity and so on. One of the reasons why the fire at Notre Dame Cathedral was so devastating was that the security employee was confronted with an indecipherable warning message and the fire brigade wasn’t called until half an hour later.
A monitoring dashboard is the broadest category. This is the one where you need to look across multiple events to interpret status. For example, at the start of your day looking across all document changes and discussions in multiple projects can help you decide what to attend to first. Activity streams (newsfeeds) in social networks are a similar example, but their scope is usually too narrow to be useful, so users soon complain that it becomes ‘just one more thing to look at’. The whole point of the monitoring dashboard is to say you’re going into multiple places just to keep track of things
Why we get dashboards wrong
Many dashboards fail because they are unclear on their purpose or mix the types. I’ve seen several business KPI dashboards that seem to aggregate every piece of data they can collect rather and asking what decision it is there to support.
I believe this is also why intranet homepages that also try to be dashboard fail. They tend to assume the dashboard has a ‘monitoring’ role, but to the employee news is far too dominant compared to the work decisions they actually need to make.
A second reason is that monitoring dashboards add little value if even the smallest actions take the user to another screen. For example, if an expense needs approval, then it should be possible within the dashboard rather than needing a login to another system and five pages of navigation. This is where microservices are having a big impact on leading digital workplace designs.
This is not to say that dashboards shouldn’t have an ability to drill-down however. A programme manager may see that a project has missed several milestones as a traffic light ‘rolled up’ indicator, and then want to delve into the project specifics to see what is going wrong. Similarly, a simple expense approval can be done with one button, but a leave request may require a look as the employee’s recent absences and even a check on relevant policies.
Good design principles
Finally, here are five tips on what makes a good dashboard:
- As the goal is to reduce overload, everything must personalised.
- Appropriate levels of interruption. If I’m working in one corner of the kitchen, I want to be interrupted urgently if the toast is burning, but if the kettle has boiled I only need that confirming when I’m ready.
- ‘Just enough’ context. You need to know enough to decide when to act but not so much that the page becomes crowded.
- Notifications understand dependencies. Sometimes one event will trigger multiple alerts. If the router goes down, I don’t need alerts from 20 other devices saying they have lost their internet connection. This is a hard one and there’s great potential for AI to help understand what matters most.
- No duplication. The same alerts should not appear in different spaces (and that includes the weather).
This article was originally published over at CMSWire.