Technical Communications Writing

No, You Don’t Need An FAQ. FAQs Must Die.

I’ve never been on Jeopardy, although I watched it on occasion when it was still running in Norway. As much as I enjoy trivia games, this was never a favorite of mine. The “answer must be a question” rule leads to lots of contrived questions, and contestants get eliminated for not remembering the “Simon says” aspect, even if they know the answer.

I’m A Writer, Not A Jeopardy Contestant

When you write for an FAQ, you take out the fun factor and big prizes, but keep the stilted and awkward aspect. No matter the topic, you have to turn everything into a question.

I will take most format challenges anytime: I write text for graphical user interfaces, I follow patterns when documenting procedures, I tweet. Then again, those are all exercises in conciseness, and I love concise, especially in technical communications.

The frequently asked questions format seems concise enough; an FAQ section is usually built up of small, discrete topics.

But in my experience, the opposite is true. From both a writing and reading point of view, I find FAQs to be contrived, redundant, and inefficient.

And that is why FAQs must die.

The UK Government Digital Service has made a fantastic case against the format in FAQs: why we don’t have them.

1. The FAQ Format Is Contrived

The biggest FAQ I ever worked on was a poorly defined database of articles meant to cover everything people couldn’t find in the general documentation. Yes, I admit it had plenty of issues alongside the question format.

The writing team had previously agreed upon an FAQ format, but many of the best entries still had titles that were scenarios, as these articles were often written for troubleshooting purposes.

Imaginary example: “My client times out when trying to connect to the load balancer.”

A helpful colleague, realizing that these couldn’t be read as questions, decided to go through the whole thing. At each scenario, they would toss in full stops and a “Why?” at the end to fit the format where needed.

“My client times out when trying to connect to the load balancer. Why?”

Every time I saw one of those titles, the “why” would take on this whiny, accusatory tone in my mind. It may not have read very well, but my colleague was doing the right thing entirely, both for the sake of consistency and for demonstrating the shortcomings of the format.

In the end, we agreed that we would call it a knowledge base rather than an FAQ and drop the question requirement. We even got a few other publishing guidelines implemented.

By all means, create a knowledge base if you need one, but define it well and don’t force a question format.

2. FAQ Headings Are Redundant And Unscannable

When you turn headings into questions, you add filler words, and you mostly lose the opportunity to frontload—putting the most significant words, the keywords users are actually looking for, first.

The same thing goes for “how to”-style titles, even when there is not a question mark at the end.

To see what a poor idea this is, try listing several of these headings after each other as they would be in search results or an index. What you get is a list that has low scannability and lots of redundancy, which is not what anyone wants in a list. (I have written about the value of scannable lists before, in Making a list? Check it (at least) twice!)

3. FAQs Are Not Efficient Communication

Why make people look for the question?

If you know the questions people are asking and at which point when interacting with your product, website, or company, then you can probably reassure them without asking the question out loud for them.

The important thing is making sure the information they need is available at the right time.

As an example: The question I most often ask myself as a visitor to non-Norwegian ecommerce sites, is whether they ship to Norway. Finding out usually requires digging through shipping policies or, in some cases, going through most of the checkout process until getting to a dropdown without my home country in it.

Surprisingly recently (it’s not like the technology is new), more sites have started using IP address sniffing for good. I am thrilled when a site displays a small info banner the moment I access their site, stating whether they ship to my country of residence. THIS is what I want: information before I waste my time.

The FAQ format is inefficient. It’s not the question people are looking for. The nature of FAQ headings also often leads to having five tiny articles or sections where one slightly longer writeup would have been sufficient.

Content strategist Hilary Marsh has some great examples and does a terrific job of explaining Why FAQs are not effective web content.

FAQs Won’t Just Go Away. Why?

The UK Government Digital Service wrote FAQs: why we don’t have them in 2013.

I had hoped that by now, with increased focus on usability, scannability, and search engine optimization through keyword frontloading, that new products might start avoiding the FAQ format.

Still, I keep hearing “and then we’re going to need an FAQ”. My suspicion is that:

  • “FAQ” has become shorthand for either “bite-sized information” or even “searchable documentation”.
  • Most people wouldn’t bat an eye if they clicked on “FAQ” and found a knowledge base without question marks in the headings. As a writer, I may obsess over genres, but I know that most readers don’t. Neither do the managers that tend to bring up the requirement.

As for search engine optimization, the pendulum swings. Many search engine optimizers are adding more questions to their content in attempts to get into Google’s featured snippets, the “answer box” displayed above all the other search results.

The sad thing here is that Google’s logic for picking answers seems primarily focused on the question and its exact wording. The quality or accuracy of the answer appear secondary, demonstrating again that the question really isn’t what the user is looking for. The logic needs to become a lot more sophisticated, and I assume it will.

How To Kill An FAQ

Over the years, I have v e r y slowly worked my way up from growling “NO!” and sharing that link from the moment someone mentions “and we need an FAQ”.

Now, I’ll let at least a few seconds pass! I might not even speak the words “FAQs must die”.

On a good day, the cool, calm, and collected answer is: “Of course we need to make sure we are answering people’s questions.” Or even, if you know the scope is significant, “Sure, we’ll need some sort of knowledge base”. And then “What are the questions people are asking, and when? Do we know, or do we need to start finding out?”

You should be the one looking for questions, not your reader.

And if you can answer before they even think to ask, the FAQ is well and truly dead.


Marketing Writing

Dear [Firstname] at [Company] — Drop the Fake Friend Act

Dear [Firstname] at [Company],

Today, you sent me a message that pushed me over the edge after a blogging hiatus that has been far longer than I like to think about.

Subject line: “Was it something we did?”

Body: I have no idea, do you honestly think I opened that? The message was clearly based on some pre-configured logic catching users who signed up for your service eons ago, then stopped using it. I’ve tested a lot of services for work in the past year, most of which I’ve left behind. It was less something you did and more something we didn’t.

But why oh why would you think it’s appropriate, funny, cute, or *shudder* engaging to sound like a needy ex-partner?


Today’s overly attached subject line was not an isolated incident, of course. Just a handful of fairly recent examples from my inbox:

  • A subject line welcoming me to the [service] family, message starting with “Hey, you’re awesome!!”
  • A “thank you for upgrading to a pro account” message signed “Your friends at [company]”
  • A service sign-up response with the subject line “Friend, welcome to [service]”

All sent, of course, by [Firstname] at [Company] — a trick so ubiquitous it no longer stands out in the least in the increasingly crowded Promos section of my Google Inbox.

Most of my personal and even work messages now go through chat, but everyone and their grandmother’s company is bombarding me with email as a lead or customer — “drip campaigns”, auto-responders and quasi-personal messages intended to steer me along the journey to conversion from lead to customer, and from customer to evangelist.

But I must admit, [Firstname] at [Company], it’s increasingly rare that I even open your messages. And you just seem to get chummier and chummier.

I expect your company does a lot of A/B testing, so please do tell me: Does the bromance lingo actually work on a majority of your targets? Because to me, really, very little could be more alienating.

It may have to do with regional culture, it may have to do with being too old to be part of the main target group for Every Marketing Campaign on Earth — millennials — but honestly, even a few millennials have mortgages and PTA duties and the odd gray hair and cellulite at this point, are you really sure they don’t prefer being talked to like grownups?

And for those who would be on board with the “you’re awesome double exclamation mark” thing amongst actual friends, are you sure they don’t see you as something of a wannabe, or like the awkward parent who picked up a little bit of slang 10 years ago and still thinks it’s the bomb?

[Firstname] at [Company], are you sure you're not sounding a little like Vanilla Ice: Oh, I'm just coolin?

Why Can’t We Be Friends?

One of the reasons I’m ranting about this is that since going from tech writer at a massive corporation to information architect at a small company where everyone wears a rich selection of hats, technical marketing for the business-to-business market is a form of communication I’ve suddenly had to care about. I’ve been reading up. And I’ve despaired, discovering that “landing pages” does not actually describe pages for visitors to land on, but pages for businesses to land people’s email addresses.

After reading a few more marketing blog posts than was clearly good for me, a bit too much of it started to make sense. Then, thankfully, I was lucky enough to spend most of last week at the Information Architecture Summit, an amazing conference about IA and user experience, whose theme this year was inclusion and “a broader panorama”. What happens when we put people at the center, when we design inclusive experiences, when we genuinely care about the humanity of every user, visitor, customer? And I came back reassured that what doesn’t happen is shiny happy auto-responders holding hands. (I learned a bunch of other stuff, too. There will be more blogging.)

So no, it’s not that I don’t think that businesses can have interesting information to share with (potential) customers by automated email, or that customers and vendors cannot have a friendly tone when they know each other — on the contrary. But here’s the thing, [Firstname] at [Company], the two are entirely separate things. And because you are not a person, but a set of merging and mailing rules, that is something you will never understand.

And that is why we can’t be friends. So can you please drop the act?

Not exactly yours,


Editing Writing

Making A List? Check It (At Least) Twice!

List writing can be a great way to make content accessible and scannable and give readers an overview. Lists are everywhere, and for good reason.

A well-written list can be a quick read, but when making a list, taking some time to properly consider the format and syntax will pay off in clarity and helpfulness for your readers.

Below, I have gathered some advice for writers and editors dealing with lists, based on my own writing and editing experience. If you have other tips or pitfalls on your mind, please share them in the comments!

Use The Right Kind Of List

It’s easy to think that usage conventions for list types are exactly the kind of thing only writers would care about. If you think that way–I have myself on occasion–then consider this progress screenshot from a WordPress backup plugin that I recently installed:

Screenshot of a message saying DO NOT DO ANY OF THE FOLLOWING and goes on to list in numbered sequence 3 actions not to perform while the installation is ongoing. When making a list, try not to confuse people more than necessary.

Without reading this multiple times, would you feel certain that you were actually not supposed to do anything mentioned in this numbered list? The introduction says one thing, but the choice of list type is communicating something different entirely.

Use an ordered list if you are describing any of the following:

  • a procedure to follow
  • a sequence of events to observe
  • a clearly prioritized order

Some may also prefer alphabetical ordered lists for options where only one may be selected (“Do one of the following: a. b. c. d.”).

If the list is not a sequence, an unordered bullet list is the most common option. However, long bullet lists are not particularly easy to read. For lists that are long and/or include a lot of information in each list item, these two other options are worth considering:

  • description lists (definition lists pre-HTML5) for glossaries, metadata listings, and similar. These tend to be styled in a manner that make them a lot more scannable than bullet lists. See Mozilla Developer Network for a good description and examples.
  • tables. I know, tables are not actually lists, nor do they have the Twitter or Pinterest appeal of a Top 5 list, but for reference-style material, a table provides much better findability and overview than a bullet list.

I like lists, I’m controlling, I like order. I’m difficult on every level. (Sandra Bullock)

Avoid Redundancy

List items that start identically, or semi-identically, reduce scannability. Keep in mind that tables of contents are also lists. If you have a table of content that is generated based on your headings, considering each heading a list item is useful.

To ensure list items remain scannable, you can:

  • front load each list item by starting with important keywords that set it apart from other list items rather than something generic , such as “You will need to …” or “For simplicity and ease of use, we have …”.
  • move repetitive phrases outside of the list itself. For example, instead of starting each list item with “how to”, make “how to” part of the introductory phrase that comes before the list.
  • drop any words and expressions that don’t add to the meaning. In most cases, list items don’t need to be complete sentences.

As a bonus, if your writing will be translated, you’ll save money by avoiding redundancy.

Every morning I get up and look through the Forbes list of the richest people in America. If I’m not there, I go to work. (Robert Orben)

Be Consistent

In a list, each item should have a similar syntax. This is a pet peeve that probably annoys me as a writer more than most readers, but I have seen plenty of bullet lists that would be confusing for any kind of reader.

Before unleashing a bullet list on the world, read through it starting with the introductory phrase and check that all list items:

  • start in a similar fashion to the others and read as a grammatically correct continuation of the introductory phrase. If the introduction says: “This chapter will tell you how to:”, you cannot have list items starting with “making” or “configuration”.
  • share the same grammatical subject or state their subject clearly. Otherwise you may easily conflate, for example, something done automatically by software with something  users must do themselves, or something the software vendor can do for you upon request. In my experience, this problem is not uncommon in lists of features and software specifications.
  • use similar syntax and punctuation. Mixing questions with statements in the same list will usually not read well. Whether or not to end each list item with a full stop is a style/preference issue. It is also painfully hard to remember and follow up on in a consistent manner.

We like lists because we don’t want to die. (Umberto Eco)