Non-continuous status "Dead Zones"

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? Yet, 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 Usability every day, it is the traffic intersection.

Yet, 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. I had how they worked 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 this most important of everyday thing?

At great risk of annoying my fellow Germans, I cautiously tiptoe into German road design. Nothing is more sacred to Germans than Cars and their Roads. So, at great risk, I venture this opinion piece.

Continuous status information

A basic principle of good Usability is to provide Continuous status information to the user. 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, After entering the intersection, the driver no longer has status information available. The driver no longer has any status information of the state of the traffic light.

How so?

The traffic lights are now behind the car. The driver cannot see the traffic lights because they are behind the car at the start of the intersection. These lights are placed on the corners of the intersection. Is the light still green? Has it turned yellow? Is it now red?

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.

Note the traffic lights in the above image. Notice that the traffic lights are placed on both the near and far sides of the intersection.

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 simple example of 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 zone all the time - a state when the product offers no user information to know what to do next, what the product is doing, and the user has 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