The right analogy?
Digital dashboards came around as an analogy from the cockpit. But there are a lot of things that just don’t translate between the cockpit and the screen world, so is this the right analogy? We need to rethink what a web-dashboard looks like in its optimal, digital-first state by understanding the key principle of the cockpit analogy and seeing where it breaks.
Key principle: Consistency
Consistency of information is essential for a pilot because it’s important for him to detect any changes at a glance. The reason why it needs to be that consistent for him is that he’s multitasking. His ‘screen’ of vision, if you will, extends beyond his dashboard. So the dashboard is only sharing part of his attention.
On a screen, however, that level of information isn’t justified because a person is not visually multitasking. The screen has all your attention — so you just end up being entirely submerged in a lot of unchanging and sometimes irrelevant information. It makes it quite unpleasant and difficult to focus that way. Digitally, we’re very adept to the information from page to page being inconsistent — we expect it. So, arguably the main translated principle of the dashboard is just not relevant.
Slap a graph on it
The feature of choice to elevate a digital dashboard from its less modern analogy is data visualisation. This has lead to a lot of dashboards being basically packed with useless graphs and charts to somehow disguise the level of information on a single screen and make it more digestible. Unfortunately what you get is overkill. What needs to happen is less information so there are a few meaningful graphs instead of 30.
What’s a dashboard useful for?
So in order to know what is relevant we need to back up into a simpler question — what’s the point of a dashboard?
Essentially it’s a tool that that needs to facilitate insights, communicate changes as well as alerts and allow a user to draw patterns through relevant information.
The framework
Design features not systems.
The problem with a complex dashboard that’s applicable to everyone is that it’s useful to no one. Something’s gotta give — it either needs to be much simpler or cater to a specific group of people doing a specific group of tasks. Trying to build a complex ‘dashboard framework’ isn’t ideal (lends itself to more traditional dashboards that cause cognitive overload). It should be relevant to you and customisable to make it even more so.
The dashboard should offer insights. Each insight should allow you to look back and move forward. Any insight that isn’t rich enough to be actionable or have a history/alternative views shouldn’t be there.
Building in a rich set of features or super powers for each dashboard module is crucial (“Variety, not volume or velocity, drives big-data investments”). It can activate/report to you when relevant rather than all the time. Could dashboard insights be tracked as they evolve in time? How would something like machine learning dashboard help to display richer insights and perhaps less of them?
The more specific the super powers are, the more we really benefit and rely on them — much like the apps on our phones. Then the dashboard starts to become a space for alerts and notifications (and there in lies the design opportunity) rather than generic overviews.
Context matters
This is where the conventional dashboard fails. A traditional dashboard doesn’t look at your context intelligently — it works on a) designing a very specific system for specific people catering to specific needs in order for it to even begin to have the right bucket of relevant features. b) more often than not, this ‘system’ then throws all of those features on the dashboard in hopes that something will stick. This actually works when a dashboard is related to a specific purpose (e.g. CharlieHR) but building a special system for a niche group of people doesn’t seem like the best or most efficient way to utilise technology. To that end, we want to look at the principles for designing a simpler, scalable framework for dashboards that would work (currently dashboard frameworks aren’t that great).
Technology is getting better at understanding context so there’s less of a reason to throw a bunch of stuff and see what sticks. We need to start pushing limits, thinking being the conventional screen and purposefully sticking things up when they’re needed.
Simplify and notify
It’s not an issue that our phone’s ‘dashboard’ (aka notifications on the lock-screen) is inconsistent. That’s partly because we’re confident that it’s communicating all the changing variables that we need to see. The last thing we’d want is every app on our phones holding a consistent spot on the lock-screen saying ‘nothing new here!’… it just doesn’t make sense. So why would it suddenly make sense to design something that way for enterprise dashboards? We don’t suddenly turn into robots when we’re at work — our psychology and the way we process information are still the same. A good case is made for the ‘undashboard’ to move away from the cognitive-overload-overview-style of overview.
How do we take this working dashboard idea of a phone and use that as an analogy for a digital enterprise dashboard? Granted, this model works on a phone because it’s already super personal — every notification is relevant to you. It gets more complicated when there’s more data and more factors to monitor outside your direct needs.
We can utilise a variety of technologies to play around with and push boundaries in order to be able to more accurately display relevant information.
BMW uses augmented reality in an attempt to make the dashboard contextual. It only shows you information that you need to make decisions as you drive. In fairness, this might actually end up being more distracting — but the point is this is a stride in the right direction. It’s moving from the ‘everything’ model to contextual, relevant information.
Infiltrate other platforms
Sure, it’s fun and exciting to try and solve problems with new technology and augmented realities. But there are simpler and arguably more impactful ways to look at this. One way we could only show relevant, contextual information is to gather data from a wider context. Instead of building one big platform and loads of features within it, we can start to spread lots of features across multiple platforms. Nikabot uses Slack as a platform to gather data for a specific task. This adds a really interesting dimension to how we can view and create dashboard insights. It means we can build fast — as we can bypass the huge platform build but still provide concise, relevant information that is actually useful to its audience. We can start to imagine a new paradigm in dashboards where insights are aggregated through small features that are spread across platforms — silent ninjas gathering information with minimal effort and displayed to the right person at the right time.
Considered views
Another way to improve the dashboard is consider how we view information. Rather than an overview page being the primary view, we can look at a dashboard from a notification-first perspective. So in a new model, the overview page would be secondary.
The less-screen dashboard.
Perhaps it’s finally the right time to bring back that ‘IoT’ chat. What would it look like to move away from the screen in order to communicate large amounts of data but only when it’s relevant? When we stop relying on a single ‘hub’ (i.e. a single or dual screen view) to show information — how can we reduce the overload of information available?
Final thoughts
Perhaps the cockpit doesn’t stand the test of time when it comes to its digital counterpart. Oh well! We can start to re-envision this analogy with a few new principles to consider: Design features, not platforms. Display actionable insights. Only show what matters now.
