> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/best-practices/content-planning-how-to-structure-a-content-set-that-scales.md).

# Content planning: how to structure a content set that scales

How to decide what to build first, which content type fits each goal, and when to add more.

Most teams start by building guides for the processes they trained last. That works for the first five guides. It breaks down once different user groups need different content, the team cannot tell what is missing, and old guides fail after application updates without anyone noticing.

## How it works

{% stepper %}
{% step %}

#### Design audiences before building content

The most common planning mistake is building content first and adding targeting later. Guides built for everyone serve nobody well, and retrofitting audience rules afterward means reviewing every piece.

Before creating content, identify the groups that use the application differently: roles, departments, experience levels, purchased packages. Define each group as an audience[^1] in Userlane. See [Audiences: design, test, and keep them accurate](/best-practices/audiences-design-test-and-keep-them-accurate.md) for the full method.

{% hint style="info" %}
**Example:** a hospital where nurses and pharmacists use the same electronic patient record (EPR) system but run different workflows needs separate audiences for each role. A software company where all users follow the same onboarding path may need only new-versus-returning.
{% endhint %}
{% endstep %}

{% step %}

#### Choose the right content type for each goal

Each content type in Userlane serves a different purpose. Picking the wrong one means the content either misses its goal or cannot be measured.

<table><thead><tr><th width="270.5859375">Goal</th><th>Content type</th></tr></thead><tbody><tr><td>Teach a multi-step process</td><td><a href="/assistance/in-app-guidance/creating-guides.md">Guide</a>: sequential, interactive, tracks completions</td></tr><tr><td>Explain a single field or icon</td><td><a href="/assistance/in-app-guidance/creating-tooltips.md">Tooltip</a> (hint): appears on hover without interrupting the workflow</td></tr><tr><td>Draw attention to an underused feature</td><td><a href="/assistance/in-app-guidance/creating-tooltips.md">Tooltip</a> (beacon): persistent visual indicator, activates on click</td></tr><tr><td>Announce a change or new feature</td><td><a href="/assistance/change-communication/announcements.md">Announcement</a>: push message via the Assistant, can be scheduled</td></tr><tr><td>Enforce correct data entry</td><td><a href="/assistance/in-app-guidance/validators.md">Validator</a>: checks input at the field level in three modes (<strong>Measure</strong>, <strong>Visible</strong>, <strong>Warning</strong>)</td></tr><tr><td>Track whether a workflow is completed</td><td><a href="/intelligence/tasks.md">Task</a>: multi-step measurement, feeds the Task Success dimension of HEART</td></tr><tr><td>Track a single interaction</td><td><a href="/intelligence/tags.md">Tag</a>: tracks one click or action, does not feed HEART</td></tr><tr><td>Trigger content when a condition is met</td><td><a href="/assistance/in-app-guidance/creating-contextual-actions.md">Contextual Action</a>: fires automatically based on element state, user activity, or content interaction within the current session</td></tr></tbody></table>

The Assistant[^2] is where announcements reach end users.

<div data-with-frame="true"><figure><img src="https://259567114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF6bxg8i3T6U4vZ3k7PHi%2Fuploads%2FrT2Nye56pIfG1ELQsCjl%2Feditor.png?alt=media&#x26;token=66c97d26-f8b1-48bc-a189-ef0a8b28a8c8" alt="The Userlane Editor, where guides, tooltips, and other content are created"><figcaption><p>Most content types in the table are created in the Editor. Announcements are created in the portal.</p></figcaption></figure></div>
{% endstep %}

{% step %}

#### Decide what to ship first

Not everything ships at once. Work through four questions in order.

**Which processes cause the most friction?** Look at support tickets, data entry errors, training requests, low [Task Success](/intelligence/heart/task-success.md) completion rates, and long completion times. Use HEART[^3] data or the organization's own operational data to rank them. Build content for the highest-impact process first: a guide on a high-friction workflow cuts support load measurably and gives the team an early result to show.

**What do new users need on their first day?** A welcome slide introducing the Assistant, a guide for the first process a new user completes, and tooltips on the navigation elements users ask about most. Keep this set small: three to five items, not fifteen.

**Where does data quality matter?** If specific fields must be filled correctly for compliance or downstream processes, deploy validators in **Measure** mode. This shows how often users enter incorrect values and builds the case for moving to **Visible** or **Warning** mode later.

**What should be tracked but not guided?** Place tasks on the multi-step workflows where completion matters. Tasks feed HEART without showing anything to end users. Place tags on the buttons or actions that indicate whether a feature is being used. Tags track usage on their own and do not feed HEART.
{% endstep %}

{% step %}

#### Add Contextual Actions when the base content is stable

Contextual Actions trigger content automatically when a condition is met within the current session. You can display a tooltip when a user interacts with a specific function, show an announcement after a user completes a process, or start a guide when a particular element appears on the page.

Wait until guides, tooltips, and announcements are tested and stable before you add Contextual Actions. A Contextual Action that fires the wrong guide or targets the wrong audience creates confusion rather than preventing it.
{% endstep %}

{% step %}

#### Review and retire quarterly

Content that is not maintained decays. Application updates change field names, move buttons, and add new pages. A guide that breaks after an update erodes trust in the Assistant.

Schedule a quarterly review using HEART data and content analytics. In each review:

* Fix or retire guides flagged by alert notifications.
* Review display rules[^4] after any application URL changes.
* Confirm that audience definitions still match current roles and departments.
* Confirm that validators and tasks still target the correct fields and elements.
* Review content analytics across all content types. Check guide completion rates and step-level drop-off points, announcement view and click-through rates, and validator trigger counts. A significant change usually points to a content length problem, a targeting mismatch, a broken selector, or an application change since the last review.
* Check Task Success data for new areas of friction. A drop in completion rates or an increase in completion time on a tracked workflow signals a process change or a content gap. Adjust existing content or add new content accordingly.

Removing outdated content improves the quality of what remains and keeps the Assistant's search results relevant.
{% endstep %}
{% endstepper %}

## How to know it is working

At each quarterly review, answer three questions:

1. **Is the content reaching the right people?** Content targeted at a specific audience should show higher completion rates than untargeted equivalents. If it does not, check the audience definition and whether the attributes behind it are being sent.
2. **Is the content being finished?** Stable or improving completion rates for high-priority guides mean the content length and targeting are right. Declining rates point to guide length, selector stability, or an application change since the last update.
3. **Is anything broken?** A rising alert notification count means application changes are outpacing content maintenance. Fix broken guides before building new ones.

{% hint style="warning" %}
**Caveat.** Analytics show what happened, not why. A guide with a low completion rate might be too long, badly targeted, or broken on step 3. Check step-level drop-off data before deciding what to fix.
{% endhint %}

## Relevant articles

{% content-ref url="/pages/NFn4yfhEX6UQ4Oy1WPAW" %}
[Audiences: design, test, and keep them accurate](/best-practices/audiences-design-test-and-keep-them-accurate.md)
{% endcontent-ref %}

{% content-ref url="/pages/i1K1cNUetLC3hx3jInea" %}
[Go-live: how to prepare for launch](/best-practices/go-live-how-to-prepare-for-launch.md)
{% endcontent-ref %}

{% content-ref url="/pages/HGvA2yvKz1f1Ux8Nm4PS" %}
[Guides: build, maintain, and make them effective](/best-practices/guides-build-maintain-and-make-them-effective.md)
{% endcontent-ref %}

{% content-ref url="/pages/PxdAhHlmuv43rj3RxGij" %}
[In-app guidance](/assistance/in-app-guidance.md)
{% endcontent-ref %}

{% content-ref url="/pages/TBF4QYHDMWQghy26u8xI" %}
[HEART](/intelligence/heart.md)
{% endcontent-ref %}

## FAQ

<details>

<summary>How many guides should an application have at go-live?</summary>

There is no fixed number. Start with the one or two workflows that cause the most support tickets or confusion. Add more after the first measurement cycle confirms what end users need. Fewer well-tested guides beat many untested ones.

</details>

<details>

<summary>When should validators be added?</summary>

Add validators when data quality or process compliance is a stated goal. Deploy in **Measure** mode first to see how often users submit incorrect values. Move to **Visible** or **Warning** mode once the data confirms a problem worth correcting. Validators feed the Risk dimension of HEART.

</details>

<details>

<summary>What is the difference between a task and a tag?</summary>

A task tracks a multi-step workflow and measures whether end users complete a sequence of actions in order. A tag tracks a single interaction: one click, one button press. Only tasks feed the Task Success dimension of HEART. Use tasks for process completion measurement and tags for feature adoption signals.

</details>

<details>

<summary>Should content be organized by audience or by process?</summary>

Organize by process, target by audience. Chapters in the Editor group related guides by workflow or feature area. Audiences control which users see which chapters and guides. Creating separate chapters per department that duplicate the same processes leads to maintenance problems when a process changes.

</details>

[^1]: An audience is a group of users defined by attribute rules, used to decide who sees Userlane content.

[^2]: The Assistant is the end-user-facing panel where guides, search, announcements, and help resources are accessible inside the application.

[^3]: HEART is Userlane's five-dimension model for scoring how well an application works for the people using it, on a scale of 0 to 100.

[^4]: A display rule is a URL-based condition that controls which pages content appears on.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.userlane.com/best-practices/content-planning-how-to-structure-a-content-set-that-scales.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.