Monday, August 10, 2009

Help experience

I’ve often heard this line “If you (UX person) do your job well, we don’t need help”.

Sure, a well-designed, intuitive interface can reduce the need for help, but to completely eliminate all help assumes a perfect system and really, a perfect world (don’t think this is going to happen any time soon).

I recently began collaborating with our Documentation team on how to build a better help system in our products. While I’ve found a few articles around document presentation, readability, etc., I wasn’t very successful in finding overall approaches to Help usability. There were a few articles that focused on heuristics, like this one from the STC: http://www.stcsig.org/usability/newsletter/0401-heuristics.html

While heuristic evaluations can help, they don’t approach help by looking at the overall user experience, or help experience.

We decided to try an look at help more holistically. Here’s an example of what we found from a customer interview:

A particularly irate customer printed out the entire documentation (1000+ pages), thumped it down on the table, and then gave me a single error message they had received in the product. They were insistent that I myself try to use our help system, and they wanted to watch. The customer asked me to solve the problem (and remember their production line is down, and every second translates to money lost). I did the following:

1. Read the error message for any clues. It only gave the error type (error), error ID, and a one line message: Contact your system administrator.
2. Searched the documentation (online) for the error code
3. Searched the documentation (online) using various keyword searches
4. Browsed through the topics (online) in the documentation
5. Checked the support website (that lead me into other problems I won’t go into)

None of these approaches produced the reason or solution for the problem. After he shared his own approaches, all of which failed as well. The interface was well-designed, but the help wasn’t.

At first this seems like just a error message problem. If the error message had better explanations, there would be no problem. Yes, this is one area that needs improvement, and there are numerous articles on creating effective error messages for UX designers.

But we took this a step further. Sometimes the reason cannot be given for the error, or the error is produced from customer-side reasons that engineers can’t predict.

We started to evaluate the overall help experience: How is someone using the help? Are they even using the help? What do they assume they can find in the help? When to they turn to help? Etc. We then broke this down into concrete areas we could focus on improving collaboratively with the Documentation team. Here are some examples:

Written content:
Messages (info, error, warning, etc.)
Tooltips
UI text

Findability:
Search engine capabilities for documentation
How users call help in the system (help links, context-sensitive help, tooltips, etc.)
Grouping of information

Documentation usability:
What needs to be documented?
Readability of content
Presentation
Formats

I think there is a high potential of improving the overall user experience of systems by working with documentation teams to evaluate and implement help systems. What do you guys think?

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.