How a connected car's instrument cluster can be redesigned for contextual empathy

©iStock.com/EXTREME-PHOTOGRAPHER

The connected car is the focus of a lot of speculation about uses for contextual data feeds. The visions are exciting, whether of helmet-mounted cyclist beacons or biometric apps to stop drivers falling asleep at the wheel.

But they derive from car makers without a long track record in the kind of human-centred thinking that constitutes best practice in interaction design. Or they come from technology companies whose over-riding ambition is to transplant their operating systems into automotive environments. Taking all the visions together would mean drowning in a sea of data, or more aptly being driven to distraction.

Instead, we need to go back to first principles. We need to start with people and their need for the right information or functionality at the right time in the very specific environment of a car. This means having what we call ‘contextual empathy’.

An empathy for context, rather than a love for contextual data, almost certainly means ‘less’ overall: Fewer types of data feed than envisaged will find a place in what will become recognised as the ‘new normal’ model for the automotive human-machine interface (HMI). But paradoxically it could also mean ‘more’ in specific circumstances and with appropriate design considerations.

This is what we found when creating a new prototype for the instrument cluster, an aspect of HMI that has remained remarkably unaltered since the earliest days of the speedometer. Our efforts are described below. Because we want to spark a debate, the output is available to anyone to adapt, through code available at http://ustwo.com/blog/cluster/ (the site also has interactive prototypes, along with a full paper on the in-house project).

The cluster: time for a change

By looking afresh at the instrument cluster at the start of 2015, we challenged ourselves to make better use of real estate that to date has been dominated by indicators relating to safety (the speedometer), efficiency (the rev counter) and practicalities (fuel gauge). These elements have over time simply moved from mechanical dials to a screen, with little else changed.

We are now at a time when sensors and wireless signals mean that so much more about the car, its environment and other information relevant to the driver could be relayed. The right information at the right time has the potential to increase situational awareness for the driver for example. The possibilities are endless, for example raising awareness of passing a school during collection time, adverse weather conditions, accidents, roadworks, a slippery road and so on.

But the questions remained of which data feeds would be most useful and how could they best be incorporated, while not crossing a legally defined line into distraction; in fact reducing it. We also wanted to retain the positive aspects of the old analogue approach – the legacy feedback elements where relevant (albeit updating the way they are presented), the ability to show relative information and reinforcement of the car brand.

The only way to find the balance that is going to be required of the ‘new normal’ cluster was to build it from the ground up using the principle of contextual empathy. Our open and product-centric approach meant we were able to quickly design, build and test prototypes.

Above: Very early in-car tests with a proxy screen – an iPad.

Five key features of Cluster 2.0

The key features of the reimagined cluster that we settled on take account of drivers’ core needs in addition to what it is technically possible to do in relation to those needs. They show where contextual data has a role, for example by enriching quantitative readouts:

  • Speed: Speed shown, but in relation to contextually derived information on local speed limits and other parameters such as weather, with appropriate feedback
  • Range status: Combining elements of a fuel gauge and range, shown both as absolutes and in relation to the next entered journey (with the range estimation based on previous driving behaviour)
  • Contextual alerts: Both based on location, time, conditions (e.g. traffic conditions) and where the alert originates from, for instance the HUD
  • Reverse: Rear view camera view takes over while reversing
  • Gears: Consistently positioned and present at all times as is the legal requirement

Design considerations affecting what gets shown, how and when

Once the key features had been decided, we applied five design principles that we had developed for a project last year to develop a concept for the car HMI of the future in the round. They simultaneously multiply the possibilities for what gets shown, depending on the context, and keep clutter to the minimum. Two of the principles are below.

Adaptive hierarchy: Elements based on action and user behaviour, agnostic to display

The layout of the design adapts and affords priority to elements based on the user’s action at any point, displaying just the right information at just the right time. This form of contextual empathy might allow users to be connected to both the HMI and the real world. For instance the speedometer only shows itself while the car moves, and is minimised when not, allowing us to focus on more important details while not in motion like range to your destination or fuel status.

Insights through visualisations, not just raw data

We shied away from using pure numerical outputs, and use visualisations and insights where we can, for example “How close am I to the speed limit” rather than simply displaying speed. Doing this helps create elements which can be understood quickly without excessive interpretation and cognitive load (even more important given that we can’t expect a car’s main driver to be the sole driver – a key contextual consideration).

The new normal starts here

What you see below is an iteration we are happy with and by no means a final answer – but more of a conversation starter with the wider community. We are very keen to hear your views so please join in (http://ustwo.com/blog/cluster/) and help us find the right role for contextual data in the cluster.

Above: while driving, speed takes top priority, while range (to the right) is secondary information.

 

Above: when parked, there is no need for the speedometer so range to destination or absolute range can take priority instead.

Above: how our concept could be designed to comply with automotive manufacturers’ brand guidelines and unify the cluster with the interior and exterior of the car’s design.

Video: Our concept in a nutshell.

Tim Smith and Harsha Vardhan also contributed to this piece.

 

Leave a comment

Alternatively

This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.