Traffic intersections. We have all used them. We've all had moments of anxiety crossing them. We've all had moments of sheer horror as we make a right or left turn and seeing a car barreling down on us. Will that driver stop? Can I make it safely across? These are all safety issues. And we haven't even started on the safety of pedestrians trying to cross the intersection.
Dead zones - systemic design problems
If there is one place we face the importance of the design of everyday things every day, it is the traffic intersection. Designed right, they are entirely safe. Designed wrong and they become “dead zones”.
I live in Berlin, Germany. I never took much thought in the design of intersections until moving here. It’s hard to not be biased when encountering something new. Yet, I have seen so many accidents happen at intersections in Canada and the US, I have always assumed the problem lay with the drivers. And in most cases, it probably is.
But what if it is a systemic problem with the design of important things of everyday life?
At great risk of annoying my fellow Germans, I cautiously tiptoe into German road design. Nothing is more sacred to Germans than das Auto and die Strasse. So, at great risk, I venture this opinion piece.
Continuous status information
A basic principle of good design, and hence usability, is to provide to the user Continuous Status Information. This way at any point the user knows where they are in a task, where they have been and where they need to go to complete the task.
However, when a driver enters a German traffic intersection to make a left or right turn or to proceed straight through the driver no longer has status information available. The driver doesn’t know what the current status is of the traffic light.
Once the car or truck enters the intersection, the driver no longer can see the traffic lights because they are now behind the car. These lights are placed on the corners of the intersection. Is the light still green? Has it turned yellow? Is it now red?
Traffic in intersections.
As a workaround (a sort of afterthought), a little arrow is added on the far left corner to inform the user that the light has turned red and they can now complete the turn.
It seems to me to be an afterthought, something cooked up to fix a known problem without reevaluating the entire procedure. It is not a complete rethink. It isn’t a complete redesign. If the driver is in the intersection, as long as this ad hoc light is not illuminated, the light is still red. However, before this arrow appears, the user is in a ‘Dead Zone”.
This dead zone is a void of any user information - except some other driver behind honking the horn to indicate, yes, you can go on.
Dead Zone Free
How would this problem be solved? Here is where my bias shows. Place the traffic lights on the OPPOSITE side of the intersection so drivers within the intersection always have status information provided. It IS a complete redesign of the traffic intersection with the traffic lights placed to PREVENT a dead zone.
Traffic in intersections.
In some configurations the traffic lights are placed on both the near and far sides of the intersection. A third light is also added for vehicles making a turn.
No matter where the driver is, status information is always provided. Whether the driver is turning left, right, or straight ahead, the status of the traffic light can always be seen.
Product “Dead Zones”
This example of the design of things in everyday life shows the importance of providing status information at all times during a procedure.
At any point, the user knows where he or she is in the procedure, knows what decision to make based on the information provided and never enters a dead zone.
Software product users can enter dead zones as well. This is a state when the product offers no user information. What should the user do next? What is the product doing? Does the user need to wait for the “arrow” to appear to let them know what to do next, or what the product is currently doing?
As a technical writer, I see this all the time when I document software. Sometimes, the only status information the product can provide IS the documentation.
Good status information should include the following:
- tell the user the end goal of the procedure, that is, the purpose of the procedure and perhaps were it fits in the context of a larger procedure
- tell the user where they have been in the procedure.
- tell the user at what point they are in the procedure
- tell the user the next step in the process to complete the procedure
In the meantime, I use drivers behind me to honk their horn to tell me to move. They are the only ones who have the status information. Not me. I am in a “dead zone”.