Windows Automotive Notifications
Many of our in-vehicle apps needed to provide information to the driver, and expected the same interruption models they enjoy on mobile phones. However, in an automotive environment, interruptions threaten the driver’s safety. Our solutions had to work in a multimodal environment, with potential touch, voice or hardware input.
CONTRIBUTORS: Myself (Design Owner) / 1 Program Manager / 1 Prototyper / 2 Researchers
We designed, tested and implemented a notifications system that optimized for drive-related, time-sensitive notifications where a simple binary action can be taken in the vehicle.
Our notifications taxonomy identified what sorts of information can be shown as an interruption, and what information could wait until after the drive. The taxonomy was informed by an initial thorough exploration of all possible notifications from our key feature areas as well as major automaker requirements.
We also developed a series of rules for the implementation of the notifications to prevent accidental dismissal or overload. For example, interactive notifications must wait for at least half a second before taking touch input to prevent accidental dismissal.
- What visual patterns are most effective when presenting notifications?
- What notifications are relevant to drivers while in motion?
- What actions can be taken? Are these notifications safe and useful while in motion?
- What happens when a notification is missed?
We iterated on designs based on several simulator-based studies while driving. Our findings enabled us to limit the types of information shown while in motion, and verified that the binary action model was successful.
Final designs were verified as safe against NHTSA standards using an eye tracker in controlled track testing in SUVs.
We learned during testing that drivers were very specific about what messaging was appropriate when driving. If the driver couldn’t take action during the drive, the information was deemed a distraction (for example, tire pressure is low.) Drivers preferred to get this information before or after a drive unless it was a severe issue
Rather than present all possible actions (answer, decline, respond with text, send to voicemail…) we focused on a PRIMARY ACTION and a NON-ACTION (ie, decline). For cases where the vehicle was stopped, more actions could be presented.
Voice UI Impacts
Actionable and critical notifications were accompanied by a spoken prompt and a question to the driver. This enabled many drivers to take action without ever looking away from the road. The questions leveraged existing conversational instincts while using keywords to increase success rates over monosyllabic “yes/no” responses known to exhibit poor recognition accuracy.
Early Visual Design Explorations
In my initial work, I experimented broadly with size, placement, appearance and content of notifications. Options were narrowed via peer critique and prototyping/simulator testing.
Actionable notifications are lightboxed to avoid creating a disorienting loss of context. A binary choice is presented with minimal supporting text. The controls are oriented to the driver’s side and physically separated to avoid accidental selections due to vibration of the vehicle during touch selection. These screens were accompanied by a full voice UI including sound, spoken announcement, and question prompt.
Critical notifications indicate immediate threat to the safe operation of the vehicle. In test environments, participants responded as desired, calmly pulling the vehicle over as soon as it was safe.
App notifications (“toast”) were used for confirmations on background tasks (like “FM 89.5”) and selected alerts not related to the drive. Many drivers chose to ignore these entirely.