Managing Project Structure and Content Planning

Defining the Documentation Project Before You Start Writing

When you reach project setup in Atloria, use the onboarding form to define the project clearly before you create any pages. This is where you set the basic details that shape the rest of your documentation work. Enter the Project name exactly as your team wants it to appear in project lists and related workspaces. If your setup flow includes ownership details or a project brief area, add the internal owner there so everyone knows who is responsible for decisions during setup, review, and publishing.

Use the onboarding fields or project brief to record what this documentation project will cover. Be specific about which product areas, modules, or user workflows are included. Just as important, note what is out of scope so your page plan does not grow too early. If your team already worked through setup readiness in Managing Project Creation Choices and Setup Readiness, use those decisions here instead of redefining them.

If Atloria shows fields for audience or project intent, use them to identify who the documentation is for. For example, you may be planning content for administrators, end users, or internal teams. This helps you choose the right page titles and section groupings later.

Where contributor or team assignment options are available during setup, assign clear ownership for planning work. Typical responsibilities include:

• A documentation lead for structure and publishing decisions
• A writer for draft creation
• A reviewer for validation
• A project administrator for final setup control

If a target release, launch date, or version label is available, enter it during onboarding so the project timeline matches the documentation plan.

Building the Initial Page Hierarchy

Once the project exists in Atloria, move to the page structure or navigation area and start building the first version of your documentation hierarchy. This is the best time to create the main sections users will expect to see when they browse the project. Keep the top level simple and task-focused. Common section patterns include onboarding, configuration, daily workflows, and administration. These labels help readers understand where to go without needing internal team knowledge.

Follow these steps to build the first structure:

1. Open the project workspace and go to the page list, structure view, or navigation tree.
2. Create the top-level sections that represent the biggest user goals, such as getting started, setup tasks, routine work, and admin tasks.
3. Under each top-level section, add child pages for the specific tasks users need to complete.
4. Arrange the pages in the order you want readers to follow them.
5. If Atloria lets you drag and drop pages, use that control to move related topics under the correct parent page.
6. Leave lower-priority topics out of the main structure if they are not needed for launch, or keep them clearly marked as planned or draft if that option appears in the page list.

Choose page names that describe what the reader will do. For example, a title built around an action is easier to scan than a title based on internal product language. This keeps the sidebar and page list useful from the start.

As you build the structure, check whether each child page belongs under the correct parent page. If a page could fit in several places, rename it or move it until its purpose is obvious.

Organizing Scope with Content Types and Ownership

After the first hierarchy is in place, use Atloria’s page details, assignments, and status options to organize the work behind that structure. A page list is much easier to manage when each item has a clear purpose, a clear owner, and a clear status. This prevents the project from becoming a long list of untitled drafts with no review path.

Start by classifying each planned page by content type if Atloria gives you template, type, or category choices. You may separate pages into groups such as onboarding, guide, reference, or troubleshooting. Even at the planning stage, this helps your team keep similar pages consistent. A getting-started page should not be structured the same way as a troubleshooting page, so this early sorting matters.

Next, assign responsibility. Use assignment fields, contributor lists, or review settings in the project workspace to connect each page or section to the right person. A simple planning model looks like this:

Then separate launch content from later content. If Atloria shows status labels such as Planned, In Progress, Review, or Deferred, use them consistently. Mark must-have launch pages first, and move lower-priority topics into a deferred group rather than mixing them into the active writing list.

If your team works by release or milestone, group related pages into those buckets so the structure matches the rollout schedule. This makes it easier to see which pages support the next release and which pages can wait.

Making Early Decisions About Templates, Metadata, and Navigation

Before anyone starts drafting, decide how pages should be structured and labeled in Atloria. Early consistency saves time later, especially when several contributors are creating pages in the same project. If Atloria lets you choose a page template when creating or planning a page, select the right one up front. A task guide, a reference page, and an onboarding page usually need different layouts, so choosing the right format early helps keep the project organized.

Use page settings or planning fields to define the metadata every page should include. If these fields are available, make sure contributors know which ones are required and how they should be filled in.

Navigation planning matters just as much as page content. Review sidebar groupings, parent-child relationships, and landing-page links so readers can move naturally from onboarding into setup, then into daily tasks. If two pages seem to answer the same question, combine them or separate their purpose before drafting begins.

Standardize naming as early as possible. Use one pattern for folders, one pattern for page slugs if Atloria exposes them, and one pattern for section headings. For example, if one page starts with “Setting Up…” and another starts with a product term only your team understands, rename them so the sidebar feels consistent.

Reviewing the Plan with Stakeholders Before Authoring Begins

Before writers begin filling pages with content, review the planned structure with the people who will depend on it. In Atloria, this usually means sharing the project workspace, page list, or navigation plan with product, support, training, and documentation stakeholders. The goal is to confirm that the structure reflects real user needs before your team spends time writing and reviewing drafts.

Use a structured review process so the conversation stays focused:

1. Open the project workspace and display the current page hierarchy or page list.
2. Walk through each top-level section in reading order.
3. Confirm that every critical onboarding, setup, and operational workflow has a planned page.
4. Ask stakeholders to identify any missing user journey, duplicate topic, or misplaced page.
5. Review ownership and approval responsibilities for each major section.
6. Confirm who will handle draft review, technical validation, and publishing decisions.
7. Update the hierarchy, statuses, or assignments while feedback is still fresh.
8. Once the group agrees, treat that structure as the baseline plan for the project.

This review is also the right time to decide how future changes should be handled. If your team wants tighter control, ask the project administrator to manage major structure changes after approval. That keeps the navigation stable while writers work.

When you finish the review, make sure everyone understands which pages are approved for drafting now and which pages remain planned for later. A stable baseline helps prevent constant rework and keeps the project moving toward release.

Fixing Common Planning Problems Early

Even a well-planned project can become messy if you do not correct small structure problems early. Atloria makes these issues easier to spot when you review the page list, hierarchy, assignments, and statuses together. The sooner you fix them, the easier the writing phase will be.

One common problem is having too many top-level pages. If the navigation tree feels crowded, merge overlapping sections and move detailed topics into child pages. Readers should not have to scan a long list of unrelated items at the top level just to find a basic task.

Another frequent issue is unclear ownership. Open the page list and check the assignment or contributor fields. If a page has no writer, reviewer, or approver attached to it, assign one before drafting starts. Unowned pages often remain unfinished or get reviewed too late.

Scope expansion is another risk. If new ideas keep appearing during planning, return to the project brief or onboarding notes and compare them against your in-scope and out-of-scope decisions. Move extra topics to a deferred status instead of adding them directly into the active launch structure. This keeps the first release realistic.

Inconsistent naming also causes confusion. Scan the planned titles in the page list and look for mixed patterns. Rename pages so they follow the same style, especially in the sidebar. Task-based titles are usually easier for readers to understand than internal labels.

Use this quick check when reviewing the structure:

• Too many top-level pages: combine or nest related topics
• Missing owner: assign a writer, reviewer, or approver
• Expanding scope: move extra topics to Deferred
• Mixed naming style: rename pages to follow one task-based pattern

These small corrections make the project easier to review, easier to draft, and easier to publish later.

Overview

This stage of project setup in Atloria focuses on turning early onboarding decisions into a usable documentation plan. Instead of starting with draft pages immediately, you first shape the project structure so contributors know what to write, where each topic belongs, and who is responsible for it. The work in this stage usually happens inside the project workspace, page hierarchy, and page planning views.

The main goal is to create a structure that readers can follow. That means defining the project clearly, building a sensible page hierarchy, assigning ownership, and deciding how pages should be labeled and grouped. It also means separating launch-critical content from topics that can wait until after release. If you have already completed the setup readiness work in Managing Project Creation Choices and Setup Readiness, this document helps you turn those decisions into a practical page plan.

In Atloria, strong planning usually includes:

• A clear Project name and ownership record
• A page hierarchy with top-level sections and child pages
• Status labels that show what is planned now versus later
• Page assignments for writing, review, and approval
• Consistent titles, metadata, and navigation labels

This planning stage does not replace document authoring. It prepares the structure so authoring goes faster and produces a cleaner result. Once your hierarchy, ownership, and review path are stable, you can move on to the next setup decisions around delivery options and connected services in Configuring Project Delivery Options and Connected Services.

Prerequisites

Before you work on project structure and content planning in Atloria, make sure the project has already been created and the earlier onboarding choices are settled. This document assumes you are not deciding whether to create a project or how to begin setup. It assumes you are ready to organize the documentation inside the project workspace.

You should have the following in place before starting:

• Access to Atloria with permission to open the project workspace
• A project that has already been created during onboarding
• Basic setup decisions already reviewed in Managing Project Creation Choices and Setup Readiness
• A rough understanding of the product areas, workflows, or modules the documentation should cover
• The names of the people who will write, review, or approve content
• A target release, launch window, or documentation milestone if your team is working to a schedule

It also helps if you already know the main audience for the project, such as:

• Administrators
• End users
• Internal teams

If your team plans to use approvals, versioning, or publishing controls later, gather that information now so you can reflect it in page ownership and status planning. You do not need final page text yet, but you should be ready to create a page hierarchy, assign responsibilities, and identify which topics are required for launch.

If you are still choosing how the project should be set up, return to Choosing Between Manual and Connected Project Setup or Creating Projects and Completing Onboarding before continuing.