What is “Human Factors”? I define it as the analysis of the cognitive processes people experience when interacting with their environment, whether it be machines (such as computer programs) or processes (such as assembling a Billy shelf from IKEA). It is often an engineering discipline, such as Human Factors Engineering, but as I have learned, its mandate spans a wide range of disciplines, including technical documentation. Human Factors essentially attempts to make something usable.
A Human Factors example from everyday life - traffic intersection
If you take the time to become aware of how you are processing the countless data that you see, hear, touch, and (sometimes) smell, you are performing a human factors analysis.
What happens to a driver when he or she stops at an intersection? Normally, they wait there until the light turns green, yes? Well, yes and no. Actually, an intersection is quite a dangerous location. Cars are approaching from behind. Cars are turning at the intersection. Cars are crossing the intersection perpendicular to the waiting cars. And pedestrians are attempting to cross while the light is green, and not get hit by cars attempting to turn at the intersection.
Then there are potential distractions. These can be anything from a boom box blaring from an adjacent car or a young entrepreneur attempting to squeeze some cash out of you by making your windscreen worse than what it was before he started cleaning it. On and on it goes. An intersection can be a very busy place.
So, it seems perfectly logical to place the traffic light in a location where you can see it at all times while you wait and still be able to keep an eye on crossing traffic, turning traffic and all the other potential safety hazards. This is where I have a problem with where the traffic lights are placed here in Germany. I see in this a Human Factors problem that hasn't been solved properly.
A problem looking for a solution
What is the problem? The next time you are driving and stop at an intersection, consider all the distractions around you, as well as where your car is, and note the location of the traffic lights. It is a complex place. You must keep your attention on the status of the traffic flow, the traffic lights, other cars, pedestrians and that is just outside of your car. And at the same time, you must be able to see the traffic lights at all times.
This scenario can be illustrated as follows.
In this example, two cars are at an intersection. The light is red and so the driver looks away from the intersection to wait for the green light. Notice where the driver is looking. Where is his or her's field of vision? While looking away from the intersection, the driver is completely unaware of traffic approaching from the left, or cars turning from the left, or even pedestrians crossing from the left. What if a pedestrian were crossing late, the light turns green and the pedestrian is now in front of the car? Hopefully the pedestrian is a good sprinter.
Furthermore, if the car is stopped directly at the stop line, it is virtually impossible to see the traffic light on the right curb if a large vehicle pulls up on the right, or if the upper part of the windscreen obscures the traffic light. The only way to know the state of the traffic light is to lean forward and hopefully see the light, or do as I do and stop one full car length back from the stop line to see one of the other traffic lights at the intersection. On some intersections a light is placed above the stop line while a third light is placed on the left corner, but the same issues apply there too. Attention is taken away from the intersection and from being aware of pedestrians crossing from the right or left.
This is the key problem. The traffic light can be obscured in many possible ways and the driver is always searching for the optimum traffic light to observe to learn the status of the traffic light.
And there is yet another more serious problem with this scenario. If the car moves into the intersection, the driver no longer knows the state of the light, especially when turning to the left or right. The traffic light is now behind the driver. It is, as I call it, a dead zone - a place where no information is provided to drivers. An apparently ad hoc solution was devised by placing an arrow light on the left opposite corner which illuminates just when the traffic light turns red and before the crossing traffic gets a green. Yet, it feels like an afterthought. It only provides a brief moment of information. 80% of the time, the driver, while in the intersection, is given no status information and must rely on experience, if possible.
Now, consider a situation with the traffic light on the opposite side of the street. It does seems rather counter-intuitive to place it there. After all, it is not on the same side as the stop line. We do not see stop signs on the opposite side of the intersection. Why then place it there?
This scenario can be illustrated as follows.
As in the previous example, two cars are at the intersection. Both cars are stopped because the traffic light is on red. Both drivers can clearly see the traffic light which is directly across the intersection in their same lane.
Notice the field of vision. Both drivers can keep an eye on both the traffic light and traffic conditions at the intersection (as well as pedestrian traffic). Any movement on the left and on the right can be noticed with peripheral vision. Somehow it is counter-intuitive placing the traffic lights across the intersection, but in practice, safety is improved for both the drivers and the pedestrians crossing the street.
Furthermore, this eliminates the dead zone. The driver is always aware of the state of the traffic light because the light is on the opposite side of the intersection. Even when turning left or right, the driver knows the state of the traffic light. Information is provided at all times during the approach to the intersection, when stopped, when proceeding through or turning left or right. Equally important, when the driver has stopped in the middle of the intersection, he or she can notice when pedestrians are crossing even while attending to the traffic light. And the driver can always see the traffic light if a larger vehicle is on the right or left. In all cases, there is no dead zone.
What about documentation?
What does all this have to do with technical writing, one might ask.
This little exercise was an analysis of how a user (in this case a driver) interacts with technology (in this case a traffic intersection and traffic lights) to understand the cognitive challenges the user faces. A solution is provided which if implemented would greatly improve the user’s experience (and safey) with the technology. In this example, traffic lights are as they are in Germany. This little blog post makes no illusions about changing that system. Similarly, most technical writers would have limited influence on changing the technology that they must document. Therefore, the emphasis must be on alerting the user to any potential issues when using the technology and suggesting solutions. (In my case, I tell myself to stop a full car length back from the intersection to keep an eye on the intersection, pedestrians AND the traffic light – and I usually get strange looks from other drivers unaware of, or not interested in the problem.)
Usability and product documentation
This goes significantly beyond merely documenting a product. It is understanding the technology as best as possible AND understanding the possible cognitive processes a user would or could experience while interacting with the technology. It is asking “How can I alert a user to possible dangers or problems before the user experiences these problems?” Then document solutions to those potential problems BEFORE the user experiences them.
With this in mind, I can then create REALLY USEFUL documentation. It is applying usability to documentation.
Technical Writers are in a unique position to influence the design and development of products, but more often than not, the technical writer is not asked to contribute in this way. Nevertheless, it has been my experience that a technical writer is an advocate for the user, not for the developer. The technical writer needs to understand as best as possible how a user would interact with a technology and create documentation to address the user's needs, BEFORE the user realizes they have these needs.
I believe that even a cursory study of human factors issues benefits any technical writer and might even enhance his or her role in the organization. The perspective a technical writer can bring to product development adds value and enhances the organization’s ability to design and develop a high quality product.
Line art generated using FrameMaker 7.0. Ampelmännchen source: Wikipedia and modified in Adobe Illustrator CC. Copyright © 2006 - 2015. This article was first published in the STC TransAlpine Chapter Newsletter Sept-Nov 2006.