Discordant Instructions

Sometimes, it becomes obvious that the copy writers and the form designers are not sitting in the same room and are probably contending with each other for dominance in the creative department internal politics of interactive agencies everywhere. Or maybe it only becomes obvious that nobody is paying attention to the actual interface when writing the instructions or paying attention to the actual text when designing the interface. The following examples show a couple of places where these things don’t confluentiate.

For starters, I’m always a fan of the separate thank you page for a successful form submission. When you do that, you have complete control of what’s on the screen when you thank the user. If you just swap success text in place of the form, you have the chance (1-5 on a d6, 1-4 on a d6 for elves) that you’re going to leave instructions on the screen:

Enter below, where there's no form
Click for full size

Notice how the form tells the user he or she can enter below, even though the application has removed the form to display the success message. The user cannot enter below. The application is faulty, and if this were an old Star Trek episode, Captain Kirk and the landing party would use this confusion to escape.

Here’s a bit of legal text for a contest entry that no one involved with the form design has read:

There is no Accept button.
Click here for full size

The instructions tell the user that he or she will have to read the rules and then click the Accept button, but then the form doesn’t have an accept button. It doesn’t even have an accept checkbox. So legally, I suppose, no one has complied with the terms of the sweepstakes, and the sponsor doesn’t have to award the prize. Come to think of it, maybe someone did read it all.

Regardless, I find it exceedingly inelegant when the labels of the controls (or their presence) doesn’t match the instructions given. In real applications, this often happens because the technical writers are told to document software that’s still changing in the interface and/or because the freaking technical writers don’t actually bother to run the applications they document. Special note to our technical writer readers: maybe not you, but some actually do that; trust me, I know. True anecdote: one day, after I made the move from technical writing to QA, my replacement came to me to ask me about the layout of a screen as I documented it in RoboHelp (street cred as a tech writer in that word, werd). Apparently, the developers referred to something on the screen that wasn’t called the same thing in the documentation, so she decided to ask me about it. I went up there, looked at the doc, and said, “Well, let’s open it up and look at it.” But you see, my friends, she was actively updating the documentation for a desktop application without actually running the application. So she was flying blind, and no doubt her work showed it.

I’m not saying QA should review all technical documentation, although if you can spare the bandwidth, you do have a small case for doing so. However, you should make sure that on screen instructions, whether on a Web page or in a tooltip, make sense and are correct and grammatically sound.

If not you, then who? The client, the increasingly dissatisfied client, that’s who.

Comments are closed.


wordpress visitors