Planning Audience Targeting for Documentation Projects

Deciding Whether Your Project Needs Audiences

Use audiences in Atloria when one documentation project needs to serve more than one reader group, but you still want to keep the content together in a shared project workspace. An audience represents a reader segment, such as customers, partners, internal support teams, or project administrators. Instead of creating duplicate pages for each group, you can plan one project with shared pages and audience-specific sections where needed.

Audiences add the most value when the project has a strong shared foundation but some instructions, permissions, or workflows differ by reader type. For example, a project may include the same onboarding pages for everyone, while certain setup steps should appear only for administrators or internal teams. In that case, audience targeting helps you avoid maintaining two nearly identical page sets. [SCREENSHOT: project documentation page showing shared content with audience-specific sections]

Before you decide to use audiences, compare that approach with simpler options:

• Use shared, untargeted content if differences between readers are small
• Use separate pages if only a few topics need different wording
• Use separate projects or spaces if the content, navigation, and ownership are mostly different

Audience targeting also changes how you plan the project. You need to think ahead about page structure, reusable content, review steps, and published navigation. A page that works well for one reader group can become confusing for another if key headings, links, or numbered instructions are hidden. If you already worked through content structure decisions in Applying Audiences to Documentation Structure and Content Decisions, use that guidance here to decide whether your project should stay unified or be split into cleaner reader paths.

Defining Audiences Before You Build Content

Define your audiences before your team starts building pages, versions, and reusable content. In Atloria, this planning work is easiest when you do it at the project level first, then carry those decisions into page creation and publishing review. If you wait until pages already exist, teams often apply audience labels inconsistently and end up reworking navigation, links, and page sections later.

Start by listing the reader groups your project serves. Common examples include:

• External Customers
• Partners
• Internal Support
• Project Administrators
• Implementation Teams

For each audience, decide what they should see and what they should not see. Write those decisions in plain language your contributors can follow. For example, you might decide that External Customers can see setup, usage, and troubleshooting pages, while Internal Support can also see escalation steps and internal review notes. Keep these rules close to the project documentation process so editors can apply the same targeting choices every time they update a page.

Use this planning sequence:

1. Open the project workspace and review the main documentation areas your team plans to create.
2. List each reader group that will use the published documentation or project content.
3. For each group, note which page types, instructions, warnings, and configuration details belong to them.
4. Mark any content that should stay visible to all readers, such as common navigation steps or general introductions.
5. Decide who on your team can approve new audience definitions and who reviews audience use before publishing.

Keep your audience list as small as possible. Broad, stable labels are usually easier to manage than many narrow labels that overlap. If two audience names lead editors to ask, “Which one should I choose?” they are probably too similar. For hands-on setup of audience definitions inside a project, see Managing Project Audiences for Targeted Documentation.

Choosing Audience Names That Stay Clear Over Time

Audience names need to stay understandable long after the original project team has changed. In Atloria, these names appear wherever contributors choose who should see targeted content, so unclear labels create editing mistakes, review delays, and confusing publishing results. A good audience name tells editors exactly who the content is for without requiring background knowledge.

Choose names based on recognizable reader roles, not internal shorthand. Names such as Project Administrators, External Customers, or Internal Support are much easier to apply consistently than labels like Advanced, Tier 2, Blue Team, or Q4 Launch Group. Those vague or temporary labels may make sense during one release cycle, but they usually become unclear when the project grows or new contributors join.

A simple naming standard helps keep audience options clean across the project:

Also decide how your team will handle renamed, merged, or retired audiences. If Partners is later merged into External Customers, review the pages and reusable content that still use the old label. Without that cleanup, editors may continue targeting content to an outdated audience name and create gaps in the published experience. Keep a simple record of approved names, older names that should no longer be used, and who can approve changes. This keeps audience selection predictable wherever contributors work in Atloria.

Structuring Pages Around Targeted and Shared Content

When you plan audience targeting in Atloria, build each page around shared content first. Put the information that everyone needs in the main flow of the page, then add targeted sections only where the experience truly changes. This keeps maintenance lower and makes pages easier to read, review, and publish across multiple reader groups.

Shared content usually includes page introductions, prerequisites, navigation paths, common setup steps, and expected outcomes. Audience-specific content often includes permission notes, internal-only warnings, different approval paths, or extra configuration details for administrators and support teams. If you place too much shared information inside targeted sections, some readers may lose the context they need to complete the task.

Use this page-planning sequence when outlining content:

1. Draft the full task flow using only the steps every reader must follow.
2. Highlight the points where one audience needs different instructions, extra warnings, or restricted details.
3. Move only those differences into targeted sections, leaving the main page structure visible to all readers.
4. Read the page again as if you were each audience, checking that headings, numbered steps, and links still make sense.
5. Split the page into separate pages if most of the content is hidden for one or more audiences.

A single page works well when the differences are small and the shared workflow stays easy to follow. Separate pages are usually better when each audience sees a very different process, different navigation, or different outcomes. For example, if a page contains one short section for Project Administrators but the rest applies to everyone, keep it together. If half the page is hidden from External Customers, create separate pages instead.

Also review cross-links and reusable content carefully. A link to a page with mostly hidden instructions can frustrate readers, especially in published documentation. Use the project hierarchy and page relationships to make sure each audience can move through the content without hitting dead ends or missing context.

Checking How Audience Targeting Changes Publishing and Reader Experience

Audience targeting affects more than page editing. It also changes how your team reviews content before publishing and how readers experience the finished documentation. In Atloria, a page can look complete to one audience while appearing incomplete or confusing to another, so your publishing process needs to account for every intended reader group.

During editorial review, check each targeted page from the perspective of each audience that will use it. Confirm that hidden sections do not break the page flow. A heading should still make sense if a targeted block beneath it is not visible. A numbered procedure should not jump from step 2 to step 5 because the middle steps were targeted to someone else. Links in navigation, related content, and reusable page elements should also lead to content that the selected audience can actually use.

Use this pre-publish review sequence:

1. Open the pages planned for release and identify any audience-specific sections or reusable content.
2. Review the page flow for each intended audience, checking headings, step order, notes, and links.
3. Confirm that shared navigation still leads readers to useful pages even when some sections are hidden.
4. Check that audience assignments match the naming rules and project decisions your team defined earlier.
5. Review the published reader experience, including discoverability and page-to-page movement, before final release approval.

This review matters for search and navigation as much as for page content. If readers can find a page through project navigation or published browsing but most of the important instructions are hidden from them, the page may create confusion instead of helping them. Keep that in mind when planning menus, page titles, and cross-links.

If your team is also preparing versions for release, combine audience review with your normal publishing checks so you do not validate content for only one reader group. For related release planning, see Publishing Documentation for Specific Audiences.

Fixing Common Audience Planning Mistakes

Most audience problems in Atloria start during planning, not publishing. If your team notices inconsistent targeting, confusing page flow, or unclear audience choices, fix the planning model first before editing large numbers of pages. That usually saves time and prevents the same issue from spreading into new content.

One common mistake is creating too many audiences. If contributors regularly hesitate between similar labels, the audience list is probably too detailed. For example, if editors cannot clearly distinguish between Internal Support, Support Managers, and Support Operations when targeting routine troubleshooting content, those labels may need to be consolidated. Fewer, clearer audience choices usually lead to better page consistency.

Another issue is unclear naming. Labels that depend on team history or internal shorthand are hard for new contributors to use correctly. Rename those audiences to match recognizable reader roles, then update the affected pages and reusable content so the new names are applied consistently.

Broken page flow is another frequent problem. This happens when shared instructions are placed inside targeted sections, leaving some readers without the context they need. It also appears when numbered procedures no longer read in order after hidden content is removed. Fix this by moving common instructions back into the visible page body and limiting targeted sections to the details that truly differ.

Use this correction process:

1. Review the audience list and identify labels that overlap or cause repeated editing mistakes.
2. Rename, merge, or retire unclear audience labels based on recognizable reader roles.
3. Audit targeted pages to find hidden sections that remove required context, steps, or outcomes.
4. Move shared instructions into the main page flow and keep only role-specific details targeted.
5. Add audience-specific review checks to your publishing process so the same issues do not return.

If you are seeing these problems across several projects, compare your project setup with the broader guidance in Defining Audiences for Targeted Documentation and Managing Project Audiences for Targeted Documentation.

Overview

Use this document when you are planning how a documentation project in Atloria should serve different reader groups before large amounts of content are written. The focus here is not on the mechanics of creating pages or publishing versions. Instead, it helps you decide whether audiences belong in the project at all, how to define them clearly, and how those decisions affect page structure, review, and reader navigation.

This planning step is most useful for teams working in shared project workspaces where one documentation set may need to support multiple readers, such as customers, partners, internal support teams, and administrators. In those cases, Atloria audiences help you keep shared content together while still controlling which sections are shown to specific readers. That can reduce duplication, but it also adds responsibility during content design and publishing review.

This document builds on the earlier guidance in Applying Audiences to Documentation Structure and Content Decisions. If you already understand how targeted content changes page design, the next step is to make project-level decisions that keep those patterns manageable over time. That includes agreeing on audience names, deciding who owns audience changes, and checking how targeted pages will behave in published documentation.

Use the sections below to plan your audience model before your team expands the page tree, creates reusable content, or prepares versions for release. [SCREENSHOT: Atloria project workspace with documentation navigation and audience planning notes]

Prerequisites

Before you use this planning guidance in Atloria, make sure the following project basics are already in place:

• You can sign in to Atloria and open the correct project workspace
• You understand the project’s main documentation goals and intended readers
• Your team has already discussed whether the project should stay unified or be split across separate projects or spaces
• You have reviewed Applying Audiences to Documentation Structure and Content Decisions
• You know who on your team can make project-level documentation decisions, especially for naming, publishing, and review
• You have access to the parts of Atloria where your team manages project content, versions, and publishing workflows

It also helps to gather a small planning group before you begin. Include the people who write documentation, review releases, manage project structure, and represent the reader groups most affected by targeted content. Audience planning works best when the same people who shape page structure also help define which readers should see each type of content.

If your team has not yet set up project audiences in Atloria, that is fine. This document is intended to help you make the decisions first so the setup is cleaner later. After you finish this planning work, continue with Planning Audience Targeting for Project Content to turn these project-level decisions into page-by-page content planning.