How do you answer every user's question?

by Tom Johnson on Jun 28, 2013
categories: findability

In my last post, I reflected on the most successful experiences I've had in connecting with users and decided that a foundational principle for successful user help is to answer the user's question.

I also realized that if there's been a transformation in the user experience of help at all in the past 50 years, one that has had a positive impact on the user experience, it's this: you can type a question into Google and find an answer.

The way Google provides answers to nearly every question imaginable has transformed the user experience of help in profoundly positive ways. The transformation is less about the medium (whether visual, textual, auditory) and more about the findability of answers.

Answering the user's question sounds easy, but it's actually quite difficult. There are a lot of questions, in fact, about answering user questions.

Anticipated questions or actual questions?

Pre-release, before you have actual users, you can only imagine what their questions will be. You can try to predict questions users will have. Formulating personas, putting yourself in user scenarios, and noting all the questions you have are good ways to predict user questions.

But once you release the product, don't consider your work done. After release, you can start focusing on real questions from users. To gather the real questions, you have to listen closely to support channels, forums, social media, and other feedback channels.

Rather than relegating the feedback to support, integrate the new questions and answers directly into your writerly workflow.

Which questions do you answer?

Do you answer all questions or just the most common ones? What if you have 500 questions to answer and only limited time to respond (and some of them are really hard questions)?

If you have a lot of questions, you can prioritize them. You could prioritize them in a number of ways:

• Easiest questions first
• Questions from most important customers
• Questions that have severe consequences if users have misinformation
• Questions most frequently asked

How to you find bandwidth to answer all the questions?

This is the golden question. Beyond foregoing sleep and working 80 hour weeks, you might approach questions by grouping them in similar categories. It's easiest to answer all questions about "widgets" and then answer all questions about "gizmos" and then all questions about "wackimos" and so on.

If you answer questions in 15 different directions at once, setting up environments to test, explore, and research the answers may require a lot more time and will be inefficient.

Also, you can chip away at the pile of questions one by one. Rome wasn't built in a day, and elephants aren't eaten in one bite. A journey of a thousand miles begins with a single step. You pick your metaphor/cliche.

How do you manage the question-answer workflow?

Questions come in through a variety of channels -- probably from your support center, a documentation feedback email, your user forum, and more. You need a system for cataloging the questions and tagging them into controlled ways that allows you to tackle all questions related to a specific topic at one time. It might also make sense to assign items of the same category to a JIRA or other bug tracking ticket.

How do you integrate short answers into help material?

Many questions may have just one or two sentence or paragraph answers -- hardly enough to constitute a substantial topic. Do you just write tiny little topics that function more like knowledge base articles? Doing so would at least allow you to optimize keywords in the title of the topic.

I've written before about topic length, and I argued for longer topics. The chances of someone landing on the topic and finding an answer are greater if the topic is more substantial, since the topic will have more keywords and therefore have a greater chance of connecting in some way with keywords in the user's search. However, longer topics require you to synthesize more material and go deeper with the content.

For the user who just asks, "How do I resolve error 555 with widget Z?" do you tack the answer on as a note to some other widget topic? Do you create a new "Error Messages with Widgets" topic and hope that you get a few more error messages to handle?

Here's my recommendation: If the answer relates to another concept or is associated with a particular task, add it there. But if it doesn't, let the topic stand alone.

At UA Europe, I attended a great session on SAQs by Tony Self. SAQs are Seldom Asked Questions. Tony presented a ridiculous variety of Frequently Asked Questions that must have been anything but frequently asked, such as "Can I bring my rugby and kayak equipment on board with me on the plane?" (from an airline website).

Tony argued that writers often get lazy in integrating information into the right topics, so they just throw the information into the same miscellaneous topic and call it an FAQ. He recommended that writers integrate the content in the appropriate place in the help system and eliminate FAQs altogether.

Regardless of your approach, if users search for answers, they'll probably find the answer whether it's buried in a FAQ/SAQ, or whether it's pulled out into its own topic. It's probably more important to simply include the content somewhere in the help. Rely on the fact that the search box will make the information findable.

When does navigation become useless?

Let's say that you start racking up the answers about Wackimos and although you started with a handsome dozen topics explaining Wackimos, the feature has become really popular and you've now quadrupled the amount of information about Wackimos. Many of the topics are simple paragraphs that answer random questions about Wackimos, such as whether they're used by Eskimos and such.

At some point, when you add too many topics, you cross the threshold of usability with a TOC. Especially with knowledge-base type articles that have no sequential nature or pattern, it's perhaps better to tag the content and roll up the topics into various views. The knowledge-base-like approach to help material requires us to leverage a system of tagging (with controlled vocabularies) to manage the endless content. A TOC simply won't hold it all.

What finding mechanisms do you employ?

As you add more and more information to your content, the information becomes less of a friendly experience for browsing and more of a search-dominant experience. But that doesn't mean you have to ditch all browsing mechanisms. For those topics that are your core, primary topics, the ones that users need to read to understand and use the system, keep them in a tightly monitored TOC.

But for those topics that are more kb-article like, let them float freely in your database and only surface through search. After all, your advanced users aren't browsing the help. They're searching it for specific questions. Your newbie users are browsing the help, but they only need the primary, newbie-oriented information.

How do you know if users' questions are getting answered?

If you're monitoring an inflow of user feedback through support channels, forums, and email, you have a clear record of feedback. If you wanted, you could catalog the feedback and monitor the trends.

Most likely you're entering the information into JIRA or some other bug-tracking database. You can run reports in JIRA that show you all issues resolved by a variety of criteria. You might create a tag called "customer-feedback" that would allow you to group these issues by date.

Conclusion

As you can see, answering the user's question is not a straightforward process. There are a lot of details about strategy, process, workflow, and bandwidth to work out. I'm interested to hear your approach to answering the user's question.