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.