What users are looking for (hint: FAQs)

I spent last week researching support and learning management systems, working on a documentation delivery schedule for the rest of the year, and responding to a few complex support cases.

Those support cases, along with some comments from other users, have made me rethink my opinion of FAQs. Maybe it’s more accurate to say that this feedback is pushing me in a direction that I’ve been trying to avoid, while I knew that I was fighting the inevitable.

What’s wrong with FAQs

I’ve seen arguments for and against FAQs, and my views have been “against.” A FAQ is just a tiny bit of information, often without a lot of context. The “question” part is often contrived, and at best it’s a guess by the author or something they think the users should ask. Or it’s shallow marketing content masquerading as more technical information (“Why is this product so awesome?”).

But those are FAQs done badly. They serve the company, but not the reader. But this means they don’t serve the company very well, since they tell the reader that there’s no real content to be found, just marketing fluff. (As opposed to useful marketing content, which is rarely found in something as small as a FAQ entry).

The real problem

The real problem is that the information in a FAQ should be in the documentation. So if it’s in a FAQ, it’s either not in the docs, where it should be, or it’s a piece of repeated content. Why repeat content when you can direct the readers to more complete documentation, which they should be reading?

Because that’s telling the users to shut up and take their damn medicine. That’s making them do what WE want them to do, when they’re probably looking for a quick answer that will let them continue working. They don’t want to be told what’s best for them, and they certainly don’t care that we spent a week writing, editing, and perfecting the topic that we think they should be reading.

FAQs are a snack, and I’m trying to serve the readers a complete 7-course meal, dammit! Look at all of this that I’ve created for you! There are release notes, a getting started guide, a UI overview, descriptions of every menu option, a tasty selection of common workflows, and an error message reference! I spent so long figuring out what those error messages mean!

At some point, your customers will need those things.

Shut up and do your job

Sorry, not you: that’s what I say to myself. Because who am I to tell the customers what they want? That’s not my job. My job is to answer their questions (and anticipate their questions) as quickly and completely as possible. Yes, I want to guide them to new and exciting features that will make them love the product even more. But when someone is using a product and wonders what the heck that column name means, or whether they want to see a high or low value in their results, or what happens when they check that box, they don’t want to read three pages of useless cruft (to them) before they get to the answer. Because they won’t bother. Do you?

When I need to know how to make a non-scrolling header in Excel (which I do every damn time I use it), I don’t want to read the history of headers, every possible thing I could do with a header, or 5 other things I could use instead of a scrolling header. I just want to know which button I need to click and where it is. Then I’m done and I’ll move on with my work (spending 30 minutes figuring out the exact color, shade, and opacity level to use for the header background, then testing every pattern only to decide, again, that I’m not going to use a pattern).

It’s not my job to tell the customer what they want. My job is to answer their question so they can keep using our wonderful product, and so they don’t open a support ticket. Or just decide that the product doesn’t do what they want it to do and give up on it.

Embrace the FAQ

Both directly and secondhand, I’ve learned about users asking questions that are documented, but obviously not being delivered in the way that the customers want (and can find easily). “How do I change my password?” is an easy one. And if you search for “password” on the knowledge center you’ll find the doc. But I put that in the topic “Configuring your [product] preferences,” or maybe it was “Setting.” Either way, that was just dumb. It was a UI-based topic, not question- or workflow-based. There’s a Preferences dialog that contains a few settings, including the user’s password.

It’s obvious (now) that I should have written a topic like “Setting your password.” Which would be a short FAQ, even if it didn’t say “FAQ: How do I set my password?” And it can link to topics about the other things you can do in that dialog, but it should just answer that very basic question.

That’s an easy example. Of course a basic workflow like that should be documented! How could I not have expected that one?

But another question that comes up every so often is “When I follow this particular workflow, what do the results really mean?”

The answer is in the documentation describing that workflow. But I’m seeing two additional requests: “how do I interpret the results?” and “give me a quick description and I’ll figure out the rest.” The former requires its own topic. The “quick description” topic can be a FAQ item that then links to the longer topic, and to the more complete workflow topic.

That’s three topics to answer three scenarios: the complete start-to-finish workflow; the “skip the Click Here parts”; and quick reference information. Although only one is really FAQ-like, it serves the reader who has to turn to the documentation to answer a question, and isn’t looking for any other context.

Isn’t search good enough?

Most users turn to the search box to find what they’re looking for. But there’s the “last mile” problem, where the reader finds a likely topic but has to wade through other information to find exactly what they’re looking for. Maybe it’s really great information. But if it doesn’t answer the immediate need, then it’s not useful to them.

The problem is the same one I have with content reuse in general: a search will return multiple hits for a piece of content, and it’s often unclear to the reader which is the right one. If the topic has a clear title, then the reader has a better chance of finding the right one. And “right one” means that they find the answer to their question as quickly as possible and don’t get frustrated with a lot of irrelevant (to them) information.

I’m arguing both sides again

So what’s my conclusion: FAQs are good, but content reuse is bad? That’s a nice contradiction, unless you put all of your help in tiny-topic FAQs. And I don’t recommend that.

It helps support the Quick In Quick Answer method of using help. (There’s a better name and acronym, isn’t there?)

But it adds yet another task: figuring out which bits of information are most important to your users, and which will make sense without a lot of supporting information. I’m putting together a short list of FAQs based on support requests, which is a better way of doing it than (wearing my Lone Tech Writer hat) trying to guess what will be most important to my customers.

And certainly better than telling them to stop complaining and read the brilliant documentation that I spent so much time creating.

9 thoughts on “What users are looking for (hint: FAQs)

  1. Yup. All that.

    But I would make this distinction. We should not be writing FAQs. We should be writing the topics that solve user’s problems and we should be providing multiple ways for users to find them. One of those ways should be a list of the topics that answer the most frequently asked questions. Those topics should not be written differently from any other topic. They just appear in the list (unbeknownst to themselves) because they happen to be frequently asked for. Ideally (this being 2014 and all) that list should be created and maintained dynamically by your WCMS. (Note that in some cases, what is frequently asked will change dynamically depending on events. Currently trending questions is the think you really want.)

    The size things is difficult, because different readers come to content knowing different amounts of stuff about a problem. If we chop too finely, those who know less have a hard time piecing things together. If we go on too long, those who know a lot have a hard time finding what they need.

    The best compromise, I believe, is
    * write topics that treat a narrowly defined subject completely on one level so as to maintain essential continuity of thought without getting too long or going off on tangents.
    * use a consistent and explicit structure, for those who only need part of the topic can find it.
    * link richly to related subject so that those who need more can navigate to it.
    * Don’t mix reference material into narrative works. Solid reference material is the backbone of any good documentation set.

    As for reuse: on the Web, it is better to link than to reuse; on paper it is better to reuse than to link. (Yes, that means single sourcing is a crock, unless you can differentiate at the information design level, not just the formatting level.)

  2. I agree with Mark – better linking, better titles, shorter sections that focus on one aspect, is the way to go. Have a clear and consistent way of separating conceptual/reflective content from the instructions (after all, they are serving different user needs).

    Personally, I hate FAQs and never use them. If I see a site where there are FAQs and the option to raise a ticket, I’m raising the ticket straight away. I don’t want to spend time searching through other people’s issues on the off-chance I will find one that matches mine.

    1. I agree, too. The problem is that users are looking for FAQs. I get frequent requests for “just this piece of information,” which means that I’m doing something wrong. Making the search box more prominent has helped with that, but some customers want something explicitly named “FAQ” and that fits their idea of what a FAQ should be (short question, short answer, a few links to more info).

      So I’m balancing user expectations with what I know to be good documentation. Fortunately, there isn’t a lot of separation, but I do have longer topics that go into a lot of detail about some things (data analysis can get pretty complex). Similarly, some readers look at a long topic and tell me “TL;DR, give me a video!” But it seems that many tech communicators aren’t as fond of videos (we’re used to reading a lot; videos take a lot of time to do well and they’re a pain to update).

  3. “at best it’s a guess by the author or something they think the users should ask. Or it’s shallow marketing content masquerading as more technical information”

    Although the concept of documenting FAQ explained is followed widely. We convert known issues and the most asked questions on forums into FAQs. Is it the right approach?

    1. That’s what I’m working on, but both Mark and Craig make excellent points (and I agree with them) that making the existing documentation more FAQ-like (stripped down, better linking) will achieve the same result.

  4. What do you think about using FAQs as a quick (or rather, alternative) access to the actual documentation? I did that once, each FAQ had a brief description and a link to the topic in the manual for more details. Of course this was a compromise, the available time did not allow for more and we had to work with the existing content ‘as is’, but looking back the result was not too bad.

    Creating FAQs that are duplicates or reworked versions of other content does not make much sense to me, unless the documentation is so badly structured that users need excerpts simply to be able to read and understand it.

Comments are closed.