Step Results: Clutter vs. Assurance
Sometimes a result statement in a step just adds clutter and annoys the readers (if not out and out insults their intelligence).
Example
- Click on Print Properties. The system displays the Print Properties dialog box.
Always useful in case the user wonders what this box is that just popped up that says Print Properties.
Most user assistance writers use result statements sparingly, but there are situations in which they are very valuable:
- If the user might be unsure what action the system will take and that uncertainty could make her reluctant or anxious to take a step
- If the system does something significant in the background that the user will not be able to see
Examples
I had this one today. The user interface had a link that said "Click here to update to version 1.5839" displayed in blue font and underlined in normal link convention. I didn't know if it was a true link or if it was a link being used in lieu of a command button. Was I going to go to a screen that told me what 1.5839 did or would I just launch the update? It turned out that I got a confirmation box and then the update. In that case, the Help should include result statements:
- Click on the link Click here to update to version version number. The system displays a confirmation screen.
- To confirm that you want to install the update, click OK. The system installs the update.
Why? Ambiguous UI control.
Result statements can also be useful when the UI is weak on confirmation messages:
- Fill in the form.
- Click OK. The system updates the record and clears the current form.
This deals with the angst of suddenly having your data go away and wondering did it go anywhere useful. I think a lot of my data goes to a house in Indiana that has the lightbulb that the switch in my hallway turns on and off. I think some of my singleton socks are there too.
1 comment:
Agreed. FWIW, I usually suppress results statements in online help, but enable them when reusing the help as a printed manual.
Post a Comment