A help centre for your software product: structure and tools

Short answer: Organise your help centre around the jobs customers are trying to do, not around your app's menus, and write a small set of distinct article types: getting started, task how-tos, troubleshooting and reference. Link to the right article from inside the app at the moment people need it. For most small products, the knowledge base built into your helpdesk is the right first tool; a separate docs site makes sense when you have developer documentation or many versions to maintain.

A help centre usually starts as a few Google Docs, a scattering of support emails answered the same way and a founder who knows everything. It's worth fixing early: every question answered well in writing is one fewer email, and a clear help centre makes the product feel more mature than it is.

What good help content does

Nielsen Norman Group's tenth usability heuristic sums it up: help and documentation should be easy to search, focused on the user's task, list concrete steps and not be too large. NN/g's article on the heuristic distinguishes two kinds of help:

Proactive help, offered before a problem arises: onboarding tutorials, contextual tips, templates and wizards.
Reactive help, which users seek out when they're stuck: documentation, videos and tutorials.

Your help centre is mainly reactive help, but it should connect to the proactive kind inside the product.

The structure blueprint

Article types

The Diátaxis documentation framework identifies four distinct needs and four matching forms of documentation: tutorials, how-to guides, technical reference and explanation, and suggests organising documentation around those needs. For a small software product, that translates into:

Getting started (tutorials). One path from sign-up to the first real result. Step by step, with screenshots.
How-to guides. One task per article: "Add a team member", "Connect your calendar", "Export your data". Title it with the task, in the words customers use.
Troubleshooting. Symptom-first: "Emails aren't sending", "I can't log in", "My import failed". List causes from most to least likely.
Reference. Settings explained, plan limits, keyboard shortcuts, integrations, API basics.
Explanations (optional at first). How billing works, how permissions work, why something behaves the way it does.

Keeping these separate stops articles turning into long essays that mix tutorial, reference and troubleshooting.

Categories and sections

Most help centre tools use two or three levels. In Zendesk, for example, categories are top-level containers and sections hold related articles, with sections able to contain subsections. A simple layout for a small product:

Getting started: account setup, first project, inviting your team.
Using [main feature]: one section per major area of the product.
Integrations: one article per integration.
Account and billing: plans, invoices, changing payment details, cancelling.
Troubleshooting: the top ten problems from your support inbox.
Security and data: how data is stored and exported, two-factor authentication.

Start with what your support inbox actually contains. Twenty strong articles that answer real questions beat a hundred thin ones.

Writing each article

Title as a task or a question.
One-sentence summary of what the article covers.
Numbered steps, one action each, with the exact button names.
Screenshots only where they help, cropped tight, and updated when the interface changes.
"Related articles" at the end, pointing to the next likely task.
A date or version note where behaviour changes over time.

Search

People search more than they browse. Check your tool's search logs monthly: searches with no results are a list of articles to write, or synonyms to add to existing titles.

Linking from the app

This is where help centres earn their keep:

A help link or "?" icon on complex screens that opens the relevant article, not the help centre homepage.
Error messages that link to the troubleshooting article for that error.
Empty states ("You haven't connected a calendar yet") that link to the how-to.
The same article links used by your support team in replies, so customers learn where answers live.

The tool decision

Option 1: The knowledge base built into your helpdesk

Most helpdesk tools include a knowledge base. Good for small teams because articles sit next to tickets: agents can insert links in replies, and many tools can suggest articles before a customer submits a request.

Choose this if: you already use or plan to use a helpdesk, your docs are mainly for end users, and non-developers will write them.

Option 2: A documentation site

A separate docs site, often built from Markdown files in a code repository, or a hosted documentation platform.

Choose this if: you have API or developer documentation, need versioned docs for different releases, or want docs reviewed and published alongside code changes.

Option 3: Pages on your own website

A section of your marketing site. Fine for a handful of FAQs, but it gets hard to search and maintain as the product grows.

Questions to ask any tool

Can it run on your own subdomain, such as help.yourproduct.com?
How good is search, and can you see what people searched for?
Can you control who sees what (public, logged-in customers, internal only)?
Does it support multiple languages if you need them?
Can you export everything if you switch tools later?
Can you link to articles reliably from inside your app?

Keeping it current

The fastest way a help centre loses trust is screenshots and steps that no longer match the product. Build updates into your release routine: when a feature changes, the person shipping it lists the affected articles. Review the twenty most viewed articles every quarter.

FAQ

How many articles do I need before launching a help centre?

Enough to cover getting started and the questions you answer most often. Your support inbox from the last few months is the best guide to that list.

Should the help centre be public?

Usually yes. Public articles help prospects evaluate the product and can be found through search. Keep internal procedures in a separate, private section.

Who should write the articles?

Whoever answers support is often best placed, because they know the real questions. A founder or product person should review for accuracy.

Video or text?

Text first, because it's searchable and quick to update. Add short videos for multi-step setup tasks.

If your support inbox keeps answering the same questions, we can help you plan and build a help centre that links into your app.