Learn how to name a page and about the differences between introductions, overviews, getting started articles, and so on.
Courses and tutorial headings can differ from product documentation headings. Here are examples of introductory and conceptual headings that can are mistakenly used interchangeably:
|Type of Title||Examples||Meaning|
||Introductions present a new product and generally describe what it does at a high level. Your guide should include only one introduction, placed at the beginning of the guide where new customers see it. (Not to be confused with overview.)|
||Overviews describe several or specific features, how they work together, and what you can do with them.
Important: Do not name a page Overview without naming what the overview is about. Overviews are not home pages. Also, if you need to describe the purpose of a guide on the landing, use an About this guide heading and describe it there.
|Fundamentals of…||Fundamentals of Campaign v8||Similar to Overview of Adobe Target but usually more ground-level and hands-on.|
|Get started with …||Get started using customer attributes||Walks through the initial steps to perform when using a feature. Customers expect to be using the interface in a getting started article or lesson.|
|Integrations||Adobe Campaign integration with Adobe Experience Manager.||Guidance: Use the product name followed by integration. (Capitalization guidelines apply)
Use Adobe in front of the product name on first use.You don’t need to keep repeating Adobe in secondary uses.
If you’re describing an integration (as opposed to referring to the formal name of the integration), you could be more forgiving with the terms. For example, “This section describes how Campaign integrates with Experience Manager.”
|Recommendations (automatic)||More help on this feature||This heading is automatically added at the bottom of a page (assuming that the Recommendations feature is enabled by SCCM). A bullet list of recommended articles is also added.
Ensure that your H1 headings adhere to capitalization standards, and that you have feature tagging correctly set up for this feature to work.
|Match your TOC and breadcrumb entries||To the best extent possible, your TOC entry, breadcrumb, and page heading (#) should be the same. When space doesn’t allow for this, remove unneeded words in the TOC entry.|
|Avoid double headings||Avoid following a heading with another heading. At least one line of text must separate headings.|
|Use sentence-style capitalization for all headings||Per Adobe’s standards, headings should use sentence style capitalization.
Example: Target fundamentals for business users
Adobe style uses sentence-style capitalization for all titles, headings, subheadings, and page navigation elements. (All words are lowercase except the first word and proper nouns, such as the names of brands, solutions, and services.) Match the capitalization in the product names of tools, options, menu items, dialog boxes, and fields.
|Keep headings short||A heading isn’t a sentence. Keep page titles short with important keywords at the beginning.
Example: Upload customer attributes
|Use nouns or short noun phrases for conceptual overview headings (and TOC entries)||Audiences
Experience Cloud integrations
|Use keywords||Keywords are feature names and accurate task names (verbs).
Example: Upload customer attribute data to Experience Cloud
This example contains all the keywords to accurately name a task and improve search results.
Create meaningful headings in an active, natural language.
|Use infinitive verbs for task headings and avoid gerunds (-ing verbs)||Run a Fallout report|
|Use the singular form for task headings||Save a workspace (not Save workspaces)|
|Use sentence style capitalization for all headings||Create an audience|
|Use parallel structures||A table of contents (TOC) or list should begin with the same verb or noun phrase. (see Structure and syntax for headings)|
Information design typically follows an overview > concept > task hierarchy. In highly structured authoring environments (like DITA), these content types are defined as separate pages or files, which are merged at help-build time. In Markdown authoring, however, you can put these content types natively on the page.
Tutorial headings for landing pages (including the link text for the
overview.md file in your
TOC.md) should use the product name followed by tutorials. Examples:
In some situations, your heading can begin with Tutorials if confusion is otherwise created.
See Content types for a discussion about organizing content on the page.