What Satellite Navigation can learn from Technical Communications

These days nearly everyone I know with a car has a Satellite Navigation device. As a communication device they work reasonably well. Their visual instructions are very clear although the audio could be improved. In my experience the audio instructions fail when it comes to even slightly complicated scenarios. For example when on a roundabout (I think these are called traffic circles in the US) with two left hand exists side by side. In such instances “Turn left” is of little use and requires a look at the visual instruction at the same time as ensuring the white van man doesn’t cut you up!

The inadequacy of Satellite Navigation devices was reinforced recently when I was sent a joke email. In it were the following statements:

• The map really needs to start its directions on step 5 as I’m pretty sure I know how to get out of my neighbourhood.
• I wish they had an “Avoid Ghetto” routing option.

This got me thinking of what Technical Writers provide and whether the Satellite Navigation device wish list logic had any relevance in what we deliver. After all, the skills of the technical communicator include designing a structure that allows for where someone is, what they already know and where they are trying to get to. So to apply the logic to technical documentation…

Starting at Step 5

This is potentially perfectly acceptable, although it all depends on your audience. For example, would you tell a Secretary to open up Microsoft Word (or even turn on their PC) in order to type a letter? If you don’t, it assumes the user already knows steps 1 to 4 off by heart. The trouble is, this may not always be the case. Take another example, I bet you know how to operate the indicators on your car. Therefore instructions arguably don’t need to mention the relevant lever, just “Indicate left / right.” Now get into a hire car at the airport and watch the windscreen wipers go into action each time you want to turn a corner.

Getting back to the Satellite Navigation device, a potential solution for this scenario would be to start your procedural steps with something like “Proceed to Acacia Avenue” with a mechanism to display how to do so if you are not sure of how to do so.

Avoid the Ghetto

This one may be slightly more difficult and controversial. My Satellite Navigation device offers the options for taking the fastest or shortest route as well as others to avoid motorways or take a walking route. All great except that you don’t know what the shortest route is in advance. Maybe it leads you directly into that bottleneck by the Shopping Centre just as the school down the road kicks out its 1500 pupils onto the street.

In technical communication terms I’d see the solution to this problem as listing the different options, but explaining the implications of each one. Users can then make an informed choice of which way to go. For example, opening a file in Microsoft Word can be performed any number of ways, some of which do not even require the application to be open. If you describe double clicking a file in Windows Explorer, you could explain that the file is opened and that any other Microsoft Word file already open remains intact in another window. In the applications that I document, there are more technical issues related to how you do something. There are different ways of performing an action, but if users want to perform another action further down the line, they have to have performed the first action in a specific way. Our solution to this is to provide “best practice” tips to explain the best way to avoid a particular pitfall.

Once again getting back to the Satellite Navigation device, the “avoid the ghetto” option could be provided by listing the summary directions after the destination has been specified with the option to accept or divert from them where required. No doubt I can expect a job offer from Tom Tom or Garmin any day now!