While we were in the WritersUA conference in Portland, OR, I noticed I was thinking about communication all the time. I started reflecting on minimalism and intuitiviness (as in what is intuitive does not need to be said), and “delighted” my travel companions by chattering about my observations constantly.
While these examples are not from the domain of technical communication, they may help us think of technical communication problems as we write instructions. How can you translate this to your own products and your own documentation?
Example 1: Traffic lights
Sometimes with the traffic lights, there’s a small box in the pole that has a button on it. It may not say anything at all, or then something in the lines of “To cross over, press the button”. If you know what traffic lights are, this is just fine.
But if you don’t – you need a whole lot more instructions to complete your task successfully:
- Conceptual information about traffic lights and what they do
- UI descriptions/term definitions for green and red lights
- Probably some warnings from your legal department, since bodily harm could ensue
- A numbered task sequence with several steps about pushing the button and crossing the street. To promote learning and understanding, you should also tell what pushing the button does, so how the user’s interaction with the UI influences the world.
The lesson: Think whether the users really know the feature you are writing about. They need considerably more information to complete their tasks if they don’t. You must teach them about the new feature.
Example 2: Hairspray
Can you pack hairspray in your luggage that’s going to the air plane’s cargo?
The dangerous goods list on my airline’s page talks about pressurised containers and flammable liquids not being allowed. Technically, hairspray is usually both. But the examples given include stuff like paint and varnish. Because hairspray is not mentioned, does it mean that it is allowed? Or does it just mean that the airline did not remember hairspray at all when writing this?
The lesson: If you know there are specific use scenarios that the user is interested in, spell out what they are and how they go. For example, not mentioning something at all does not intuitively mean “it must be OK then”.
Example 3: Oxygen masks
You know those safety demos or videos they must show you before an air plane can take off? On the Portland trip, we did one strech with an airline I had not used before. And they had included a really nice point about the oxygen masks.
Normally, you just get the instructions about how to put the mask on. This airline also told you that when the mask is in use, the oxygen flows even when the bag does not inflate. Now this is something I would never think of pondering in advance. But if there was an emergency and I needed to use the mask, I probably would expcet certain behaviour from the mask UI, and get worried whether I am completing my task of getting oxygen successfully. I think this airline did a good job in anticipating that user worry (or perhaps panic would be a better word).
The lesson: Anticipate the problems or questions the users will have when completing the tasks, and respond to them. In tech comms, it is very likely the user picked up your instructions because they are already facing that problem or question, and want an answer.
Filed under: communication, conferences | Tagged: Portland, WritersUA
Excellent observations!
There are loads of things we can take as examples from every day life (opening the door, pull vs. push; sorting out different kind of recyclables; how to use a travel card in a bus;…). We have yet a lot to learn of our end users, and I’m glad we finally talk about things out loud (i.e. write about stuff in blogs). 
The example on the traffic light also underline the fact that we should not document _everything_ that needs to be done or known. If a traffic light button included all the information next to it, either people would just ignore the instructions, be irritated by them, or worst still, become intimidated by the complexity and not even try to use it.
In documenting a software application it is important to know whether you can expect the user to have the basic knowledge about using software in general. If not, you should be thorough (applications that are targeted to the general public). However, more advanced users become frustrated, if they cannot easily scan the instructions to find the answer to their particular problem. If the instructions seem too basic, they give up on the guidance altogether.
Maybe traffic light buttons could have an indication as to how long it will take before the light will change – that’s the information I usually crave for, when it seems to take ages after I have pushed the button…
It’s not easy deciding how much information should go in – when does useful information turn into information overload?
Like you said, Pirjo, it is important to know what the users already know. If they don’t know much, you may want to provide content that helps them learn, too, and not just have them follow steps without understanding what they are really doing.
No matter what level of info you select, it is likely to be wrong for some of your users. What would be great here is personalised, dynamic publishing. Then you would “just” need to determine the general rules what level and detail of information certain user groups require. But the possibility to view more, or less, content would also be there for the user.
By nature, some designers, writers, and editors are more minimalistic than others. I guess that is why the issue can spark lively discussions, at least so in our team
I agree with your improvement idea on the traffic light button UI