When writing or editing Help Center articles, use the following standards as guidelines.

The standards are organized in three groups:

Keep articles short and focused. A reader landing on an article should be able to solve a specific problem or understand a specific concept without scrolling through unrelated content. When an article starts to cover multiple problems, break it down into smaller articles linked from a parent or workflow article.

Short, focused articles are also easier to maintain — when the product changes, the radius of update is smaller.

Three design principles to keep in mind:

Three patterns to choose from. Pick the one that matches the article's actual job; don't force cookbook structure onto an orientation or reference article.

Cookbook — Scenario / Solution / Go deeper / See also. For task-oriented articles where a reader has a specific problem to solve. Most "how to" articles fit this. Examples: "How to schedule an event," "Integration for Slack," "How to create and edit an article."

PlusPlus 101 hub — Why X / How it works / Choose / Set up / Operate / See also. For orientation articles that introduce a feature area and route readers to multiple sub-articles. Use when the article's job is navigation, not procedure. The "PlusPlus 101:" prefix is not required for the pattern to apply — what matters is the navigational job. Examples: "PlusPlus 101: SSO Integration," "PlusPlus 101: Getting started with notifications."

Reference / explanation — custom structure (for example, trigger / lifecycle / retention / configuration). For documentation that explains how a system behaves rather than walking through steps. Use when the content is about what happens, not what to do. Examples: deprovisioning lifecycle, scheduled-track Slack channel behavior, user-role definitions.

Articles within a feature family use Feature: Subtopic format. This keeps related articles findable in search and signals family membership at a glance.

Examples:

Use sentence case for titles (see Formatting, grammar, and word choice below for the general sentence-case rule).

Always include a description under the title. Aim for up to 220 characters. Descriptions appear in Intercom search-result snippets and on article cards, so they should read as concrete, one-sentence summaries of what the article does and who it's for — not as essay intros or marketing copy.

Good descriptions are scannable and lead with the action or behavior.

Examples:

URL slugs are sticky once published. Treat the article title as the place to apply naming convention; don't break URLs to chase consistency. Inbound links from in-product help, sales collateral, customer bookmarks, and search results all break if a slug changes.

Title and slug can diverge. The title should follow current convention; the slug stays whatever it was originally.

When publishing a renamed article in Intercom, change the title but leave the URL slug untouched.

Direct and precise, RFP-ready by default. Speak as though you are addressing a respected colleague — not talking down to the reader, but also not padding with pleasantries or marketing copy.

Avoid:

A description like "Connect PlusPlus to your Slack workspace to deliver notifications as direct messages" works for RFP grading. "Unlock powerful Slack notifications for your team!" does not.

The See Also section is a curated short list, not a generic dump. Three to five links is typical. Focus on:

Do not duplicate links already inline in the article body. Do not include every tangentially-related article.

Example for Integration for Slack:

Generally, our voice and style should not talk down to users, but should feel as though we are speaking to a respected colleague.

Put names of fields, buttons, and so on, in bold text.

Don't refer to UI elements if possible (like button, field, and so on).

Don't capitalize items in the UI unless referring to actual fields, buttons, and so on.

Use second person when referring to the reader.

Use present tense verbs, avoiding "will" or "would then."

Avoid pleasantries (if desired, please, simply, and so on).

Don't use Latin abbreviations.

Use sentence case for article titles and headings and title case for UI fields and buttons.

| YES| NO
---|---|---
​Article titles| Help Center writing standards| Help Center Writing Standards
​Article headings| Go deeper| Go Deeper
​UI elements| Select Add Event from the menu. | Select ADD EVENT from the menu.

*even though it is in all caps in the UI

Avoid referring to the "system" or "application" when talking about the instance of PlusPlus the reader is using. If it can't be helped, use "system."

You select from a list of options and click on a button that takes action.

Click Bulk Import.

Buttons are clickable, and icons are not, so don't tell users to click an icon. When buttons are images (like a context menu), describe what the button looks like in parentheses.

Reserve bulleted and numbered lists for genuinely list-like content: settings, status definitions, comparisons, parallel options. Use prose for explanation; lists shouldn't replace paragraphs that flow naturally.

If the content reads as a sentence with a series ("the integration supports SAML, OIDC, and SCIM"), keep it as prose. If it reads as discrete items the reader will scan for one at a time, use a list.

For reference material in a Go deeper section, tables are often clearer than bullets — particularly for comparisons, parameter definitions, or status enumerations.

Be as sparing as possible with images since they are difficult to maintain long-term. Use screenshots only when they are needed to clarify the instructions given.

When possible, place images above the text that references it.
This helps convey a logical flow from step to step where an image shows the result of an action taken. For example, if you direct readers to click a button to open a new page, an image of that page should appear after the "click button" step and before the instructions of what to do on that page.

| YES
---|---

| NO

Apply a drop shadow to all screenshots so they stand out from the surrounding text. Recommended settings: opacity 25%, offset 0pt, blur 20pt. [NEEDS VERIFICATION: confirm these settings are still current convention before publishing — copied from the prior Help Center Best Practices article and may be stale.]

Think carefully about what to include in the screenshot frame. Show too much and the image dates faster as the UI changes; show too little and the context becomes unclear. Crop to what the reader actually needs to see.

For multi-step workflows where the result of each step matters, an animated GIF can be more effective than a sequence of stills.

List procedure steps as numbers, not bullet points. If you need to note the result of a step, put it after a line break within the step rather than delineating it as another step. Steps are actions the user takes, not the result of the action.

|

|

Combine two steps when the second logically completes the first and it reasonably reduces the number of steps in the process.

Always include the concluding step of a process, such as: Save your changes.

2. Select Edit for the event.3. Edit the Title for the event.4. Save the event.

Bulleted lists should be parallel.

| YES
---|---

| NO

Five steps to follow before drafting a replacement for an existing article:

Always verify the exact settings path before stating it. Old articles have been wrong about the path multiple times, often using Settings > where the actual path is System Settings >.

Common things to verify before publishing:

When something can't be confirmed from the article being audited, project knowledge, or other source material, mark it inline with [NEEDS VERIFICATION] rather than guessing. Better to ship with an explicit flag than to encode incorrect behavior. Resolve all [NEEDS VERIFICATION] flags before publishing.

For procedural and reference articles, validate the article's claims against source code when accessible. Claude Code against the PlusPlus repo is the path.

Treat source validation as:

Run source validation after the draft is otherwise ship-ready, then iterate on findings.

Deprecation is one of three valid outcomes of an article audit (the others being rewrite-in-place and new-article). Choose deprecation when:

When recommending an article for deprecation, the audit produces three things:

In Intercom, deprecate by setting the article to unpublished and configuring a redirect from the old slug to the redirect target.