Desgining the UI for a center stack (100% touchscreen), still in the wireframe stages. However, when mocking up the home screen, it dawned on me I don't know much about UX (I do mostly backend work, and am slowly breaching my way to design). So, that leaves me two options:

  1. Blindly follow the OEM's design just because it's the OEM's design, while changing simple things like icons and backgrounds.

  2. Create a new design from the ground up, while taking into account hig (if any exist for this sector).

I would like to go with #2, to set my UI apart from the rest, but still be easy to use. I have a few guidelines in mind, but want a 'sanity check' and also if any documentation exists on this somewhere then also have that as a resource (I'm still googling for this at the time of this writing).

Here is what I have so far:

  1. Anything potentially used by the driver while driving should be easily identifiable at a glance, and easy to use/change (i.e. BIG BUTTONS with familar pictures

  2. Settings/Options most likely used should be not be more than 1-2 levels deep, if at all possible.

  3. Important/Relevant Information should be displayed on every screen such as the clock, important diagnostic/service information such as battery charge for electric vehicles, etc.

  4. Fast response time, meaning no (or very little) cheesy screen transitions. My theory is that on this platform it wastes time, and the longer it takes to refresh the screen with new content, the longer the driver's eyes are off the road (potentially). Not a big deal at a red light, but obviously almost everyone has changed the heat or radio on a freeway, where taking one's eyes off the road for 4 seconds @ 60mph is equivalent to traveling the length of an entire American Football field blind.

I'm sure I have more, but those are the high points of course. Any more info is welcomed.


To be crystal clear, I am asking what (if any) UX guidelines exist for the automotive platform, or what one should keep in mind. This is not a 'port' of an existing application to a platform that has publicly established hig. user1757436's link provided valuable documentation on some of the research done in this domain.

  • 1
    Before you start, please familiarize yourself with the research in this domain. The OEM probably follows the standards and guidelines created by organizations that do research on this problem. Commented Feb 10, 2014 at 13:18
  • This is useful, what GoogleFu did you perform for this, or are you in the field? also ..please familiarize yourself with the research in this domain, that is what I'm trying to do!! :-)
    – MDMoore313
    Commented Feb 10, 2014 at 13:35
  • 1
    Try 'human factors', ivis, 'driver performance', 'driver distraction' as a starting search. The research methodology also provides useful search terms: 'occlusion protocol' 'occlusion method' driver 'secondary task' Commented Feb 10, 2014 at 14:05

1 Answer 1


As everyone suggested, please do look at the existing research in the area. That said, here are some suggestions I found on what would be the expected best practices in defining dashboard specific content for automobiles.

  • Ensure content is visible from a distance : Do note that while you would be hoping that your drivers have good eyesight they will have only a fraction of time to take in information and having content in really small font can make it hard for them to assimilate information. To quote this article about automative UI's

Dashboards are often viewed from a considerable physical distance. This distance imposes some restrictions on the dashboard's appearance. Here's a little experiment: open up any text document. After that, walk away from your desk and get some coffee. When you return, keep five or six steps distance from the screen and locate the fifth word of the second paragraph. How long did that take you? And how hard was it to locate and read the word? From a distance, 12 pt type tends to blend into the background, becoming barely legible. This means dashboards can't feature small text, however pretty and aesthetically pleasing it may be.

  • Due to the limited space,consider using icons if they are easily recognizable : If you have an icon which is easily recognizable consider just using it rather than providing a lot of text to explain the same reaction. However if the icon is not well known or easily recognized consider supplementing it with text to make it easier to read. I recommend looking at this link to get additional inputs on the type of icons to use.

  • Define a consistent layout grid : As you rightly pointed out do not try to have too many screens and multiple levels but try to have a well defined and structured grid so that users are accustomed to one layout rather than having multiple layouts to remember. To quote this article:

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 occurrin

  • Contrast and color : I recommend looking at some of the answers in this question "Dark screens in cars" as that will give some additional inputs on the need for sufficient contrast to ensure information can easily discerned at a glance. Also to quote the above mentioned article

Use of contrast 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: While your design might stand the test of time in day time viewing you need to also consider for the fact that the contrast and brightness levels will be different at night time. To quote this article

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.

  • Voice and Gestural Commands : I am not sure if you are considering this as part of your design\implementation phase but there are a few considerations to consider here as well as quoted below

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.

Also ensure that primary activities are not dependent on gestures alone as the focus on performing the specific gesture can be a distraction to the user as mentioned in this article about the Cadillac gesture based system

If a driver moves his or her right hand within 8 inches of the center touch-screen of a Cadillac equipped with the CUE infotainment system, the screen illuminates and displays icons for more features.

But systems such as CUE can be controversial. Consumer Reports blasted CUE in a blog posting two months ago as potentially causing more driver distraction. Because the screen doesn't brighten until your hand gets close to the display screen, it might be harder to zero in on a particular icon from among many.

I also recommend listening to this excellent talk Trip O'Dell: If UX Can Kill it Probably Will - Designing for the 70 MPH Interface as it gives excellent inputs on how to design for car based interfaces and what you should consider.

I also recommend looking at this excellent article on how Tesla defined the user experience for its Tesla Model S

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.