Reducing Cognitive Overload in the Connected Car

At Hike One we have been designing and reviewing car interfaces for quite some time. In 2014 we even set up a website all about this topic: Here we analyze and review dashboards from different car manufacturers. Recently we also wrote an article for Autoweek. One of the biggest automotive magazines in The Netherlands.

With the rise of the connected car and the transition to digital dashboards drivers have more possibilities to interact with their car than ever. While this seems like a positive development, it also raises a new problem. While driving, drivers are getting distracted by the many functionalities of their own cars, leading to dangerous situations on the road.

That’s why we decided to take a closer look at the cognitive overload people experience while driving their car and find a way to minimise this through design. This became the graduation project of intern Wouter van de Kamp.

Cognitive Overload

The last couple of years the everyday car has evolved from a simple commute product into a connected platform. A transition that seems simple; connect a car to the internet and it’s done! However, in reality, this change raises way more questions than we had prepared for.

When we look at the connected car ecosystem, it shows us a huge increase in the number of services, applications and providers (Figure 1). This is the result of car manufacturers and tech companies trying to provide a better commute experience. To make this work inside the car, the choice for a touchscreen has become a no-brainer thanks to its ability to present and interact with dynamic information.

At first sight these changes look perfectly fine, but as soon as we took a closer look during several observations (Image 1), we noticed that today’s car is asking too much effort from drivers to accomplish certain tasks while driving. As a result, drivers are now experiencing a cognitive overload.

A cognitive overload means that there is too much data being processed in the short-term memory, which results in drivers to miss out on vital driving information. In other words, the driver becomes distracted and serious injuries can happen. Based on our observations, the situations in which a driver tries to complete any of the following tasks are the ones most likely to cause this phenomenon;

  1. Changing music when a disliked song starts to play
  2. Adjusting the temperature when it becomes too hot or cold
  3. Rerouting when a traffic jam occurs

The fact that these scenarios are increasing cognitive load is mainly related to the way they need to be executed. First, they require an excessive amount of steps to complete. Secondly, the steps to reach a certain option are different every time forcing drivers to search through their system. Lastly, every single solution requires a different action from the driver, example given; temperature is being controlled by a slider, whereas rerouting requires single touches. (Image 2)

Contextual & Dynamic Solutions while Driving

With this set of problems defined it was time to craft a solution and start trying to reduce cognitive overload. Over the course of four iterations this translated itself into the concept Contextual & Dynamic Solutions.

Contextual & Dynamic Solutions provides drivers an extra layer on top of their current system (Figure 2). This way only relevant information is being displayed with relevant solutions and options.

Inside this layer there are three different modes; temperature, traffic and music. Depending on which mode the driver is currently in, it displays the corresponding changes in data. Example given; when the driver is in music mode, it only shows a notification when the music changes. (Figure 3)

Besides an overview of the change in data, it’s also giving the driver three solutions and an option to ignore the contextual layer. All solutions that are being offered can be based upon the drivers’ context if it is defined during an optional onboarding at the beginning of his/her commute. (Image 3)

This concept is solving the three issues that are mentioned in the introduction by doing the following:

  1. The extra layer is always relevant and solutions are immediately available. This way we are able to eliminate an excessive amount of steps.
  2. All three modes can be reached in the same way. No need to search through the system.
  3. Every solution is also executed in the same way. Figuring out how the controls work has become a thing of the past.

To make this concept work, not only on paper, but also inside the connected car defining the right devices had become a priority. Soon, it became clear that a touchscreen in the center cluster stack and a head up display in the windshield would be our best options.

The touchscreen in the center cluster stack was an easy pick since that’s becoming today’s standard and would fit perfectly into every car manufacturers’ roadmap. The problem however, is that it’s position and visual dependency is taking the driver’s eyes of the road way too much and can easily cause a cognitive overload.

A first step to solve this was by integrating haptic feedback, a large interaction area and the use of gestures instead of direct touch. Unfortunately this wasn’t enough, so that’s when the head up display made it’s entrance. By displaying all information on this screen, the users eyes will be on the road all the time. This means that dividing attention between driving and interacting will become easier.

To demonstrate how this would come together in the daily life of drivers the following scenario has been developed.

An Everyday Commute

It’s early in the morning and you are commuting to work with a colleague. The commute is pretty standard and you know that the drive will be around 60 kilometers. To make sure the connected car is going to offer you relevant solutions to changes in data, you are setting up your profile through the onboarding right before you leave (Video 1).

After driving for a little while you notice that traffic is light in the area, so you switch to music mode. This way you have better control over the new playlist that you selected. After a couple of minutes you know that this is a good decision because a song kicks in that you dislike. With one simple swipe upwards you browse through the three solutions that are ordered by relevance. Since you’re eyes need to be on the road you decide to concentrate on the haptic feedback. As soon as you feel three short vibrations you know you navigated to the third solution. You quickly glance on the head up display and realise that it matches your needs. To select the solution you release your finger from the screen in the center cluster stack. (Video 2)

When you getting closer to the office, traffic becomes heavier. The system becomes aware of that as well, and figures out that you are going to be delayed by 10 minutes. To prevent this from happening it gives you a contextual overview with three reroute options. You decide that you don’t mind the 10 minute delay because you are early anyways. With a simple swipe down you ignore it. (Video 3)

Testing a Connected Car Concept

To test the concept and validate the scenario’s a prototype and a test setup were necessary. The prototype, that has already been shown in the videos above, was build relatively quick by using Framer and Firebase. Framer was used for the interactions, and Firebase would connect the head up display with the center cluster stack.

The test setup took a bit more time since we needed to improvise. A car simulator to simulate the pressure of everyday driving and eye-tracking glasses to measure cognitive load weren’t within reach.

Eventually we solved this by using a small game called Dashy Crashy created by Dumpling. This game would give the users a bit of pressure while they completed several scenario’s on both a regular connected car as our prototype (Image 4 & 5). Besides simulating pressure, it also gave us a basic insight in the cognitive load on users. By measuring the scores, amount of failures and the time to complete a scenario we would obtain an indication of whether a user was under a high or low cognitive load.

After we completed our test and compared the statistics there was only one conclusion that could be drawn; our prototype and the connected car were identical when it came to the amount of cognitive load they had delivered onto the drivers.

Differences only started to originate when we began to evaluate the experience through an interview. Herein users mentioned that they thought they had more control over the game when using our prototype instead of the regular connected car.

What We’ve Learned

As a final thought we would like to share some of the principles that has helped us in trying to minimise cognitive load and shaping this prototype. They also developed to help you getting started with designing for the connected car yourself!

  1. Use gestures in combination with haptic or auditory feedback instead of plain direct touch
    Direct touch is demanding a lot of driver attention; glancing where the touch area is, making sure you touch it right there, and finally confirming whether you did it correctly by glancing again. Using gestures with haptic and/or auditory feedback on a big interaction area can prevent all of this and help the driver keeping his eyes on the road.
  2. Make use of the driver’s context
    Almost everything has to be done manually in the connected car. From enabling navigation to setting up playlists. By understanding the driver’s context these tasks can become more automated and thus limiting the number of interactions the driver has to do while driving.
  3. Prevent choices while driving as much as possible
    Making choices while driving has proven to deliver a high cognitive load. So whenever you add a decision in your design make sure it’s valuable and useful to the driver at that particular moment.
  4. Give access to all relevant streams of information
    If interaction with the connected car is inevitable, make sure the road is still in his or her peripheral vision. This way we make sure that the driver is constantly in control of all relevant streams of information and able to switch faster between interacting and driving.
  5. Deliver information to multiple senses
    While driving it can be hard to take in information. If you design something that it’s really important and shouldn’t be missed by the driver make sure to deliver it to multiple senses. Our short-term memory filters every sense separately so maybe visual information will be missed, but audio or haptic information won’t.
  6. Be creative when it comes to testing for the connected car
    When a driving simulator isn’t available it can be a challenge to test your connected car prototypes. Throughout this project we’ve noticed that a game can be a good replacement, but we are sure that there are many other ideas out there. If you know one them, make sure to let us know.