Documentation template and free outline generator

Describe your product or feature and pick the type of document. The generator drafts an outline you can fill in, or copy a template below.

Free, no account needed. Updated .

Documentation templates

Copy a template into your docs tool or editor, keep the headings that fit, and replace the parts in [brackets]. 13 templates in 5 groups.

User guides and manuals

  • User guide template

    # [Product name] user guide Last updated: [date] Applies to: [version, plan or app] ## What [product name] does [Two or three sentences: the problem it solves and who it is for.] ## Before you start - You need: [account type, permissions, device or browser] - Have ready: [files, details or codes the reader needs] ## Get started 1. [First action, such as signing in or opening the app.] 2. [Action that gets the reader to a first useful result.] 3. [Check: what the reader sees when this worked.] ## [Main task 1, written as a goal, such as "Invite your team"] 1. [Step.] 2. [Step.] Result: [what changes when the task is done]. ## [Main task 2] 1. [Step.] 2. [Step.] ## Settings | Setting | What it does | Default | |---|---|---| | [Name as shown on screen] | [Effect] | [Value] | ## Troubleshooting - **[Symptom the reader sees]:** [cause and fix]. - **[Symptom]:** [cause and fix]. ## Get help [Help center link], [support email or contact page], [hours, if you publish them].

  • User manual template (physical or installed product)

    # [Product name and model] user manual Model: [model number] Manual version: [version] Date: [date] ## Safety information [List the warnings that apply to this product. Put them before any setup step.] ## What is in the box - [Item and quantity] - [Item and quantity] ## Product overview [Diagram or photo with numbered parts.] 1. [Part name]: [what it does] 2. [Part name]: [what it does] ## Setup 1. [Unpack and place the product.] 2. [Connect power, cables or the app.] 3. [First start: what the reader sees.] ## Daily use ### [Task, such as "Start a cycle"] 1. [Step.] 2. [Step.] ## Care and maintenance - [Cleaning instruction and how often.] - [Parts to replace and when.] ## Troubleshooting | Problem | Possible cause | What to do | |---|---|---| | [Problem] | [Cause] | [Action] | ## Specifications [Size, weight, power, capacity, operating conditions.] ## Warranty and support [Warranty terms or link], [how to contact support], [where to find the serial number].

  • Quick start guide

    # Get started with [product name] in [number] steps This guide gets you from a new account to [first useful result]. For everything else, see the [full user guide link]. ## 1. [Create or sign in to your account] [One or two sentences and the button name to click.] ## 2. [Connect or import your first item] [What to choose, and what to leave at the default for now.] ## 3. [Do the first real task] [The action that shows the product working.] ## You are ready You can now [what the reader can do]. Next, try: - [Second task, with a link] - [Setting most teams change first, with a link] Stuck? [Contact link] or reply to [support email].

Help center articles

  • Help article (explains one topic)

    # [Question the customer asks, such as "How does billing work for added seats?"] [Answer in one or two sentences. A reader who stops here has what they need.] ## How it works [Two or three short paragraphs with the details. One idea per paragraph.] ## Example [A short worked example with real numbers from your own policy.] ## Limits and exceptions - [Plan, region or account type where this is different.] - [What this article does not cover, with a link to the article that does.] ## Related articles - [Article title and link] - [Article title and link] Still need help? [Contact link]

  • How-to article (one task)

    # How to [task, starting with a verb] You can [task] from [page or app area]. It takes about [time] and needs [role or permission]. ## Before you start - [Requirement, such as a plan, a permission or a file.] ## Steps 1. Go to **[Menu] > [Page]**. 2. Select **[Button name]**. 3. [Fill in or choose something.] If [condition], [alternative step]. 4. Select **[Save or Confirm]**. ## Result [What the reader sees when it worked, such as a message or a new item in a list.] ## Next steps - [Related task and link] ## If it did not work [Most common reason and fix, or a link to the troubleshooting article.]

  • Troubleshooting article

    # [Symptom in the customer's words, such as "I don't get the sign-in email"] ## What you see [Exact error message or behavior. Quote the message so search finds this page.] ## Try these fixes in order 1. **[Most likely cause]:** [fix in one or two steps]. Check: [how to tell it worked]. 2. **[Next likely cause]:** [fix]. 3. **[Less common cause]:** [fix]. ## Still not working? Contact [support link or email] and include: - [Detail support needs, such as the account email] - [Detail, such as the device and browser] - [A screenshot of the error, if there is one] ## Why this happens [Optional: one short paragraph for readers who want the reason.]

API and developer documentation

  • API reference page (one endpoint)

    # [Verb] [resource], such as "Create a contact" `[METHOD] [/v1/path/{id}]` [One sentence: what the endpoint does and when to use it.] ## Authentication [Header name and format, such as Authorization: Bearer [token]. Link to the authentication page.] ## Path parameters | Name | Type | Required | Description | |---|---|---|---| | [id] | [string] | Yes | [What it identifies] | ## Body parameters | Name | Type | Required | Description | |---|---|---|---| | [field] | [type] | [Yes or No] | [Meaning, allowed values, default] | ## Example request ```bash curl -X [METHOD] [base URL][path] \ -H "Authorization: Bearer [token]" \ -H "Content-Type: application/json" \ -d '[example body]' ``` ## Example response ```json [example response body] ``` ## Errors | Status | Code | Meaning | What to do | |---|---|---|---| | [400] | [code] | [Meaning] | [Fix] | ## Rate limits [Limit and what happens when it is reached, or a link to the rate limits page.]

  • API getting started and authentication page

    # [Product name] API The [product name] API lets you [main things a developer can do]. It uses [REST and JSON, or your style] over HTTPS. ## Base URL `[https://api.example.com/v1]` ## Get an API key 1. Go to **[Settings] > [API keys]**. 2. Select **[Create key]** and copy it. You can see it only once. 3. Store it as a secret on your server. Never put it in browser or app code. ## Authenticate a request Send the key in the [header name] header: ``` [Header name]: [format, such as Bearer YOUR_KEY] ``` ## Your first request [A short curl example that returns something real, such as the current account.] ## Versioning [How versions are named, how you announce changes, how long old versions keep working.] ## Pagination, errors and limits - Pagination: [cursor or page parameters]. - Errors: [error body shape and a link to the error list]. - Rate limits: [limits or link]. ## SDKs and help [SDK links], [changelog link], [where developers ask questions].

  • Webhook event reference

    # Webhook event: [event.name] Sent when [what happened, in one sentence]. ## When it is sent - [Trigger.] - Not sent when [case that surprises developers]. ## Payload ```json [example payload] ``` | Field | Type | Description | |---|---|---| | [field] | [type] | [Meaning] | ## Delivery and retries [How you sign requests, how to verify the signature, what counts as success, how retries work.] ## Example handler [A short code example that verifies the signature and reads one field.] ## Related events - [event.name]: [when it is sent instead]

Feature and release documentation

  • Release-ready feature doc

    # [Feature name] [One sentence: what the feature lets the reader do.] Available on: [plans] Who can use it: [roles] Released: [date] ## What it is for [The problem it solves, with one concrete example from a customer's day.] ## Turn it on 1. Go to **[Menu] > [Page]**. 2. [Switch, setting or permission.] ## Use it 1. [Step.] 2. [Step.] [Screenshot: what the reader should see.] ## Limits - [Size, count or plan limit, with the real number.] - [What it does not do yet, if customers will ask.] ## FAQ **[Question support expects]?** [Answer.] **[Question]?** [Answer.] ## Related [Links to settings, API or billing pages.]

  • Deprecation and migration guide

    # [Old feature or API version] is being retired **What changes:** [old thing] stops working on [date]. **What to use instead:** [new thing, with a link]. **Who is affected:** [accounts, plans or integrations]. If you do not use [old thing], you do not need to do anything. ## Timeline - [Date]: [announcement, new option available] - [Date]: [old option hidden for new accounts] - [Date]: [old option stops working] ## How to move to [new thing] 1. [Step.] 2. [Step.] 3. Check: [how to confirm the move worked]. ## What is different | [Old thing] | [New thing] | |---|---| | [Behavior] | [Behavior] | ## Questions [Contact link]. Tell us if the date does not work for you, and why.

Internal documentation

  • Internal runbook

    # Runbook: [task or alert name] Owner: [team or role] Last tested: [date] Review by: [date] ## Use this runbook when [Alert name, symptom or request that starts it.] ## Do not use it when [Cases that need a different runbook, with links.] ## Access you need - [System and permission] - [Tool and permission] ## Steps 1. [Check the current state.] Expected: [what normal looks like]. 2. [Action.] Expected: [result]. 3. [Action.] If [unexpected result], stop and go to Escalation. ## Roll back 1. [How to undo step 3.] 2. [How to undo step 2.] ## Escalation If [condition], contact [role] through [channel]. Include [details they need]. ## After you finish - Record [what was done] in [ticket or log]. - Tell [who needs to know].

  • Internal knowledge base article for support agents

    # [Situation agents handle, such as "Customer was charged twice"] Applies to: [products, plans or regions] Owner: [role] Updated: [date] ## How to recognize it [What the customer usually says, and what agents see in the account.] ## What to check 1. [Check in tool, with the page name.] 2. [Check.] ## What to do - If [condition]: [action, and the saved reply to use]. - If [condition]: [action]. - Never [action agents must not take, such as promising a date]. ## What to tell the customer [Approved wording or a link to the saved reply.] ## Escalate when [Condition], to [team] through [channel], with [details]. ## Customer-facing article [Link to the public help article, if one exists. If it does not, ask [owner] to write one.]

Short answer

A documentation template is a fixed set of headings for one kind of document, so every page answers the same questions in the same order. A user guide needs a getting started section, one section per task and a way to get help; an API reference page needs authentication, parameters, examples and errors. Copy one of the templates below, or let the generator outline a page from your own description.

How to use the documentation template generator

  1. Name the product or feature the way your customers name it, not the internal project name.
  2. Pick the type of document and the readers. A how-to article for customers and an API reference for developers need different sections, so the outline changes with both choices.
  3. Describe what it does and how it works in up to 3,000 characters. Paste rough notes, a spec or a support thread. The generator uses only these facts. Where it needs a detail you did not give, such as a plan name or a limit, it writes a placeholder in [brackets] instead of inventing one.
  4. Fill in the outline. Each heading comes with a line on what the section must say. Write those sections, then delete any heading that does not apply.

If you have used today's 5 free outlines, or you want the full structure at once, copy one of the templates above. They cover user guides and manuals, help center articles, API and developer pages, feature docs and internal runbooks.

Which documentation template to use

Documentation types and when to use them
DocumentUse it whenMust have
User guideCustomers learn a whole product or areaGetting started, one section per task, help
User manualThe product is physical or installedSafety, parts, setup, care, specifications
Help articleOne question needs an explanationThe answer in the first two sentences
How-to articleOne task with clear stepsNumbered steps, one action each, the result
Troubleshooting articleCustomers see an error or a symptomFixes in order, what to send support
API referenceDevelopers call one endpointParameters, examples, errors, limits
RunbookYour own team repeats a technical taskChecks after each step, roll back, escalation

What makes documentation easy to use

  • The answer first. Most readers arrive from search or a chatbot link with one question. Put the answer in the first sentence or two, then the details.
  • One topic per page. A page that explains billing, seats and invoices is hard to find and hard to link. Split it, and link the pages to each other.
  • Titles in the reader's words. "How to add a team member" is found more often than "Workspace membership management".
  • Steps that match the screen. Use the exact button and menu names, in bold, in the order the reader sees them.
  • Real numbers. Write the actual limit, price or time. "Up to [number] files" in a template is fine; in a published page it is a support ticket waiting to happen.
  • A date and an owner. Readers trust a page that says when it was last checked, and your team knows who to ask when it is wrong.

How to write a user guide

Start with a list of the tasks customers do in the product, in the order they do them. Each task becomes a section with a goal as its heading, numbered steps and the result. Before the tasks, add a short getting started section that gets the reader to a first useful result, because that is where most new customers get stuck. End with troubleshooting for the symptoms your support team hears most, and a clear way to get help.

A user manual for a physical product follows the same idea with a few extra parts: safety information before any setup step, a parts overview with a numbered diagram, care and maintenance, and the specifications.

API documentation template tips

Developers read API docs to copy something that works. Give every endpoint a request example they can paste, a real response, and a table of parameters with type, whether it is required and the default. List the errors the endpoint can return with what to do about each one. Keep a separate getting started page for keys, the base URL, versioning and a first request, and a webhook page for each event you send. Mark what changed and when in a changelog, so integrators can see if an update affects them.

Keep docs current after you publish

Documentation goes out of date when the product changes and nobody updates the page. Three habits help. Add a docs check to the release checklist, so a feature is not done until its page is. Review your most visited pages on a schedule. And read the questions customers ask support: each repeat question is a page that is missing, unclear or hard to find.

Docs that are current also answer more questions without a person. A customer support chatbot that answers only from your help pages is only as good as those pages, so clear, one-topic articles with real numbers help your customers twice: when they read the page, and when the chatbot answers from it.

Announce what changed with the release notes generator, turn a help page into questions and answers with the FAQ generator, and write internal procedures with the SOP generator.

Frequently asked questions

What should a documentation template include?

A title that names the task or topic, a short answer or summary first, what the reader needs before starting, the steps or details, limits and exceptions, and where to get help. Add a last-updated date so readers and your team can tell when it was checked.

What is the difference between a user guide and a user manual?

Most teams use the words for the same thing. When they differ, a user guide is task-based help for software, and a user manual covers a physical or installed product from end to end, including safety information, parts, care and specifications.

What goes on an API documentation page?

For each endpoint: the method and path, what it does, authentication, a table of parameters with types and defaults, a request example, a response example, the errors it can return and the rate limits. A separate getting started page covers keys, the base URL and a first request.

Does the outline generator write the whole document?

No. It writes the headings in reading order and notes what each section must say, with example wording where your description gives the facts. Where it does not know a detail, such as a limit or a setting name, it leaves a placeholder in square brackets for you.

Is the documentation template generator free?

Yes. You get 5 free AI runs a day without an account, shared by all our AI tools. What you type is sent to our AI model to write the outline and is not stored. The templates on this page are free to copy with no limit.

Newsletter

Support notes, once a month.

One email with what we learn about help centers, honest AI answers and support teams. Unsubscribe at any time.

We use your email only for this newsletter. See the Privacy Policy.