Build help docs from taxonomy to published article

01 Anchor on the tickets, not on the feature list.

Before you write a taxonomy, define what this work has to change. The deliverable is not "a complete help center." It is a measurable drop in tickets and a measurable rise in self-serve resolution on the topics that cost the most. Pull three months of support tickets. Cluster them by theme. The top five to ten themes are your P0 articles. Everything else waits. Diagnose before executing, refuse the playbook ask

Support is also the place to start because the path to value there is the shortest and the feedback loop is the tightest. The corpus is already structured as problem and resolution, and even partial deflection is material when volume is high.

"For businesses thinking about where to start with AI, we recommend support. The results are predictable and the path to value is the fastest."

Internal Customer Agent at HubSpot resolves ~60% of internal support inquiries without human intervention.

· Yamini Rangan, HubSpot blog, 2026-04-28 · “Start your AI-in-GTM build…”

State the target at the top of the project: which ticket themes this set of docs must deflect, and by how much. Check the finished work against that target, not against page count.

02 Build a product-knowledge file every claim traces back to.

Crawl the existing docs. Read the two- and three-star reviews. Sign up and use the product yourself. The output is one verified product-knowledge file: every feature, every UI label exactly as it appears on screen, every plan tier, every capability described in plain terms.

This file is the single source of truth. Every claim in every article traces back to it. A wrong claim does not just confuse a customer. It creates the exact ticket the doc was supposed to prevent. Ogilvy's frame separates the two ways teams write: from what the buyer actually does, or from the team's own taste and assumptions.

"I prefer the discipline of knowledge to the anarchy of ignorance."

· David Ogilvy, Ogilvy on Advertising, 1983 · “I prefer the discipline…”

A help doc grounded in verified product knowledge is the discipline. A help doc written from memory is the anarchy. Keep a human checking each claim against the source file before it ships, the same way you would verify any AI-generated draft against the underlying truth. Verification, not execution, is the irreplaceable human job

03 Define the reader as the marginal user in the worst conditions.

The wrong reader to design for is the power user who already knows the product. The right reader is the person on the cusp: high intent, low success, reading your doc on a phone, mid-task, slightly frustrated, with no patience for jargon. Fix that person's path and you fix everyone's, because the friction that blocks them also taxes everyone else, more lightly. Design for the marginal user, the person on the cusp of converting in the worst conditions

"When you fix marginal user problems, you fix everyone downstream. Focus on making that person's experience stupid easy."

· Adriel Frederick, Lenny's Podcast, 2026-04-28 · “Design for the marginal…”

Run the comprehension test on every category and section name. Could someone with no product vocabulary read the label and know what is behind it? This is Miller's caveman test applied to navigation, not to a homepage.

"Could a caveman look at your website and immediately know what you offer, how it will make their life better, and what they need to do to buy it?"

· Donald Miller, Building a StoryBrand, 2017 · “Could a caveman understand…”

If a section name fails the test, rename it before you write a word of the article.

04 Audit what exists. Score it. Prioritize by ticket volume and views.

Inventory every existing article by type: how-to, conceptual, troubleshooting, reference. Score each on four axes: product accuracy, customer-centricity, structure, completeness. Then rank rewrites by ticket volume plus page views, not by which article is easiest to fix.

Cut before you add. Subtraction is more reliable than improvement in a tangled help center. An out-of-date article that confidently states the wrong thing is worse than no article. Delete it. Subtraction-first operating discipline

The output is a P0 / P1 / P2 list with a reason attached to each entry. "Reset Password gets 4,000 views a month and is wrong about the email step" is a P0 with a reason. "Reset Password needs work" is not.

05 Map the customer experience to content, sequenced by the first week.

Order the content the way a real customer hits the product, not the way the org chart is drawn. The arc is setup, then core concept, then core action, then power feature, then edge case. This is the post-sale half of the experience map: the path defined by the customer's success milestones, not your release schedule. Map the journey by customer success milestones, not pipeline stages

For every feature, answer five questions in this order:

The "undo" and "after" questions are the two teams skip. They are also where the next ticket comes from.

06 Design a task-first taxonomy. Three levels, five to seven top-level categories.

Use a hybrid model: task-oriented top-level categories with feature-named articles inside them. "Set up your phone system" is a category. "Call forwarding settings" is an article within it. Three levels maximum: Category, then Section, then Article. Cap the top level at five to seven items, because each extra navigation level cuts findability.

No acronyms, no product jargon at the category level. The category names are the first thing the marginal user reads, and a confused reader leaves before the article ever loads.

07 Design the getting-started experience as its own category, listed first.

Onboarding is the bridge between buying and getting value. If the customer does not reach first value fast, no amount of reference documentation rescues the relationship. In PLG, no pricing model can save you if onboarding doesn't reach the Eureka moment quickly

Give getting-started its own top-level category, listed first. Inside it: role-based quick-starts (admin setup, end-user onboarding), a short conceptual overview, and five-minute quick wins that deliver one undeniable result. Sequence the narrative as Motivate, Setup, First Value, Power Use. The job of the getting-started path is to get the customer to the first moment where the product visibly works.

Watch out for the trap of measuring the wrong thing here. A customer logging in is not a customer getting value. Adoption metrics flatter you. Value delivery is the real signal, and the two are not the same: a tool can deliver value even when nobody logs in, as long as it lands where the work already happens. Tool adoption should not be conflated with value delivery.

08 Write each article from a template. Outcome first, product never first.

Every article opens with the customer outcome, not a feature description. No sentence starts with the product name. The buyer is the agent of every instruction: "you" do the thing, the product is the tool. Instructions beat descriptions every time.

The headline carries the article. A title a reader has to interpret is a title that fails, because a person mid-task in a help center allocates zero interpretive effort. Plain wins. Sell to the buyer's mindset, not to product features

"Clarity beats cleverness, always. A headline that requires interpretation is a headline that fails."

· Eddie Shleyner, VeryGoodCopy, 2024 · “Clarity beats cleverness, always,…”

Write to one specific person, the way Ogilvy framed every piece of copy: as if you were talking to someone whose intelligence you respect, not to an abstract user segment.

"The consumer isn't a moron; she is your wife. You insult her intelligence if you assume that a mere slogan and a few vapid adjectives will persuade her to buy anything."

· David Ogilvy, Confessions of an Advertising Man, 1963 · “The consumer isn't a…”

When the doc has emotional weight (billing, data loss, a failed setup), name the problem at more than the surface layer. The external problem is "the call dropped." The internal problem is the customer feels the product is unreliable. A doc that acknowledges both reads as written by someone who understands the situation. Articulate the buyer's problem at three layers, external, internal, and philosophical, or your message rings shallow

Each template carries: a title, a one-line outcome, a prerequisite block in the first two lines, the body, and a related-articles block.

09 Apply progressive disclosure. Answer first, complexity behind a deliberate click.

Lead with the one-line answer or TL;DR. Step-by-step instructions come second. Edge cases, admin-only options, and exceptions go into expandable sections the reader opens only if they need them. The marginal user gets unblocked in the first screen. The power user expands for depth. Neither pays for the other's needs.

Conciseness is not a style choice here. It is respect for a reader who is stuck and counting seconds.

"Conciseness is respect. Every unnecessary word signals that you value your message more than the reader's time."

· Eddie Shleyner, VeryGoodCopy, 2024 · “Conciseness is respect, every…”

Format for the eye before the mind. Short paragraphs, generous breaks between steps, no walls of text. Dense unbroken text reads as effort and gets abandoned before the substance lands.

"treating white space as oxygen in her formatting"

· Ann Handley, Total Annarchy, 2024 · “White space is oxygen,…”

10 Handle multiple platforms with parity, not duplication.

When the desktop and mobile workflows diverge substantially, write separate parallel articles with identical structure. When only one or two steps differ, use inline tabs or callouts inside a single article. Keep the verbs honest: "click" on desktop, "tap" on mobile. A customer who follows a desktop instruction on a phone and hits a wall files a ticket. Parity prevents it.

11 Plan cross-links before you write, so no article dead-ends.

Map inbound and outbound links per article before writing the body. Every article carries breadcrumbs, at least one inline link inside the body, a curated related-articles block of three to five hand-picked links, and a next-steps prompt for any sequenced setup. Concept-and-action pairs always link to each other: the "what is an IVR" concept links to the "set up your phone menu" task, and back.

Do not auto-generate the related block. An algorithm picks adjacent, not relevant. Curate it. Every article needs at least three exit paths so the reader is never stranded.

12 Make the docs legible to agents, not just humans.

A growing share of your help-center traffic is not a human reading. It is an AI agent fetching the page on a customer's behalf, in one or two requests, deciding whether your doc answers the question. A page written only for human eyes fails the agent on several axes at once. Addy Osmani's six-layer model names the concrete moves: access control, discovery via llms.txt, explicit capability statements, answer-first formatting inside a short TL;DR, token discipline so a long page does not blow the agent's context window, and a copy-as-markdown handoff for humans working with agents. Agent-first content has six platform layers, access, discovery, capability, format, token, UX bridge

Treat this as a docs and help-center concern specifically, the place the source names as in-scope, not a brand-page concern. The answer-first TL;DR you already wrote in step 9 is the single most useful layer: it serves the stuck human and the fetching agent with the same first 200 tokens.

13 Add search tags and synonyms so technical and plain-language searchers both land.

A customer types what they call the thing, which is rarely what you named the article. Tag "Set up your phone menu" with "IVR" so a technical user searching the acronym finds the plain-language article. Build a tag and synonym inventory per article. Track zero-result searches: every query that returns nothing is a missing article or a missing synonym, and it is the cheapest signal you have of a gap.

14 Run the quality gate before publishing.

Review every article against the bar: product accuracy traced to the knowledge file, customer-centric intro, clean structure, tight copy. The strongest single check is the frontline one. Reps and support agents hear the real language of confusion before any dashboard reflects it, so route drafts past the people who answer the tickets. Frontline customer contact is the PMM substrate

The deepest version of this discipline is cultural. At Zappos, every new hire spent four weeks on the support phones before starting their actual role, which made the customer's voice the first language they learned.

Every new hire — including the CFO and engineers — completes four weeks on the customer-loyalty phones before starting their actual role.

· Tony Hsieh, Delivering Happiness, 2010

Every new hire, including the CFO, does four weeks on the customer phones

You do not need a four-week rotation to borrow the principle: the people closest to the tickets should review the docs that are meant to deflect them.

15 Measure, then iterate on a loop, not a one-time launch.

Track article views, zero-result searches, ticket-deflection rate per topic, and time on page. A help center is never finished. New tickets create the need for new knowledge; existing articles drift as the product changes. Run two loops: a solve loop that captures new answers from incoming tickets, and an evolve loop that refines articles that are getting views but not deflecting tickets.

Quality here is a growth lever, not a cost. Docs that actually work reduce support load, lift activation, and turn the post-sale experience into something customers talk about. The product, including its docs, is the marketing. Quality and friction-as-feature are growth levers, not constraints

"Godin argues that in a world of infinite choice and zero attention, the product IS the marketing."

· Seth Godin, Purple Cow, 2003 · “In a world of…”