“Pushing the Envelope” from ACM <interactions>, September/October 2006
By Fred Sampson
wfreds@acm.org
How often do you turn to the person in the next cubicle or down the hall for help with a software application? Does your teenager program your cell phone for you? How often are you called on to provide training just because it’s easier to ask you than to look it up? Is it really that hard to press F1 on your keyboard? Is the help system that useless? Or are user interfaces still so baffling that you don’t even know where to start?
Wouldn’t it be nice if friendly, helpful advice was built right into the system? Microsoft tried that approach, but Clippy is dead and buried—isn’t he? Many of us hope so. Clippy was more intrusive than helpful, and smarmy to boot. I once knew a woman who liked Clippy’s personality; in fact, she said, “I would date him.” (Yes, she needed to get out more often.) She may be the only one who misses him.
Help. User assistance. Embedded help. Assistance platform. Pop-ups, tool-tips, mouseovers, hover-help. User documentation accessible from the interface comes with many names, and varying effectiveness.
Do most users just not want to be bothered with using help? In one of my early mobile device projects, we ported an existing customer relationship management application to WAP-enabled cell phones. We assumed that the field sales representatives would already know the basic application; still, I suggested providing at least a quick-start card to help them through learning this particular implementation. The product manager rejected my suggestion, assuring me that the users, being salespeople, would just throw the card away. Which left no user assistance at all.
The challenge of small mobile interfaces is in making their use sufficiently obvious that no additional documentation is needed. The manual for my new cell phone is bigger and heavier than the phone itself. The phone’s primary function is readily decipherable: I can make a phone call without reading instructions. The initial setup instructions are carried on a transparent peel-off covering, much like the iPod’s. After I initialized the phone, it just worked. But the rest of the functionality is a mess of features of questionable value to me.
What do the cognitive psychologists amongst us know that we are not yet applying to user assistance? We already know that we can’t force users to read documentation. What if we provide the information that they need without them realizing that they’re being helped?
It used to be that development managers could get away with saying, “Well, we’ll just have to document that” when faced with intransigent coding problems and no elegant solutions, which is where Frequently Asked Questions (FAQs) come from. FAQs do not address questions that users frequently ask; they address problems that the developers couldn’t fix, which turns their design or coding problem into the user’s problem. We know better now, don’t we?
A poorly-designed user interface cannot be documented, and a well-designed interface doesn’t need documentation. You cannot write enough words to fix a bad design, and a good design already has all the information that a user needs. A self-documenting UI is much more useful than putting more words into a book that will sit unused on an inaccessible shelf. Rob Chandler quotes a writer who says, “The goal of the UI designer is to put the Help author out of a job.” (Not to worry; we’ll just become information architects.)
Of course, embedded assistance must be useful to be effective. A tool-tip pointing to a text field that says “Enter text” is more irritating than helpful. A tool-tip that instructs “Enter street address” when the field is already labeled “Street address” is redundant. Learning to write appropriate and useful embedded assistance is as important as designing usable and obvious interactions.
Well-written page or screen titles and error messages provide help without users even noticing. Messages that help solve a problem instead of just announcing that there is a problem can make users feel good about their experience. Titles and messages are a form of embedded help, because they’re part of the interface. The Microsoft Inductive User Interface Guidelines even admit that “documentation writers and editors should be involved in coming up with screen titles because their expertise include[s] choosing words.” That’s right: Your writers and editors are part of your design team.
My mentors in technical communication instilled the belief that information should be part of the interface. Andrea Ames, information architect, teacher, and past president of the Society for Technical Communication (STC), says, “Design the interface as if the product will have no documentation.” Implementing effective user assistance means making the help available when and where the user needs it. How close are we to that goal? What is the state-of-the-art in user assistance?
I will have the pleasure of editing a special section on the intersection of HCI and user assistance for the January-February 2007 issue of <interactions>. If you can enlighten our readers on the topic, please request the Call for Participation and submit a proposal to me at fred@fredsampson.com.
References
Chandler, R., “UI and UA changes on the road to Longhorn.” The Code Project, http://www.codeproject.com/dotnet/LHChangesUA1.asp.
“Microsoft Inductive User Interface Guidelines.” http://msdn.microsoft.com/library/en-us/dnwui/html/iuiguidelines.asp
Price, J. and Price, L., Hot Text, Web Writing That Works. New Riders, Indianapolis, 2002
About the Author
Fred Sampson is a co-chair of BayDUX, Vice President for Finance of SIGCHI(as of July 2006), and a senior member of STC. In his spare time, Fred works as an information developer at at IBM’s Silicon Valley Lab in San Jose, California. Contact him at wfreds@acm.org.
Copyright Notice
© ACM 2006. This is the author’s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ACM <interactions>, Volume XIII.5, ISSN 1072-5520, (September/October 2006), http://doi.acm.org/10.1145/1109069.1109077.