Designing for In-Dash Automotive. A UX Primer.

Most design documentation for in-car use is focused on safety. Sadly, these guides regurgitate the stats on texting and driving, then call it a day.

I wrote this guide specifically for UX professionals who are expanding their knowledge of design to include in-car devices and have already seen the “It can wait” bumper sticker.  I do include a fair amount of safe driving points, but expound on what’s unsafe around the sacred trinity of driver safety: Driver Distraction, Driver Reach, and Driver Attention Span.

The guide may contradict many UX practices for the screen, but it’s focused on more of an augmentation to existing UX tenets and leans far more towards a mobile approach than a desktop approach. It is fair to assume in-dash devices should be held in similar range of understanding as apps on mobile devices or interactive TV, and any designs should be kept along those same lines of low-use understandability.

Please Note: This guide is far from comprehensive.  

It is the beginning point of an emerging style of design that we, as UX pros, need to be active in moving forward.  Much of this guide consists of simple snippets of advice needing more detail as the complexity of design emerges.

Let’s Jump In!

Our Driver

For the sake of understanding, this guide uses “The Driver” as its main user persona. This persona indicates basic human factors for safe driving, non-distracted interactions and physical measures for most passenger vehicles.

The persona does not take into account the wide variance in technographics and understanding of basic UI formats that will be encountered.

UI Basics

Many of these may overlap or contradict existing accepted methods, but will supersede them as using technology while driving takes precedence over any conflicting best practices.

For designers who have never created in-dash systems, it’s important to research the capabilities of the hardware with regard to screen display, audio capabilities, user input capabilities and device co-ordination with vehicles. These abilities will inform your design greatly.

The first use of the system should set the groundwork for consistent behavior. As time is an important factor, the design of the UI must be Clear, Easy and Obvious to the driver, so superfluous animations or presentation of the UI are discouraged.

With every use, the driver should be aware of system options, how they can pre-set as many items into the system, and if the system allows for voice commands.

The Grid
The design of a standard grid for each screen should take three things into account at all times:

  • The design must present a consistency of information dispersal.
  • The design must provide consistent and easy access to basic features and progressional actions.
  • The design must take into account the reach of driver, expectation of minimal attention spans and placement of tappable areas requiring minimal recall.

These three items are constants regardless of screen size, functions of applications or resolution of screen.

Consistency of Information Dispersal
The grid should account for the majority of the screen to be used to convey information, with minimal need to scanning. The centered area is commonly the first accessed by a driver’s vision and therefore is the best place for immediate feedback.

The standard app structure should account for 3-4 major zones of activity:

  • Main Content Area
  • Primary navigation / feature set access
  • Action areas for current task
  • Alerts and notices (both active and passive)

Once the basic grid has been established, it should not be altered for fringe cases of activity. During the design process, the grid will adjust as needed, but final design should have a locked structure.

Note the grid does not have to be mathematically relevant, but designed for need and size of available screen size, activity and content.

The active areas of the screen should be considered for easy recall of action for the driver.

  • Recall of driver is imperative in any in-dash application. For most purposes, assume the driver has 1-2 items of focus at any time, with less than 2 seconds of driver attention per action or interval. Any additional demands of driver’s cognitive space will cause distraction and unsafe driving.

This restriction will allow for the emergence of an active UI that minimizes distraction and places focus on the core even that is occurring.

Consistency of interaction types should be maintained at all times. As an example, if “OK” is the trigger for all actions, it should be consistent in placement, action and effect.

Reach of driver is variable and unpredictable. Placing tappable items closer to the driver is a key factor is in-dash success. Assume the right edge of the screen, closest to the passenger as a dead zone for suitable interaction.

At times this area is very valuable, but understand any shift in driving position puts the driver and others at risk.

Be aware of the shape and contour of the device itself, and how a beveled edge, the shape of the mount or inset into the dash may cause objects close to the edge of the screen to lose targetability of the tap area.

Application Structure
With any in-dash application, the system design is more important than the visual design.

This is not to minimize the importance or impact of a beautiful design, it is simply to place the focus on the design of the experience as a whole, not just the visual aspect.

Structured application design is a skill that some designers do not have opportunity to accrue. Following is an explanation of the Hub and Spoke approach, which produces shorter activity cycles and major areas for drivers to re-orient themselves.

It is strongly recommended that this approach be attempted.

Hub and Spoke Design
The Hub and Spoke is a simple structure that places the user at the center of activity, allows for rapid access to core features, then returns user to the central point.

This approach increases recall of available actions, shortens time to arrive at a task and provides exit modes in the event of user error.

All tasks are to be action based, with no use of noun-based listings of “Places.” This approach will call into focus, a far more useful and usable range of opportunity for the user.

Sub Modal Processes
Any progressional feature that branches from the hub needs to be kept short and concise. A minimization of any process is encouraged, and designers should strive for a maximum of three steps within any process.

Any process that results in simple informational display should be examined. In many cases these processes are moot as the resulting information is status based and can simply be displayed without adaptation.

Visual Design
Visual acuity and recognition in in-dash applications is a vital key to the success and safe use of any system.

Designers should reference key trends in flat and clean designs and avoid complex and intricate graphical elements.

If two things can be stressed in the visual design, it is the following:

  • If a graphical element provides no function or obvious use, it should be removed.
  • The user should be delighted in the visual UI, how responsive the UI performs and how clear and obvious the features are presented.

Color and Contrast
In-dash applications rely on contrast to differentiate key areas, actions and visible active items. Subtlety in a color palette is not something to strive for. Select a palate of bold, easily divergent colors and apply in a methodical pattern to the layers of the UI. Transparency and shading within a single color range should not be considered a viable use for differentiation of key items.

Use of contract to indicate changes to state or draw users attention to important items is critical. Use strong solid colors with clear text rather than shaded, extruded or beveled buttons in conjunction with text with visual effects.

Keep in mind the screen type may render some colors / color distinction invisible in direct sunlight, while other screen types may have glare that will cause difficulty in viewing low contrast color palettes.

A good rule of thumb is to initially design your application entirely in grayscale and textures. This will allow for an understanding of contrast and differentiation needed for proper use of the UI. As you add color to the design, be aware of how the addition enhances or degrades the usability and visual acuity of the UI.

Nighttime Viewing
When dealing with color and contrast, be aware of the brightness of the interface during night driving, and the potential of the device to affect the eyesight of the driver.

In most cases, having a darker or neutral background should be considered for this reason alone. A stark white background will have effect on the ability of the driver to conduct safe driving in dark environments.

Some devices will have the ability to dim, if so, consider how the dimming affects the UI, whether or not there is a nighttime view, or if the dimming is a user-controlled part of the interface.

If a separate night view, or any selection of views is considered in the design, first be aware of any auto-dimming abilities of the device. Selection of modified views is simply a compounded learning effort by the driver and not something that should be expected to be a known attribute.

Depth
single overlays are preferred, and any multi-pane scenario should be killed (along with the designer who suggested it).  Shading and other depth-related items do not need to be huge to be effective.  Many times these are merely screen space eaters, so use wisely. Use color/texture differentiation to separate areas of the screen, and set a series of tiered alerts or notifications that are visually differentiated.

If buttons or tappable areas are given the appearance of depth, ensure there is user feedback that shows they have been activated. If the appearance is merely artifice, consider changing to something with similar visibility but no expectation of visible results.

Iconography
Use icons over text wherever possible. Use text sparingly and write clear direct short and concise copy. If designer has issues finding correct icons, consider need, naming and placement of the feature.

Please note that if you have a concern about too many icons lining up next to each other, and a driver’s inability to discern one icon from the next: You have an application level problem, not just an icon problem.

Nowhere should there be more icons than can be easily identified, accessed and distinguished from another. If you have a long-assed row of them, you’ve failed to segment the features of the app properly, go back to the user journeys and adjust accordingly.

Branded Visuals
In modern design of digital devices, we need to consider function as brand.

This is a big step for some designers who rely on repetitive messaging and visuals to be the primary brand representatives. In this style of design, refer to the brand ideals for how an app should feel, the voice it should take to interact with a user and the overall emotive quality of digital interaction.

There may be recommendations in this document that are counter to brand approved fonts, colors and style. If there are conflicts with brand style guides, you are strongly urged to update those style guides with new variations for this type of application.

Voice and Gestural Commands

If the device supports audio or gestural commands, it is highly recommended that they be used.  This is the stuff of a much longer post as vocal commands, the software’s ability to respond and the training of a driver is a massive thing to design and discuss.

Understand that audio have limitations based on the host device’s integration with the vehicles existing audio input and speaker system. This will need to be assessed specifically when a software/hardware and I/O protocol are established.

Gestures are becoming more and more useful and obvious to many consumers and can lead to activating key areas of the application without needing the driver to focus on the device visually.

If gestures are to be used, consider basic driving issues such as unintentional rapid scrolling, or the vehicle itself moving at inopportune moments.

Testing Recommendations
Testing the device and interface in real-world situations is highly recommended.

Without a full visualization and simulation environment, traditional testing will not be appropriate for significant results.

 

As I stated, this is merely the beginning.  If there are any in-dash designers working on something they’d like to discuss or show off, please give me a shout!