1# FAQ Writing Template
2
3FAQs are designed to offer concise responses to frequently asked questions, covering a range of topics from fundamental product or service concepts to feature explanations and common usage inquiries.
4
5These FAQs are compiled based on the most common questions posed by users and are incorporated into the developer's documentation. By addressing individual user concerns and identifying the underlying issues, they cater to real-world usage scenarios, thereby assisting a broader user base.
6
7## Criteria for Effective FAQs
8
9* FAQs serve as reference materials for users when they are unable to resolve issues on their own.
10* The effectiveness of an FAQ is judged based on two main criteria:
11  - First, whether users can quickly locate the relevant FAQ.     → **Titles and symptoms**: acting as guides or maps, which are essential for pinpointing the issue.
12  - Second, whether the FAQ can guide users to solve problems effectively.  → **Possible causes and solutions**:
13
14A typical FAQ consists of the following three parts:
15
16FAQ = Symptoms + Possible Causes + Solutions
17
18Problems can be complex or simple. For some straightforward issues, if the title already covers the "symptoms" and "possible causes," it is acceptable to omit redundant information.
19
20| Scenario                                                               | Purpose of Writing              | Corresponding Document Module| Writing Requirement|
21| ----------------------------------------------------------------------- | ---------------------------- | -------------- | ---------- |
22| 1. Locating: Users look up specific FAQs by identifying problem symptoms, akin to following a map.               | The documentation should be easily navigable and allow for quick matching with user issues.              | Symptom      | The descriptions should be detailed and precise.    |
23| 2. Analyzing: This step is optional. Users can compare their situation with the listed possible causes to analyze if they face a similar problem and to gain insights into how to address it.| The documentation should clearly explain the causes to prepare users for problem-solving.| Possible Causes      | The explanations should be logical and coherent.    |
24| 3. Resolving: Users follow the provided solutions to resolve issues independently, without needing external help.            | The documentation should guide users through the process of self-help problem resolution.        | Solution      | The instructions should be actionable and practical.    |
25
26FAQs generally fall into two main types:
27
28* [Troubleshooting](#troubleshooting)
29* [Consulting (including feature principles, specifications, concepts, and usage)](#consulting)
30
31
32## Troubleshooting
33
34**Title: A concise, one-sentence summary of the issue's outcome.**
35
36**Symptom**
37
38Describe the errors from the user's perspective that they can observe. This includes the context, manifestations, and conditions under which the problem occurs.
39
40(For complex issues, optional) If there's a full procedure for reproducing the issue, it should be detailed here as well.
41
42**Possible Causes (optional)**
43
44Clearly state the root cause of the issue. If various causes require different solutions, they should be distinctly itemized.
45
46**Solution**
47
48- Compose in a step-by-step format to ensure the steps are actionable.
49- Focus on "action-object" phrases for the steps, sometimes including the "purpose of the action" and the "outcomes of the current step".
50- Organize the logical flow (appropriate layering), use bullet points for parallel relationships, and numbered lists for sequential dependencies.
51
52**Code Examples**
53
54Showcase the essential code and offer runnable code snippets.
55If it is procedural code, it can be integrated with the solution steps.
56
57**Reference**
58
59Include links to guides, API references, and samples to facilitate further reading for developers.
60
61## Consulting
62
63**Title: Begin with the user's query, including specific feature keywords.**
64
65No need for separate subheadings, provide direct answers with implementation plans and relevant specification constraints. If code examples are used to clarify, simple snippets can be given right after the solution.
66
67**Reference**
68
69Include links to guides, API references, and samples to facilitate further reading for developers.
70