## Defining the audiences that drive your documentation plan
Before you change a page outline, sidebar, or section order in Atloria, make sure your team is working from a clear audience list. In most teams, that means reviewing the audience definitions already set up for the project and confirming they still match the documentation you are about to write. If you need help creating or editing those audience records first, use [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation).

A useful audience record should capture more than just a name. Your team should agree on details that affect writing and publishing decisions, including:

| Audience detail | What to record | Why it matters in Atloria |
|---|---|---|
| Audience name | The label used in the project | Keeps page tags and navigation labels consistent |
| Role | Who the content is for, such as Documentation Managers or Technical Writers | Helps you choose the right tasks, examples, and terminology |
| Product knowledge level | Beginner, intermediate, or advanced | Affects whether pages start with definitions, context, or direct steps |
| Publishing target | Internal, customer-facing, or partner-only | Determines where the page should appear when published |
| Access type | Internal vs external | Helps prevent the wrong content from appearing in public documentation |

Store these decisions wherever your team already maintains content planning details in Atloria, such as page metadata, project audience settings, or the content brief used before drafting. The important part is consistency: the audience name used in the brief should match the audience label used on the page.

Before writers reorganize headings, split content into separate paths, or add audience-specific notes, get approval from the people who own documentation structure. That usually means the project lead, documentation manager, or another reviewer responsible for publishing decisions. [SCREENSHOT: audience settings and content planning notes side by side in a project workspace]

## Mapping audience needs to page structure
Once the audience is defined, use it to shape the page before you start writing full paragraphs. In Atloria, this usually happens in the page outline, content brief, or navigation planning view. The goal is to decide what kind of page each audience needs first: explanation, setup guidance, or a direct task flow.

1. Start by identifying the main reader for the page. If the page is for a beginner audience, place definitions, context, and basic orientation near the top. If the page is for an experienced audience, move quickly to procedures, settings, or reference details.
2. Decide how the page should open. Some audiences need a short explanation of why a task matters before they begin. Others need prerequisites first, especially when the page covers setup, permissions, or publishing choices.
3. Separate shared sections from audience-specific sections. For example, one page might include a shared introduction for all readers, followed by one heading for Documentation Managers and another for Technical Writers.
4. Label the outline clearly. In your headings, navigation notes, or content brief, mark which sections belong to each audience so reviewers can see the split before the page is published.
5. Set an order that matches reader confidence. Newer readers usually need “what this is” and “when to use it” before steps. Experienced readers often prefer “do this now” instructions first, with explanation below.

This structure work is especially important when one project serves multiple groups. A mixed page becomes easier to scan when each section has a clear audience purpose instead of blending policy, setup, and writing guidance together. In Atloria, that also helps when you later assign audience metadata and decide where the page should appear in navigation. [SCREENSHOT: documentation outline with audience-labeled headings]

## Choosing what each audience should see on the page
After the page structure is set, decide which parts of the content should be visible to each audience. In Atloria, this is where audience planning becomes practical: you are no longer deciding only who the page is for, but also which paragraphs, notes, examples, and media belong in front of that reader.

1. Review the page section by section and mark what every reader should see. Shared items often include the main procedure, a standard definition, or a common workflow that applies across roles.
2. Identify content that should appear only for a specific audience. This may include administrator-only setup notes, writer guidance, internal release timing, or examples written for a partner workflow rather than a customer workflow.
3. Check the page title and introduction. Some pages can use one shared title with audience-specific context below it. Others need a more specific opening paragraph so readers immediately know whether the page applies to them.
4. Review procedure steps and screenshots. Keep one canonical step sequence when the task is the same for all readers, then add audience-specific notes before or after the steps instead of duplicating the full procedure.
5. Remove internal-only details from external content. Editorial reminders, unpublished feature notes, and internal approval instructions should stay out of customer-facing or partner-facing outputs.

This approach helps you avoid maintaining several near-identical pages. In Atloria, it is usually better to keep one shared procedure where possible and surround it with audience-specific explanation, warnings, or examples. That way, when the task changes, your team updates the core instructions once instead of correcting multiple copies.

When you review embedded media, apply the same rule. A screenshot that shows internal workspace details may be appropriate for internal readers but not for public documentation. [SCREENSHOT: page editor showing shared content with audience-specific notes and media blocks]

## Preparing metadata and publication rules for targeted delivery
Audience planning is not complete until the page is tagged correctly for publishing. In Atloria, your page structure and content choices need to match the metadata used to control where the page appears. If the metadata is wrong, the right content can still end up in the wrong place.

1. Open the page settings or content properties and assign the audience information your team uses, such as audience tags, channel, product, or access level.
2. Confirm that the audience labels match the project’s approved audience names. Small differences in naming can create confusion when pages are filtered into navigation or publication outputs.
3. Check where the page is supposed to appear. A page meant for internal readers should route to the internal documentation experience, while customer-facing or partner-only pages should appear only in their intended collections.
4. Review navigation rules. Make sure audience-tagged pages appear only in the correct sidebar, landing page, or filtered view so readers do not see links that lead to content outside their access level.
5. Validate the page before publishing. Compare the page metadata, visible content, and publication destination together to make sure they all point to the same audience.

This is also the stage where teams catch mismatches such as a customer-facing page that still carries an internal audience tag, or a partner-only page that appears in a general navigation group. In Atloria, those issues are easier to fix before publication than after a version is released.

If your team uses the same source content for more than one destination, double-check that the page properties support that setup and that each output respects the intended audience filters. [SCREENSHOT: page settings panel with audience tags, access level, and publication destination]

## Reviewing audience decisions with writers and stakeholders
Audience-based planning works best when writers and reviewers check it before the page moves too far into drafting or publication. In Atloria, this review usually happens in the content brief, page draft, or project review workflow. The purpose is to confirm that the page is written for the intended reader, not just tagged for them.

1. Review the outline first. Check whether the section order fits the audience definition and whether beginner, intermediate, or advanced readers will encounter the right level of context at the top of the page.
2. Read the terminology closely. Make sure the page uses the language that audience expects. Documentation Managers may need governance and workflow language, while Technical Writers may need drafting and structure guidance.
3. Compare examples and screenshots against the audience. A public-facing example should not rely on internal team knowledge, and an internal guidance page should not hide important review or publishing details.
4. Confirm publication intent with stakeholders. Reviewers should agree on whether the page is internal, customer-facing, or partner-only before the page is approved for release.
5. Record the decision in the content brief or planning notes. Capture the approved audience, visibility rules, and publication destination so future edits do not accidentally change the page’s purpose.

This review step is especially helpful when a page serves two nearby audiences that need different levels of detail. A side-by-side review of drafts or outlines can show whether one version is too broad, too technical, or missing the governance detail expected by reviewers.

In Atloria, keeping these decisions in the page’s planning record makes later revision work much easier, especially when a new writer inherits the page. [SCREENSHOT: draft review view with comments about audience fit, terminology, and publication destination]

## Fixing common problems in audience-based content planning
Even with a good plan, audience-based pages can drift over time. In Atloria, the most common problems appear when a page tries to serve too many readers at once, when metadata no longer matches the content, or when internal details slip into public outputs. Fixing these issues usually starts with a focused page review.

1. Split mixed-purpose sections when one heading tries to serve different readers at the same time. If a section combines internal policy, writer guidance, and end-user steps, break it into separate audience-specific headings or separate pages.
2. Correct mismatched tagging. If the page sits in a customer-facing navigation area but contains internal review notes, update the metadata, move the page, or remove the restricted content so structure and visibility match.
3. Reduce duplication. When your team has copied the same procedure into several audience versions, keep one shared procedure and move only the audience-specific explanation, warnings, or examples into separate surrounding sections.
4. Review hidden and visible content before release. Check that internal-only notes, release timing details, and unpublished guidance are not included in external outputs.
5. Reconfirm the audience with stakeholders if the page has changed over time. A page that started as internal guidance may now belong in a partner collection or a customer-facing help set.

A quick quality check in Atloria should compare three things together: the page content, the audience metadata, and the navigation location. If those three do not align, readers will have a confusing experience even if the writing itself is strong.

When a page keeps causing confusion, it is often better to create cleaner audience-specific deliverables than to keep adding exceptions inside one crowded page. That keeps maintenance manageable and makes publishing decisions more reliable. [SCREENSHOT: page review showing incorrect audience placement and corrected navigation assignment]

## Overview
Applying audiences to documentation structure and content decisions in Atloria means turning audience definitions into visible choices on the page. Instead of treating audience planning as a label added at the end, you use it to decide how a page is organized, which sections appear first, what examples are shown, and where the page is published.

The main areas to review are:

- **Audience definitions**: Confirm the approved audience name, role, knowledge level, and publishing target before drafting.
- **Page structure**: Decide whether the page should begin with context, prerequisites, or a direct task sequence.
- **Content visibility**: Choose which notes, examples, screenshots, and warnings belong to all readers and which should appear only for a specific audience.
- **Metadata and publishing**: Match the page’s audience tags, access level, and destination so the right readers see the right content.
- **Review and maintenance**: Record approved decisions so later edits preserve the same audience logic.

If you have already created or updated project audiences, this document helps you apply those definitions to actual page planning. For the setup side of that work, refer back to [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation).

In practice, the strongest audience-based pages in Atloria are easy to scan because they do not force every reader through the same path. A beginner reader can get context and definitions first, while an experienced reader can reach procedures and reference details quickly. That balance depends on clear planning, accurate metadata, and careful review before publication.

## Prerequisites
Before you apply audience decisions to page structure and content in Atloria, make sure these items are already in place:

- You can access the relevant project workspace in Atloria.
- Your project already has audience definitions created or reviewed. If not, start with [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation).
- You know where your team records planning details, such as page briefs, page settings, or audience metadata fields.
- You are working on a page, outline, or draft that will be organized for one or more defined audiences.
- You know the intended publication destination for the content, such as internal documentation, customer-facing documentation, or a partner-only collection.
- The writer, documentation manager, or reviewer responsible for approving audience decisions is identified before major structural changes are made.

It also helps to have these materials ready while you work:

- A current page outline or draft
- The project’s approved audience names
- Any navigation plan or sidebar structure used for the documentation set
- Existing screenshots or examples that may need audience review

If your team is still deciding how audiences should fit into the broader documentation plan, the next step is [Planning Audience Targeting for Documentation Projects](doc:planning-audience-targeting-for-documentation-projects).