Little Springs Design. 2001 – 2010.

The other day the team here at Little Springs working on [the other big project] were talking about one of their next phase deliverables, a help system. So I jumped in and intruded with all my ideas. Open plan offices are great for this.

Especially in my time at Sprint, building large scale account management systems, I've run through a lot of serious help systems, that had to meet specific financial and satisfaction goals. So, I've not just designed a lot of help stuff, but had some user research, and metrics on effectiveness. I am therefore pretty confident these methods all work. It should also be mentioned that this is not mobile-specific. That's a subset which I haven't worked out quite as well, but will try to someday. This is more like application and web systems help.

And after I gathered all my best practices to present to them, it occurred to us that these seem to be published nowhere else.

My guiding principles are that most help systems suffer from two distinct problems:

1. That you need help at all.
2. Internal organization and jargon.

Solving these will guide you to the right design.

Problem: That you need help at all

What I mean here is that customers don't want help. They usually don't want to pay bills, or change their settings. In their heart of hearts, they just want everything to work, seamlessly. When it doesn't that's a problem, and help gets called on in these dark times to get them out of it.

To solve for this fundamental problem:

• Design as though you have no help system — I almost never design a help tab or little question-mark icons into my basic system designs. Any user going to help is a failure of the design, so work to avoid that with other design principles. Don't throw errors. Make everything clear. Set expectations, and follow them up.
• Pre-empt help questions — When you come across a problem, very often you can solve it by sticking the "help" content on the page. Whether it's explanatory intro text, hint text below the form fields, or a balloon that pops up when you fill in that field wrong, you can tell the user how to avoid errors, or that something is wrong before it's a serious problem.
• Simplify errors — Though back to system design, this is the sort of thing that often tends to come up only when detailed help documentation is being created. One example serves to illustrate this best: A web-initiated SMS sender I designed once, which attached to a number of different back end systems. Any number of them could fail, in a number of ways. Development had cut down the 80-some errors to 15. But the user can't fix them and they all meant "something is wrong, try again" or "something is very wrong, try again later." So we cut down to two messages, with basically that text. If you have more than a handful of error messages, something is certainly wrong.
• Place help content contextually — "Help" does not have to mean a pre-packaged, self-contained knowledge base. Often, it should not be. I covered this some in the pre-emptive stuff above, but the principles apply more universally. If the user calls for help, it can appear on the page. When browsing help, make sure it's a new window, and you can regain focus on the application (or browser window) so the customer can follow along with your recommendations. Make sure interactive help is at least no worse than a book open on their desk.
• Contextually link to and within help — Launching help should pretty much never just open a help home page. Take the user to the help topic, or section, for their current location in the system. Sure, there will be a search, and other navigational elements to help them move around, but most of the time help is related to the location from which it was launched.

Problem: Internal organization, and jargon

All too often I encounter, or have to build, systems that are communicated in the way the company works, instead of the way the user perceives things.

• No FAQs — We've all seen it: the "Frequently Asked Questions" section of a brand new website. Frequently asked by who? And it's true, that almost all of these are just what some marketing team or other has dreamed up. Users see through this. They are as cynical about FAQs as you can imagine, and disregard them whenever they can find a better solution. Not that the concept is bad. If you can actually talk to the customer service arm of the company, and get the top 100 call reasons, go right ahead and narrow them down to the top 10-20 basic problems. Be sure to highlight them somehow (whether inline or as a topic area on the help landing page). But don't call them FAQs if you want any users to read them.
• Gather and organize information carefully — The best way I have found, on anything like a reasonable budget, to get help topics written is as follows: Get "help topic writing" to be a task on each developer's checklist. Right after successful unit testing, he has to write up the topic. These all get gathered up, and the product manager (or account manager, or development manager, depends on the dev team) reviews them to make sure nothing is totally unexpected. They can also turn impossible jargon into something useful, or reject them as too dense and ask for rewrites. Then the UX team organizes them in a sensible manner (see next bullet) and gives the final result (with reference back to the original topics) to the tech writer to clean up. With more time or money, you bring the writer in earlier and earlier. To the UX meeting, to review, even to interview the developers directly about what they wrote.
• Organize help like the application, site or service — Assuming that you have managed to build your product correctly, do not then fall back on the way the business is run for your help system. In fact, once you have all the help topics in hand, laying the product information architecture on top of them is often a good organizing principle for the topics. Sub-organize and cross-link all you want, but make the topics reflect the product. This also helps when you want to link to the help system from any location; there's a heirarchically-relevant location in the help architecture to send them to.
• Use common terms, not jargon and brand terms — Unless of course, your product is full of jargon and brand terms. And even then, also use the more common terminology along with it "Super FrogConnect, high speed 802.11g WiFi, can be configured..." Be sure to use several levels of terminology, to appeal to experienced and novice users, as well as tying it to the product.
• Teach the users, using good educational practices — I am not an instructional designer, but I know some. All I remember is that I have encountered normal distributions with visual learners on one end, and textual on the other; and on one help system I included diagrams of the new account management structure. Which worked great. And is especially important if something about your system is new, or breaks previously-established expectations. Be sure to hire a good writer, at least, and someone like an instructional designer if you can. They'll tell you more about this.
• Don't make users classify themselves — In theory, knowing the knowledge level, or intended use of the customer is a great thing. You can give them the correct experience, or here the correct sort of help language. In practice, this is a total non-starter. Even when people can classify themselves in useful ways (which is rare) they usually resent it. You don't need more ways to annoy customers, so just present the information and take your best guess as to how to communicate to them.

Be trustworthy

There's a sort of third principle that emerges when you look closely at these, and that's Trust. Sure, it's a common principle of all interactive design, but as I explain in my book on design process it's good to identify which of these principles are most important to the targeted users of your particular product.

Certainly, help systems need to be easy to use, transparent, preserve user data, identify them personally and so on. But trust is the biggest problem. Customers seeking help are (almost always) having a problem. You are already in a hole, and any friction is going to add to the frustration.

Aside from informing the rest of the design, this leads to one last best practice:

• Let your customers call you

This is rejected a lot by folks looking to cut Customer Care costs. Phone calls cost money, so anything to redirect them is good. But it's one of those where the conventional wisdom is wrong.

I'm not saying calls don't cost money. But customers already on the website are (generally) trying self-care anyway. They want to solve the problem themselves. Putting the phone number at the bottom of every screen doesn't drive more calls, it gives customers the confidence that they can try to solve the problem themselves. If they can't figure it out, they know there's someone to help them. Call rates often go down the more you add the number to the website.

This is not a theory. Several times I have seen this borne out by data, and I've heard the same from others, in all sorts of industries.

So, in summary, my best practices for interactive help are:

1. Design as though you have no help system
2. Pre-empt help questions
3. Simplify errors
4. Place help content contextually
5. Contextually link to and within help
6. No FAQs
7. Gather and organize information carefully
8. Organize help like the application, site or service
9. Use common terms, not jargon and brand terms
10. Teach the users, using good educational practices
11. Don't make users classify themselves
12. Let your customers call you

This entry was posted on Monday, February 22nd, 2010 at 12:45 pm and is filed under Design, Design Tips, UI Design Patterns. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.