Team Knowledge
How to structure a help center — a practical guide for teams building customer-facing or employee-facing help centers that people can navigate independently, find what they need, and use without contacting support.
A help center fails when users can't find what they need. They click around, search, don't find it, and contact support — which is the opposite of the help center's purpose. The help center's structure — how content is organized, named, and navigated — determines whether users find answers or default to asking.
The difference between a help center that deflects support contacts and one that generates them is almost always structure, not content. Teams that build help centers often have accurate, complete content. Users still can't find it because it's organized around how the team thinks about the product, not how users think about their problems.
A help center structured for user navigation:
An effective help center has three navigational layers that work together:
Layer 1 — The home page: The starting point for users who don't know exactly what they're looking for. Organized by the most common user tasks or questions, with prominent search. Not comprehensive — curated to the 6-10 most important entry points.
Layer 2 — Category pages: Groups of related articles organized by theme (Getting Started, Account Settings, Billing, Troubleshooting, etc.). Users who arrive at a category page are looking for information within a known area.
Layer 3 — Individual articles: The specific answer to a specific question. Written to be found by search, to answer the question in the first paragraph, and to stand alone without requiring context from other articles.
Each layer serves a different navigation mode: browsing (layer 1), narrowing (layer 2), and finding (layer 3). The structure should support all three.
The most common help center home page mistake: listing all categories with equal prominence. This produces a page with 20 categories and no guidance about where to start.
The effective home page:
Featured content: The 3-5 articles that are viewed most often, or that cover the questions new users always ask. These go at the top, before any navigation structure.
Task-based navigation: 6-8 sections organized by what users are trying to do, not by product feature. "Getting started," "Managing your account," "Billing and payments," "Troubleshooting" are task-oriented. "Product features," "Platform overview," "Core functionality" are product-oriented and less findable.
Search bar, prominently placed: Most users who arrive at a help center with a specific question will use search. The search bar should be the most visually prominent element on the home page.
Contact support link: Visible but not prominent. The help center exists to answer questions before they reach support; the support link is the fallback, not the primary path.
The most consequential structural decision in a help center: how to name the categories.
Product vocabulary: "Core Features," "Advanced Configuration," "Integration Layer," "Administrative Console." This is how the product team thinks about the product.
User vocabulary: "Getting started," "Setting up your account," "Connecting to other tools," "Managing users and permissions." This is how users describe what they're trying to do.
User vocabulary wins almost every time. Users searching "how do I add a team member?" will find the answer in a category called "Managing users and permissions" more easily than in "Administrative Console."
The vocabulary audit:
Review the most common support tickets and help center searches for your product. What language do users use to describe their problems and goals? Those words should be in your category names and article titles.
"Our users always search 'delete account' but our article is titled 'Account Termination'" — this gap is a structure problem, not a content problem. The content is there; the vocabulary doesn't match.
Each help center article should follow a consistent structure that serves both searchers (people who arrive from search engines or internal search) and navigators (people who browse to the article).
The title is the question: "How do I add a payment method?" is better than "Payment Methods." The question title matches what users search for and tells the reader immediately whether this article answers their question.
The first paragraph answers the question: The answer to the primary question in the title belongs in the first 2-3 sentences. Users who are scanning determine relevance immediately; users who read the whole article read the first paragraph first.
Steps are numbered and short: For procedural content, numbered steps with one action per step. "Click Settings in the left sidebar, then click Billing, then click Add Payment Method" is three steps, not one.
Screenshots support but don't replace: Screenshots of the relevant UI steps are useful. They should show exactly what the user will see, and they should be updated when the UI changes. Outdated screenshots are worse than no screenshots — they create confusion when the user's screen looks different.
Related articles link: At the bottom of each article, 2-4 links to related articles. Not a comprehensive list of everything in the category — the 2-4 articles most likely to be the next step or to answer the follow-up question.
Every help center needs a "Getting Started" section explicitly designed for new users. This section has different objectives from the rest of the help center: it's not for users who have a specific question, it's for users who don't yet know what questions to ask.
Getting Started content:
What is [product] and what can it do? — A brief, non-salesy description of the product's purpose, written for someone who has just signed up and needs to understand what they're working with.
First steps — The 3-5 things every new user needs to do, in order. Not comprehensive; the essential sequence to get from "just signed up" to "basic working state."
Key concepts — The 3-5 concepts that the product uses that aren't self-evident. If the product has specific terminology or a data model that users need to understand to use it effectively, explain them here.
Quick start guides — Role-specific or goal-specific quick starts for the most common user types or use cases. "Quick start for project managers," "Quick start for developers," "Getting started with [specific feature]."
The Getting Started section is often the most read section of a help center and the least maintained. It should be reviewed quarterly and updated whenever the product's onboarding flow changes.
Most help center searches are from users encountering a problem. A strong troubleshooting section is the highest-value section in a help center measured by support deflection.
Troubleshooting article structure:
The error message as content:
Search engines and help center search index the text in articles. If a user searches for the exact error message they're seeing, the troubleshooting article should contain that exact text. Paraphrasing error messages reduces findability.
The "symptoms first" organization:
In troubleshooting sections, users know what's wrong (the symptom) but don't know why (the cause). Organizing troubleshooting articles by symptom rather than by cause matches how users navigate: "my export isn't working" rather than "export format conversion errors."
A help center's search function is often the primary navigation method. Articles that don't appear in search results for relevant queries don't get read.
What users search for:
Users search for the task they're trying to do ("how to add a user"), the error they're seeing ("payment method not accepted"), or the feature they're trying to use ("export to CSV"). Article titles should match these search patterns.
Synonyms and alternatives:
An article about "canceling your subscription" should also be findable if a user searches "how to unsubscribe," "how to stop my plan," or "delete my account." The article should contain these alternative phrasings, either in the title, in the first paragraph, or in an explicit synonyms section.
Short titles for search:
Long, specific titles are useful for browsing; short titles are more scannable in search results. Where possible, match the primary search query length: "Add a team member" rather than "How to add a new team member to your organization's account."
Support ticket deflection rate:
The percentage of users who visit the help center and do not subsequently submit a support ticket. This is the primary measure of help center effectiveness. Improving deflection rate is the help center team's primary goal.
Self-service rate by topic:
For each category of support ticket, what percentage of users find the answer in the help center vs. contact support? Topics with low self-service rates have either missing or hard-to-find documentation.
Search success rate:
Of users who search the help center, what percentage of searches lead to a page view? A low search success rate indicates either poor search functionality or content gaps.
Article feedback:
"Was this article helpful?" with thumbs up/down, optionally followed by a comment prompt. Articles with low helpfulness ratings are candidates for rewriting or replacement.
Setup: A project management SaaS company has a help center with 180 articles organized by product module (Tasks, Projects, Reports, Integrations, Settings, Billing). Support tickets have increased 40% over six months. The head of support reviews support ticket topics: 60% of tickets are for questions covered in the help center.
The problem: Users can't find the answers that exist. The product-module organization doesn't match how users think about their problems.
What they do:
They restructure the home page around user tasks:
They rename 40 articles to match search patterns (most common change: adding "how to" to article titles, e.g., "Bulk delete tasks" → "How to delete multiple tasks at once").
They add the 15 most common error messages to the troubleshooting section.
Results:
Three months after restructure: support ticket volume drops 22% despite no product changes and no reduction in new user volume. Search success rate increases from 62% to 78%. The 60% of tickets that were for documented topics drops to 35%.
A help center that deflects support contacts rather than generating them is structured around how users think about their problems — in user vocabulary, by task or symptom, with the most common content most prominent. The structure is more important than the content volume: a help center with 50 well-organized articles that users can find reduces support contacts more than a help center with 500 articles that users can't navigate. The measurement that matters — support ticket deflection rate — directly tracks whether the structure is working, and the combination of search analytics and support ticket analysis tells you exactly where to improve.
More WebSnips articles that pair well with this topic.
How to run a documentation audit — a practical guide for teams who want to systematically assess what documentation exists, what's accurate, what's missing, and what should be removed, producing a clear action plan for a knowledge base that's trustworthy and complete.
How to break down knowledge silos — a practical guide for teams and organizations where critical knowledge is trapped in specific people, teams, or systems, creating organizational brittleness, slowing decisions, and widening capability gaps between teams.
How to build a company handbook — a practical guide for founders, operations leaders, and HR teams who want a handbook that communicates what the company values, how it works, and what employees can expect, without producing a bureaucratic document no one reads.
How to build a company knowledge base — a practical guide for teams and organizations who want to capture institutional knowledge, reduce repeated answering, and make organizational context accessible to every employee regardless of when they joined.
How to build a decision log — a practical guide for teams and organizations who want a permanent, searchable record of significant decisions that makes the reasoning behind current practices visible and prevents repeated debating of already-resolved questions.
How to capture knowledge from departing employees — a practical guide for managers and HR teams who want to systematically extract institutional knowledge before it leaves with an employee, rather than discovering the gaps after they're gone.