How to Create a Good FAQ
Literally translated, Frequently Asked Questions are frequently asked questions. A format that you've probably encountered many times. A set of popular questions about the product that may interest users, and short answers to them. Most likely, there is even a section with typical problems and their solutions in the instructions for your microwave.
By the way, which is correct – “Questions and Answers” or “Problems and Solutions”?
In fact, there are more options. Sometimes they write a literal translation of “Frequently Asked Questions” or simply “Frequently Asked Questions”, and the pioneers of Runet may remember the abbreviation “FAQ”.
All options (except, perhaps, the last one, which has become outdated) have the right to exist; there is no single correct one. But we prefer to call this section “Questions and Answers.” This seems to express the essence best and sounds simple and clear. “Problems and solutions” is also a good and familiar option, but if it really only contains problems and their solutions, and not questions and answers about the product.
Where to publish?
The most convenient option for the user is directly in the product, so that the questions and answers section can be easily found through the menu. If this is not possible, publish separately, for example, on a corporate Wiki (for internal products) or on a product landing page online. But try to embed at least a link to the FAQ into the product.
What's good about the question and answer format?
Why, even when there is a full user manual, do many people go straight to the FAQ section? First of all, it is as natural as possible for the user. Let's be honest, few people open product documentation simply out of curiosity or a desire to broaden their horizons. A person most often goes looking for it when he has a question or problem.
The format itself involves short answers to specific questions, without unnecessary words and sheets of text, which is also attractive, even on a visual level.
So if you want fewer support calls for the same questions, collect them and write answers. Yes, even if you already have a set of user instructions.
Can a FAQ section replace instructions?
Maybe. But it’s better to have both. The instructions are needed to study in detail the scenario of some action in the product. The FAQ allows you to get answers to specific questions and, ideally, should not contain long step-by-step instructions. When there is both, the section with questions can also serve as an entrance, even a kind of promotion for the section with instructions – we remember that it is usually much more popular among users.
Let's use an example. Question from the online store FAQ: “Is it possible to cancel an order that has already been paid?” In the answer, we should only talk about the fact that such a possibility exists, for example, and briefly describe the conditions under which this occurs. There is no need to give step-by-step instructions on exactly how to do this, which sections to go to and which buttons to press. The user just asked about the opportunity; he may still be at the stage of deciding whether to place an order. But after the answer, we can provide a link to a section of the guide that provides step-by-step instructions for canceling.
Sometimes frequently asked questions are added directly to the user manual. So it is possible?
Yes, you may see a questions section at the end of your user manual or instruction set. And sometimes a small FAQ accompanies each section of the manual. This is also a good idea, but I recommend that you still collect all the questions from all sections and duplicate them in one place, as a single section.
Let's just say that the main thing is to provide a quick search for the FAQ for the user. If we just hide it at the end of a long tutorial, few people will get there. But if you provide a direct link to it from the product menu or somewhere else where the user can easily see it, then no problem.
Who can write a FAQ?
This is the job of a technical writer. But the format is not the most complicated; you can assign it to any employee who is good with letters in your team – an analyst, tester, delivery manager, etc. Of course, after he studies this guide! 🙂 But remember that the Q&A section is usually well attended, so everything should be nice.
Ideally, find a technical writer, editor or proofreader for at least a one-time service, proofread the text, correct possible stylistic and grammatical errors, and achieve uniformity in the formatting of all issues.
If the FAQ is updated, try to have one person on the team responsible for it. If, as new topics arise, different people add each time, you will end up with a letter from Uncle Fyodor, like in the cartoon about Prostokvashino.
FAQ step by step
Step 1. Type questions
At the first stage, the task is to collect as many questions as possible that may interest users. There is no need to try to filter them and tighten up the wording yet, just type a list.
Here are some main sources for questions:
Complete all scenarios as a user. During the process, record any questions and doubts that arise.
Show your colleagues not from the product. It is possible for friends too, if they agree and the NDA allows it. The main thing is an unclouded look.
Ask users. If it is possible to reach end users, ask them what they do not understand about the product and what problems arise when using it. You can use mailing lists, feedback forms, etc. But be careful with B2C products so that users do not consider your requests as spam. It’s easier with internal products – you can ask fellow users for such help.
Ask for support. If the product is already operational and has been sent for support, specialists working with requests probably already have a large pool of frequently asked questions.
Read reviews in app stores. If you are working on an application that is in the AppStore and Google Play, monitor reviews there. Users often write there about problems and unclear points.
Add standard questions. It makes sense to start almost any FAQ with questions about why the service is needed and who can use it. Questions about your account are always relevant – problems with authorization, deleting your account, etc. If you have non-standard or temporary solutions, also “highlight” them separately. For example, you published a beta version of an application where the created request cannot be deleted in the interface, but you need to write to support for this. This is an atypical scenario; such scenarios should be described in the FAQ, as users will definitely have questions.
Step 2. Create the structure
When the questions are typed, sort and sort them to form the structure of the future section.
Combine similar questions and, conversely, separate questions that cover several topics at once.
Remove questions that seem too specific or related to already resolved problems.
If there are more than 15 questions, divide them into sections by topic, giving each a title.
Form the list from more general questions to more specific ones, from the most popular to the least.
If there are more than 10 questions, add a table of contents so that the user can easily find the question they need right away. Instead of a table of contents, you can use cards – with this layout, the user sees by default only questions, and by clicking on a question, the answer is revealed.
Step 3. Formulate questions
It's time to sharpen the wording of your questions.
Make sure the wording is consistent. Either they should all be formulated as questions, or as descriptions of problems. If the list contains both, turn them all into questions. For example, “I can’t sign into my account” can be reworded as “What should I do if I can’t sign into my account?”
Ask questions from the user's perspective: “How can I do this?” rather than “How can the user do this?”
Write in natural language: as we usually ask if something is not clear. Not a single user will ask “What is the timeframe for refunds on canceled orders?” He is more likely to say, “When will the money for the canceled order be returned?”
Keep it as brief as possible and make sure each question is about the same topic.
Give preference to open-ended questions. To the question “Can I redeem points when purchasing online?” you will have to answer simply “Yes.” The open question “How to write off points when purchasing online” will give you the opportunity to tell us a little about how to use this functionality.
Don't use marketing language when asking questions. No user will ask a question like “What unique capabilities does your service provide?”
Step 4. Write the answers
Finally, it's time to write the answers to the questions. The recommendations here are the same as for any other texts for users. And if you have a style guide and Tone of Voice of the product, of course, you need to adhere to the principles described there. If not, then the general principles of infostyle.
However, here are some basic tips:
Write in as simple a language as possible, without terms that may be incomprehensible to at least some of the readers. Here too, avoid marketing language, just talk about the possibilities.
If instructions and other user documentation are written for the service, do not describe detailed action scenarios in answers to questions, but provide links to instructions. It’s good form to do without diagrams and screenshots; this clutters up and makes the text heavier.
Don’t write too much, answer exactly the question asked. If the question is “How to redeem points?”, start answering it right away, rather than talking about all the benefits of your loyalty program.
Answer the question that is asked. It seems obvious, but I regularly see cases in FAQs where the question is asked about one thing and the answer is about something else. Check and, if necessary, correct either the question or the answer.
Step 5. After publishing
After publication, work on questions and answers does not end.
Make sure the text is up to date. Especially if in some answers you talked about temporary promotions, described beta solutions, etc. Delete or edit outdated questions in a timely manner. Typically, FAQs become outdated more often and faster than other user documentation.
Add questions and answers. Your product continues to work, functionality can be expanded, and users continue to ask questions. FAQ is a living format; it can and should be supplemented with new cases. Just try to always have one person responsible for additions.
Collect feedback. At the end of the section with questions and answers, it is logical to make a block like “Any questions left? Write to us.” This way you won’t leave the user alone with a problem if he couldn’t find an answer, but you yourself will receive valuable information on how to supplement the section.
