Turn Your Lights On!
The perils of failure in the design of the automotive experience
As we race headlong towards a future of automated auto-motion, it is increasingly clear that absent the perfection of level 5 autonomy and all that it assumes, the design of these systems has to pay a lot more attention to the human machine interface and how it enables clear awareness, communication and control between the two systems. The degree to which this is a non-trivial and under-appreciated problem is easily illustrated by the current failure to prevent the people inadvertently driving at night with their lights off.
It has become an almost nightly event now for me to encounter at least one vehicle driving without their lights on. And I’m not talking about driving at dusk — when we really ought to have them on anyways — but long after the sun has set. However the offending vehicle may present itself — taillights off in front of me, or headlights off approaching me in the opposite direction of travel or in my rear view mirror — each one of these situations is genuinely terrifying. And not just because of hazard created by the reduced visibility of the vehicle in question, or the driver’s compromised ability to see the road & impaired situational awareness; but also for what we can only assume must be the driver’s generally impaired awareness of their environment before they even started their vehicle.
My immediate instinct is to yell at the driver. My second has often been to pull up to them (if possible, at a stop light), roll down my window, honk at them, and shout “lights” while making the universal hand gesture of a horizontally-oriented squawking cone (silly I know, but most people seem to get it). Of course, none of this is entirely safe, and I do not recommend anyone else engaging in such antics.
After some speculation as to the reasons for this plague of vehicular invisibility — increasing stupidity in the general population, the intoxicating effects of our clean California air vs. other places I have lived & driven, or perhaps even the emerging phenomenon of youngins vaping while driving — it has become clear that operator error aside, what’s really making this possible is just plain BAD DESIGN.
Before we break down this failure to create a safe automotive experience, it’s worth establishing a basic premise about the operator. Just about anyone driving a vehicle — even those who make the poor choice of driving while impaired — is trying to get from A to B in one piece. Everyone knows that being able to see the road is critical to a safe journey, and no one wants to drive at night with their lights off.
People who drive at night with their lights off believe the opposite situation to be true, i.e. they think that their lights are on. Now we can blame this on the driver’s failure in perception, distractions such as passengers, navigation setup, infotainment systems, etc., and maybe even the impact of our brighter urban environments when the driver starts their vehicle.
But what has really broken down is the primary communication between the vehicle and the driver regarding the state of the system. This used to be accomplished by pairing the state of the dashboard lights with that of the headlights and taillights. Till you turned the vehicle’s lights on, your dashboard did not light up enough to let you feel that the vehicle was ready to be driven. The parity between the two systems made understanding the state of the exterior lighting obvious through the unmistakable state of the interior lighting. And then we got automation in its various flavors, and the UI/UX for managing the configurations and defaults for these more complex states predictably got more confusing.
This is not to say that the inclusion of automated lighting options — Automated Lights On/Off and Daytime Running Lights — are undesirable, but rather that some of the design choices made in their deployment have resulted in breaking the parity between the states of the two systems, and thereby the simple mental model that allowed the driver to really understand and manage the state of the system.
Rather than attempt to describe a specific design pattern for how these features should be integrated across all vehicles and regulatory regimes, I think it makes the most sense to articulate a set of guidelines for the design of the overall lighting experience:
- Preserve parity between the state of the exterior lights and the dashboard lights for the primary driving instrument clusters — speedometer, tachometer, odometer, etc. When the exterior lights are not on, these associated interior lights should be unmistakably dim enough to catch the driver’s attention and communicate the lack of readiness to be driven.
- Daytime Running Lights systems which typically illuminate at lower levels than those required for night driving, should NOT suggest sufficiency at night, i.e. in keeping with the principle of parity, primary instrument clusters should not be fully lit if only DRLs (and not full exterior lights) are on.
- Automated Lights On/Off systems should be cognizant of their limitations and provide some support and provision for manual activation of lights during transitional periods such as dawn, dusk and conditions such as daytime precipitation, driving through tunnels, etc..
- Lighting for secondary systems such as environmental controls, infotainment systems, and navigation should not be coupled to lighting for the primary driving instrument clusters in any way that would violate the principle of parity of the latter with the state of the exterior lights.
Automated behaviors in machines are great for reducing human workload, but as even this relatively simple case of managing exterior vehicle lighting shows, when we design for these systems with the assumption that they are foolproof and completely self-sufficient — when that is not in fact the case — we create the possibility of dangerous misunderstandings of the state of the system. We should be careful when we assume that all the complex intelligence we have evolved in the machine age — and our ability to decipher, learn and manipulate complex systems — can easily be subsumed into ‘smart’ machine logic through a fail-proof set of rules.
Designing systems to manage for these ‘edge cases’ gracefully is a non-trivial challenge with no MVP-style escape hatches through which to dodge undesired complexity. Machine learning systems may well eliminate the need for manually crafting these complex interactions, but the challenges of validating the behavior of such black box systems against desired design principles are only now beginning to be understood. Building the organizational and disciplinary cultures to deliver such systems at a level that is truly smart enough to be worthy of entrusting our lives to … that’s a whole new level of challenge that we’re just gearing up for.
To follow through on this initiative, I need a little help from all of you. If you drive a vehicle wherein the design of the controls for the lighting systems breaks the principle of parity in a way that might allow an unsuspecting driver to drive at night unaware that their exterior lights are off, I’d love to know the make/model/year and your experience of the lighting controls. Thank you!
.
.
.