Ode to FAQ

Technical writers tend to take a dim view of FAQs, those "Frequently Asked Questions" that, in fact, aren't questions. Much criticism of them falls into these categories:

• Hoarding. You couldn't figure out where to stuff this random bit of information, so it goes into the FAQ, just to be safe.
• Dishonesty. You want to feed them marketing information without seeming to do so, with disingenuous questions no user would ask: "What are the major features of ProductX?"
• Laziness. Gotta close this Jira by posting some kind of update to the docs, and just adding it to the FAQ (without rewriting the old topics) gets 'er done.

Yes, yes. And yet, I promise you that when I tackle a new product or platform, I often run first to the FAQ for a deliberate scan, especially if they're written by Support (who might publish them as solution articles).

But why? because FAQs often reveal what docs rarely do: friction.

We tend to write documentation starting with the Happy Path, the actions and sequence that yield success for the ideal use case. That's useful for quick orientation to what the product feature has to offer, but it's far from enabling. The iterative growth of the documentation should walk users through their use cases, as we discover more what they are, as we all learn more. We should craft the words and examples in a way that sets their expectations for what the product can and can't do for them, and what to try instead.

So: where docs are founded on Happy Path, the best FAQs are founded on pain. User pain. The good FAQs delve into the gritty and sticky parts of the product, where users get lost, mislead, and stuck. Done well, they reveal not only the bad news, such as an integration that isn't possible, but also the reason why and how I might approach the problem differently. They point to where the UI tends to confuse and frustrate. They reveal the chalk outline of missing functionality.

The reason I run to the FAQ with a new product is that I want to kick the tires and see what flies out of the wheel well. I'm perfectly capable of figuring out the happy path, but that's not enough. I want a peek into the limitations I may hit. I want to see where others have stalled out, with what use cases (which might affect mine). I want to hear workarounds, which reveal worlds about how things are actually working. I want to learn where others struggled, so I can choose another path. I want to jump into the messy stuff to grow my confidence that I can navigate around the pitfalls.

If I'm going to make a commitment to this product, I need the authentic stuff.

In the end, documentation should only exist to empower users. If a FAQ is written with that in mind, it's gold.