# The Strategic Value of Information Architecture for Growth-Stage SaaS
> Growth-stage SaaS companies scale revenue faster than they scale onboarding headcount, and most can’t tell whether that gap is costing them expansion revenue, because nobody has instrumented the question. The problem isn’t documentation volume. It’s whether onboarding content is structured to work without a person standing beside it.

## What actually moves net revenue, time to value, and feature adoption in SaaS onboarding

What do your leaders care about? Net revenue, time to value, feature adoption, and churn are likely high on the list. None of them are in your job description on paper. All four are affected by, at least in part, on something that is: can a customer find what they need without you standing next to them?

A customer who reaches their first real outcome faster moves time to value. One who finds that unknown-to-them-but-needed feature moves [feature adoption](/blog/strategic-value-user-assistance-content/), and often net revenue behind it. A customer who never has to guess what to do next is a customer who will always renew. These are different metrics that share a common lever: whether the content in front of them was built to help them, or just built to exist.

That lever is what the rest of this is about.

## Why SaaS companies can't afford white-glove onboarding at scale

When companies are starting out, it's all hands on deck to get projects delivered. Customers sense that personalized attention they get. It becomes one of the hallmarks that allowed you to grow.

That personalized service is what will prevent you from scaling.

The thing that got you to where you are has to change. You cannot hire more people fast enough to provide the hands-on customer service. Your leadership and investors require a self-serve approach.

You need to onboard more accounts, with proportionally less human time per account, without the activation rate dropping. Every quarter, someone above you asks for both at once. You're not in sales, but your content supports their effort.

Your team is already stretched across renewal risk, feature launches, and the accounts loud enough to escalate and continue to demand that custom service you're known for. They're not the ones you need to worry about. It's the accounts that have gone silent. Are they happy or are they disengaging and seeking an alternative? That silence is where churn actually starts, long before it shows up as a number anyone can act on.


## How information architecture reduces time to value (TTV)

So what actually shortens the distance between signup and the moment a customer gets real value from your product?

It's tempting to answer "better docs" or "a better product tour," and both miss the mechanism. Page views and time on page are metrics. **Net revenue retention, gross revenue retention, segmented activation rate, and time to value are the numbers your leadership actually tracks** — and they're rarely the numbers your onboarding content gets measured against, even though they're the ones it's actually driving.

[Time to value](/blog/strategic-value-user-assistance-content/) is a sequencing issue. Remove as much friction as possible. Make it like pushing the Easy button. If there is a hiccup, provide your customer with the ability to self-serve. 

But there is a significant difference between [providing contextual information where a person needs it](/blog/strategic-value-delivery-ia/), providing the same content in a support portal, or, worse, in a PDF. Even when the content is identical and equally accurate, the friction increases with each one for the customer.

## Documentation vs. onboarding: why they're not the same thing

Documentation answers a question someone already knows how to ask. [Onboarding has to work before the customer knows what to ask](/blog/rabbit-holes-vs-rescue-ropes/).

That distinction is important. And it's significant. It's a necessary change in perspective too. A reference article assumes the reader already knows their use case, their plan tier, their integration setup. Onboarding content has to route around all of that uncertainty and still land the customer at a specific outcome: their first successful action inside the product.

Treating onboarding as "documentation, but earlier" produces exactly what most growth-stage SaaS companies have: a knowledge base that's technically complete and functionally useless to someone who doesn't yet know the vocabulary to search it.

## Can you measure whether undiscovered features are costing you revenue?

Most people don't want to have to stop what they're doing to call a support line. Buyers expect self-service before they expect a human. [Zendesk's customer research found that 67% of people prefer solving a problem themselves over contacting a company representative](https://www.zendesk.com/blog/help-center/self-service/searching-for-self-service/), and 91% would use a self-service knowledge base if one existed that actually matched their situation. [Gartner's most recent sales survey found two in three B2B buyers now prefer a rep-free purchasing experience](https://www.gartner.com/en/newsroom/press-releases/2026-03-09-gartner-sales-survey-finds-67-percent-of-b2b-buyers-prefer-a-rep-free-experience). Neither is an onboarding-stage statistic. Both describe the same expectation your customers carry into onboarding: they assume they can find what they need without asking.

Can you actually tell whether you're meeting those expectations? Unless your technical support and onboarding content is structured and instrumented, you can't. If you want true visibility, you need intelligent content you can instantiate. 

Identify a business goal you want to track. Find the relevant content that represents the happy path. Monitor how readers traverse the content. Where do they enter? Where do they click? Exit? How long does it take to move from phase to phase? Is it what you expect? 

While "more help" seems like the easy fix, you need to be open to process or interface change.

Repeat the process for the next business goal.

## How to audit your onboarding content for information architecture gaps

You don't need a redesign to find out where the structure is missing. You need to know whether you can currently answer four questions, using data your team should already have:

- Can you decompose net revenue retention and gross revenue retention cleanly enough to say why either one moved this quarter, or do you only see the topline number and guess at the cause?
- Is "time to value" a specific, instrumented event in your product, held consistent across every plan tier and use case, or is it standing in for "time to onboarding checklist complete," a different and easier metric wearing the harder one's name?
- Is activation rate reported as a single company-wide average, or segmented by plan and use case so that a thriving segment can't hide a failing one?
- Can you tie expansion revenue back to what content and features were actually surfaced to a given account, or is "the customer didn't want to expand" currently indistinguishable from "the customer never knew there was something to expand into"?

Those four questions won't fix the structure. They'll tell you, in an afternoon, whether the gap is a content problem or a structural one, and which conversation you need to be having next quarter instead of the one you've been having for the last four.

## The top 5 KPIs for a SaaS onboarding content dashboard

The audit above tells you whether you can measure any of this. Once you can, here's the scorecard worth putting in front of leadership, and what you actually own on each line.

- **Can a new customer solve their own problem without opening a case?** You don't own the support queue. You own whether the answer exists somewhere they'll find it before they give up and reach for the phone.
- **Can they find the right answer for the handful of questions that drive most of your onboarding friction?** You own the vocabulary. If your content calls something one thing and the customer searches for another, [the answer might as well not exist](/blog/ctrl-f-means-you-fail/).
- **Can they complete the small number of workflows that actually define activation?** Not every workflow deserves the same investment. You decide which ones get [full, structured, start-to-finish support](/blog/strategic-value-management-ia/), and which ones stay thin.
- **Is your highest-traffic, highest-risk onboarding content actually current?** Stale content competing in search against the content that replaced it is worse than no content at all. You own the review cycle that decides what "current" means and enforces it.
- **How far behind your product releases is your onboarding content?** A feature that shipped and never made it into the onboarding sequence is functionally undiscovered, no matter how good the feature is. You own the trigger that turns a product change into a content update, and how fast that trigger fires.

None of these five require a redesign, a new platform, or a bigger team to start tracking. They require deciding that content is a line on the dashboard, not an afterthought to one.

Knowing which five numbers matter is the easy part. Knowing exactly which levers move each one, inside your specific content stack, with the team you already have, is a longer conversation, and one worth having before the next budget cycle instead of after it. [Get in touch when you're ready to have it](https://calendly.com/intuitive-lief/discovery-initial-consultation).

---

# EPPO is Not Dead: Every Page Is Page One in the Age of Generative AI
> EPPO still matters as an information architecture principle in the age of LLMs. But the meager paragraph has to do more. While the page is still the container, each paragraph, list, or table must be able to stand on its own out of context. It might be just the answer your customer is looking for.

**EPPO** is [Mark Baker’s principle](https://everypageispageone.com) that content should be written so any page can be a reader’s first point of entry — self-contained, explicitly scoped, and not dependent on the reader having read anything on your site before it. In the age of LLM-mediated search, the same requirement now applies one level down: to the paragraph or fragment an AI retrieves, not just the page. 

In a previous post we talked about the strategic value of Baker’s [Every Page Is Page One](/blog/strategic-value-every-page-is-page-one/). Baker himself built on Pirolli and Card’s “scent of information.” Today, that “scent” is often tracked by an LLM. Does a paragraph makes sense in isolation, not dependent on what comes before or after?

## Why AI bots are reading your content instead of humans

While we might be cranky that our sites don’t have the same number of human visitors, we still have plenty of robot visitors. There’s a high chance the person who uses our content never makes it to our website. And yet our content is still being used to supply the answer. 

As content professionals, we need to worry about what we have always concerned ourselves with: creating high-quality, correct information that is well suited for our readers. 

Now, we need to also worry about LLMs hallucinating. If the answer requires combining information from content on multiple pages, the LLM may not retrieve all of the necessary information, even when links are provided. Public LLMs won't know your content and its nuances and
specialized vocabulary, unless they have been specifically trained on it. Remember, LLMs are looking for statistical
similarity, both of the user’s query and their intent and of your content. It’s guessing.

## Why AI-synthesized answers aren't the same as human judgment

When a user asks a question, the sequence is no longer: *human searches, finds page, reads page, judges the value of
the source content as appropriate and correct.* It is: *human asks, AI retrieves fragments, AI synthesizes answer, human
judges AI’s synthesized response.*

**EPPO and scent disappears.** What the AI retrieves are sections, paragraphs, or blocks. There’s nothing inherently incorrect
about this approach. What AI cannot do is judge whether those were the correct pieces to retrieve or what might be
missing. AI systems can go through a mechanical process of ranking and re-ranking, which may seem like its ‘judging’ the
content, but it’s not exactly the same. It did so solely on statistical similarity, and, maybe, some additional
training. That’s why AI summaries provide links to its sources, so that you, a human, can read the source material and
judge for yourself whether what the AI pulled supported its result.

But similarity is a ranking exercise, not a completeness check. Retrieval can tell you which fragments look most relevant to each other; it can’t tell you whether the candidate set is missing something that was never included in the first place. It doesn’t know what it didn’t retrieve.

## From EPPO’s “topic” to the AI era’s “fragment”

We may not always like it, but a human can tolerate decontextualization. We can notice when something is missing or off and fill in the gaps. We can look around for clues. We might look for a sidebar or click “Up.” An AI works with what its given. A fragment that depends on context not present in the retrieved chunk is apt to produce a confident but wrong answer. Vector-based retrieval is probabilistic; it ranks by similarity without certainty. GraphRAG trades some of that flexibility for [symbolic structure](https://thinkingdocumentation.com/downloads), and that structure is what makes complex, multi-hop answers reliable rather than lucky. Authors who write EPPO-compliant topics (complete, well-scoped, explicitly contextualized) produce the high-quality training and retrieval data that AI requires.

## How to apply EPPO principles as metadata for AI retrieval

The shift to AI-mediated delivery requires a tactical change in how we handle metadata and structure. When AI synthesizes your content, your content authors shouldn’t abandon EPPO’s principles. Your writers should lean into the principles, making them explicit as metadata where they can be leveraged beyond their semantic qualities.

### Metadata as a Targeting Mechanism

Before LLMs, metadata helped humans browse. In the AI era, metadata helps LLMs normalize or separate similar terms, and gives [retrieval systems the chunk boundaries](/blog/strategic-value-management-ia/) they'd otherwise have to guess at.

| Element | Pre-AI (Search Optimization) | AI-Era (Retrieval Precision) | EPPO Principle |
| :--- | :--- | :--- | :--- |
| **Title** | `Configuration` | `Configuring OAuth 2.0 for API Gateway v3.1` | Establish context; specific and limited purpose |
| **Short Description** | `How to set up your system.` | `Prerequisites and steps for enabling OAuth 2.0 authentication on the API Gateway for Enterprise environments.` | Establish context |
| **Tags** | `setup, admin` | `auth-protocol:oauth2; product-version:3.1; user-persona:security-admin` | Assume the reader is qualified; conform to a consistent pattern |

A vague title like `Configuration` — a common title in many user guides — relies on its place in a hierarchy or the surrounding navigation to provide context. That context disappears in an LLM. The expanded title is “specific and limited purpose” title: (OAuth 2.0, this gateway, this version). It’s explicit about the content of its topic rather than implying it covers configuration more broadly.

Metadata that can be implicit or exposed does something similar for “assume the reader is qualified.” This meant writing for the person who normally performs the task, not explaining every term to every possible reader. Experienced and professional technical writers used their judgment and user research to identify who was ‘qualified.’ Now that needs to be made explicitly: `user-persona:security-admin`, because the thing consuming the tag now has to be trained on your specific content and user personas to infer qualification level from tone or vocabulary the way a human skimming the page could. The metadata makes it explicit for all user types.

### The Fragment Test: Can Each Paragraph Stand Alone?

Baker wrote about ‘pages,’ which could roughly be considered a ‘topic.’ (We are using ‘topic’ here in a Wikipedia sense of the word, not an information architecture sense.) With LLMs we need to move into the sub-topic, the fragment, and [size that fragment deliberately](/blog/how-big-is-a-topic/) rather than leave it to chance. Every paragraph should be interpretable in isolation. If an AI retrieves a paragraph about “the reset button,” the metadata or the text itself must identify which device that button belongs to, or the AI may hallucinate context from an adjacent but irrelevant product topic.


### Subject Affinity: The Case for GraphRAG

The EPPO principle to link by subject affinity is a natural precursor to knowledge-graph structures: rich, deliberate links between related topics are the basis for graphs. Building the graph itself, with typed, machine-traversable nodes an AI can use for multi-hop reasoning, is separate work on top of that linking discipline. That work is exactly what [GraphRAG benchmarks measure](https://arxiv.org/abs/2506.02404). But it starts from scratch if the underlying content isn't already linked with intent. Organizations with deliberate subject-affinity linking have a head start that organizations without it don’t. [Unstructured corpora return inconsistent answers](/blog/strategic-value-information-architecture/) regardless of how capable the model is.

### Why “Stay on One Level” Doesn't Work for LLMs

Not all seven principles port cleanly for LLMs. “Stay on one level” assumes a *reader* who chooses when to shift between general principles and concrete examples, following a link when they’re ready to change levels. An LLM doesn’t make that choice the way a person does; it retrieves a topic or it doesn’t. This may be the one place EPPO’s authoring guidance needs to be adjusted: level needs to be stated as fragment-level metadata, not left as something the writer trusts the reader to navigate. (And this is where ‘topic’ could be used in the information architecture sense.)

## EPPO content is a head start for AI retrieval

Organizations that already practice Every Page Is Page One — well-scoped, self-contained, richly linked topics — are ahead of the curve. They’re well positioned to take advantage of their content as a strategic asset.

---

If you want to understand how your current content architecture holds up as an AI retrieval source, [schedule a call](https://calendly.com/intuitive-lief/discovery-initial-consultation) and we can work through what your corpus looks like from the retrieval side.

---

# How Big Is a Topic? Sizing at the Source and at Delivery
> Topic size isn’t just a stylistic choice; it’s a financial and technical one, and it’s really two questions. How big should a topic be where it’s authored, and how big should the page be once it reaches a reader? Here is the strategic case for the 250-word target, and why it can still fall apart at delivery.

Documentation leaders often ask about topic size when writers can't agree on where new content belongs, or when support portals start feeling like a maze. While frameworks like DITA and Diataxis define topic *types* (task vs. concept), they do not prescribe a length.

When referring to topic size, we are really looking at length or, more precisely, word count. It's not the column inches or amount of disk space.

**Are you concerned about topic length for your authors, readers, or both?** *How big should a topic be where it's authored and maintained?* This is a [management information architecture](/blog/strategic-value-management-ia/) question. *And how big should the page be for a reader?* This is a [delivery information architecture](/blog/strategic-value-delivery-ia/) one. A well-sized source topic can still arrive at the reader too big or too small, because delivery can combine, split, or transclude topics independently of how they're stored. This affects wayfinding and user experience of your content.

Over time topics grow and the writer doesn't have a framework for when to say 'enough is enough; time to split.' It's a common pattern we see in many organizations. I described my own experiences in [rabbit holes vs rescue ropes](/blog/rabbit-holes-vs-rescue-ropes/).

Setting a maximum topic length target is dependent on you and your content. You can have a schema or your CMS validate or enforce size limits, though.

## How big should a topic be at the source?

*The Language of Content Strategy* identifies the core tension: a topic should be large enough to be self-contained from a writer's perspective, yet small enough to be portable across different contexts.

There are three primary pressures that determine this balance:

* **Reuse (The Pull Toward Smaller):** Smaller topics are more portable, easier to assemble into multiple outputs, and cheaper to localize. However, stripping too much context turns a topic into a fragment that **cannot stand alone**, rendering the corpus practically unusable.
* **Enough Context (The Pull Toward Larger):** Because most readers arrive via search or direct links, every topic must carry **the minimum context a reader needs to be successful** [without requiring them to read prior material](/blog/strategic-value-every-page-is-page-one/).
* **AI Retrieval (The Stakes Raiser):** Retrieval-augmented generation (RAG) systems pull individual chunks to build answers; if a topic is too dependent on surrounding context, **the AI surfaces the piece but loses the frame**, leading to immediate ambiguity in generated answers.

### How long should a topic be? The 250-word benchmark

At DITA Europe 2026, content practitioners from ServiceNow spoke about a target of roughly **250 words per topic**. **It's not a rigid rule; it's a working constraint** that keeps writers honest about scope. Shorter topics cost less to localize, which is critical for organizations publishing in multiple languages.

A team without a topic size expectation tends to let topics expand indefinitely, making it harder for readers to find the specific answer they need. We want **readers arriving on a page to get a complete answer**, or an AI system to reason and synthesize an accurate response from the content.

## How big should a topic be at delivery?

A well-sized source topic doesn't guarantee a good reader experience. Can a user who arrives at a page get a complete answer to their question without clicking elsewhere? If the answer is no, the delivered page has a chunking problem that usually goes in one of two directions: the "Frankenbook" or the "infinite scroll," and neither is really about how the source topic was sized. It's about how delivery assembled it.

It's important to isolate '*to their question*' in the previous paragraph. A person who gets an answer to one question may have follow-up questions. Follow-up questions are signal of a new user journey. That journey may be closely related to the one the user was just on, but it can be isolated and viewed independently. The answer to the follow-up questions do not need to be on the same page. They might be, and that is why user research and having a true understanding of what your readers need is necessary. 

### The too-small "Frankenbook"

When moving to topic-based authoring, teams often treat a "topic" as a page-building unit rather than an information design philosophy. This creates the [Frankenbook](https://everypageispageone.com/2012/02/24/frankenbooks-must-die-a-rant/) problem: content with required context is broken into individual pages that assume the reader has seen everything before it. These pages can be easy to spot. They tend to be mechanically and arbitrarily split at every heading, even heading 5s get their own page. 

### The too-large "infinite scroll"

Conversely, some delivery layers skip chunking entirely, stitching well-scoped source topics into long pages that force users to scroll for answers. While infinite scrolling works for social feeds where users are "browsing," it is not recommended for documentation, where wayfinding depends on finding specific information quickly.

Nielsen Norman Group (NN/g) [research highlights the user experience (UX) cost of long pages](https://www.nngroup.com/articles/scrolling-and-attention/):
* **Attention Drops:** 74% of viewing time is concentrated in the first two screenfuls.
* **Scanning Efficiency:** Well-structured content enables users to focus efficiently on task-relevant information; removing that structure makes finding a "needle in a haystack" harder.

## Why a well-sized topic can still fail at delivery

A topic sized correctly at 250 words in the CMS doesn't guarantee a well-sized reader experience. Delivery can assemble several well-written source topics into one long page (infinite scroll) or split a single coherent topic across multiple screens or paginated views (Frankenbook), independent of how disciplined the authoring was. Getting topic size right requires attention at both layers: [management IA](/blog/strategic-value-management-ia/) governs what's authored and maintained as one unit; [delivery IA](/blog/strategic-value-delivery-ia/) governs what's actually assembled and rendered for the reader.

**The UX Audit:** Look at your five highest-traffic delivered pages, not your source topics. Can a reader have enough context to get a complete answer without leaving? If not, the problem may be delivery assembly rather than the authored topic size.

---

If your content structure is making it harder for systems to surface answers, [schedule a conversation](https://calendly.com/intuitive-lief/discovery-initial-consultation) to work through your architecture.

---

# Rabbit Holes vs. Rescue Ropes: Designing for Reader Intent
> A Wikipedia reader and a support agent or service technician are in two different worlds. One is following curiosity; the other is fighting a fire. Here is how to know when a sub-topic needs to stand on its own.

As a technical writer, I'd get requests to "add just one more thing" to a section of documentation. For some topics, that meant it just grew out of control, until a single topic was pages and pages long.

Intuitively, I knew none of that could stay consumable or skimmable for a novice or even an intermediate user. It was content really designed for the expert, and that always made me uneasy: [content added for the expert made things worse for the novice](/blog/content-depth-by-expertise/).

So I was often hunting for a place to put the "expert stuff," cleaving off bits and pieces to stash elsewhere, wherever elsewhere was. I needed a framework for deciding when something had gotten too big and needed to be reshaped.

Wikipedia is a standard reference for ["Every Page Is Page One"](/blog/strategic-value-every-page-is-page-one/)-style content. Its articles are designed for **browsing mode**, where readers often follow "rabbit holes." Because of this, Wikipedia’s size guidelines prioritize logical separability—the moment a sub-topic is distinct enough to stand alone, it gets its own page.

**It was a logical separability framework that I needed.**

## Why documentation readers need a rescue rope, not a rabbit hole
Documentation readers are almost always in **task mode**. They aren't usually following curiosity about your product (although sometimes they do); they are looking for a **rescue rope**. When a user is on the clock, their ability to filter out "interesting but irrelevant" context diminishes.

## When should you split a topic? The One-Question Test
Writers often ask me how to handle a topic that keeps attracting new material. The temptation is to let it grow, but [length is merely a symptom](/blog/how-big-is-a-topic/); **separability** is the real question. 

If you are wondering whether to split a topic, apply the **One-Question Test**:
* **Does this section answer a distinct, specific question?** If yes, it likely belongs in its own topic.
* **Can a reader arrive here cold and leave successful?** If the section requires the context of the entire page to make sense, it is a fragment. If it stands alone, it should be its own addressable unit.
* **Is it a "distinct topic" or a sub-step?** Wikipedia editors ask if content is complete enough to stand as a distinct topic or if it properly belongs inside a larger one. In user assistance, if a sub-section is a destination for a search result, it needs to be a separate page.

## How splitting topics helps search engines and AI find the right answer
A person reading documentation has a specific work problem and wants an answer quickly. Applying the One-Question Test consistently means **search engines and AI systems surface the "rescue rope" directly, rather than forcing the user to hunt through a "rabbit hole" of tangentially related info.**

---

If your team is struggling to define where one topic ends and the next begins, [schedule a conversation](https://calendly.com/intuitive-lief/discovery-initial-consultation) to refine your editorial standards.

---

# Every Topic Is a Microstory
> Your reader is the hero of this story, not your product. A microstory puts them in that role: a real problem, a guide who gets them through it, a visible win. Apply that structure to your technical writing.

Years ago, when I was starting as a technical writer, the industry was filled with people with degrees in journalism and creative writing. The Technical Communication majors were few and far between. There was a joke that technical writing paid the bills and allowed for the poets and novelists to fund their passion projects at night.  

What I couldn't and didn't appreciate at the time was that these colleagues were trained in storytelling. I dismissed it as unneeded in our work. Boy, was I wrong.

It took a course on filmmaking to open my eyes to storytelling. It made me recall a humanities class in high school where I learned about Joseph Campbell and The Hero's Journey. I started to look at my work through a different lens (figuratively, not literally). It recast the characters and what my role was in the delivery of user assistance content. I was no longer merely a technical writer or information architect. My reader was no longer “the user.” I was a guide, helping shepherd ‘the hero’ around an obstacle in their path to transformation.

## When accurate documentation still fails

A microstory, like any story, has an inciting incident, an obstacle to overcome, and a resolution. It doesn’t need to be a grand epic.

During the IDEAS conference, I was talking with Rahel Bailie, who told me about the week her internet provider swapped in a new fiber router. Every device in her home needed new Wi-Fi credentials, printer included, and she had something she urgently needed to print. 

The printer’s user manual told her to push the ‘home’ button. There was no ‘home’ button on her printer. She searched for it, and found instructions showing a panel that looked nothing like the one in front of her. Twenty minutes and a few dead ends later, she texted her partner. His answer: delete the printer and add it again. That worked. **Nothing in the documentation had ever mentioned it.**

I’ve had a version of this too, minus even the bad instructions. I was buying concert tickets from Ticketmaster. At least I was trying to. I was signed into my account, and had tickets in my cart. With the countdown timer running before the tickets would be released for someone else to purchase, I was literally on the clock. 

I kept being looped back to a screen telling me to log in to my account. I was logged in! Ticketmaster’s ‘helpful’ advice was to switch to a different device. Fine, I switched from my phone to my laptop. Same error with the laptop, but now the advice was to switch my Wi-Fi network. (How is that even practical? Do they think people have multiple Wi-Fi networks in their home they can just jump from one to the other?) I was so frustrated that I wanted to chuck my laptop and my phone. (This would be the stress and cortisol moment.) 

I went deep into Ticketmaster’s feedback form to report my experience. There was an option to attach an image, so I went looking for the screenshot I’d already taken. Surely I could attach it from my gallery. No. All I could do was take a live photo right then, which made zero sense to me. Rahel at least had a bad instruction to blame. I didn’t even get that. I needed [a rescue rope](/blog/rabbit-holes-vs-rescue-ropes/).

I never did get my tickets. And if Ticketmaster ever reads this, it’ll be the only way they know I couldn’t even use their own form to report the problem. I’m pretty certain they don’t care.

**But you should.** Your users have a task they’re trying to accomplish with your product. You want them to succeed as efficiently as possible. Otherwise, it’s you and your product that look bad.


## The narrative arc every help topic needs

When a user lands on a help topic, something has already gone wrong. Rahel needed to print and I wanted to buy a concert ticket. Your users are no different: they have a problem and need it resolved, and they are not sure they have found the right page.

That uncertainty is not just an emotion. Their cortisol level, the stress hormone, is elevated. **If the first few lines of your topic do not immediately signal “you are in the right place,” they leave** (or chuck their laptop).

Good documentation recognizes where the user is at and meets them where they are. As the topic makes the user’s situation visible and accurate, oxytocin rises: the recognition response, the sense of being understood. When the user completes the task, dopamine releases. The story is done. Happy ending. Rahel eventually got that relief, from her partner, not from the manual. I never got it at all.

Bad documentation ignores all of this. It puts the product front and center, not the user. 

## The hero’s journey: user as hero, writer as guide

The hero’s journey maps onto almost any human experience of challenge and resolution. A hero has a problem. A guide provides the path. The hero works through the obstacles and arrives transformed at the other side.

In user assistance content, the reader is the hero. They came to your help system because something is blocking them. **The documentation is the guide.**

Donna Lichaw makes the same point about product design in *The User’s Journey*: “As much as you want your business to be the hero of the story, your users are the real heroes. Think of your product as Dorothy’s ruby slippers. Without your product, she would never be able to solve her problem.”

The same logic applies to every help topic. The guide’s job is not to explain how the product works. It is to get the hero through the problem. Rahel’s manual explained the product. It never got her to a working printer. That distinction rewrites what topic-based authoring is for: how topics are opened, structured, and closed.

## Six questions for topic-based authoring

We use the following six questions, drawn from the hero’s journey, as a pre-writing checklist for every topic. You can map the questions directly onto your topic-based authoring.

![A help page faded to the background, with story-diagnostic questions overlaid and the cortisol-to-oxytocin-to-dopamine arc on the right side.](/blog/images/ia-brain-chemicals-microstory-mapping-questions.png)
*The six diagnostic questions applied to a corporate password change topic.*

**What is the inciting incident or conflict?**
What situation brought this user to this page right now? A password is expiring in 14 days. An error message appeared at login. An account is locked. This is the cortisol trigger. 

**Who is the hero?**
Which user are you writing for? A new employee who has never changed a corporate password is a different reader from a power user managing multiple accounts. The answer determines vocabulary, assumed context, and how much procedural detail the topic needs.

**Why did they come to this page?**
Not what they are doing, but why they care. The reader needs context, otherwise they assume they are in the wrong place and they leave. This is where oxytocin is built or lost. 

**What content is needed?**
Given the hero and the situation, [what is the minimum necessary](/blog/how-big-is-a-topic/) to get them through? Be judicious about what you choose to include. Everything else is noise. Noise increases cognitive load. Cognitive load increases the cortisol levels. 

**In service of what goal? What is success?**
What does the completed task look like? A result statement, “Your new password is active. You can sign in immediately,” is the dopamine moment. It confirms the story is over. Leaving it out ends the topic without telling the user whether it worked.

**How is it measured?**
At the program level: is this topic working? [Support ticket volume](/blog/strategic-value-user-assistance-content/) on this task, task completion rates, search dead-ends on related queries. These signals tell a documentation team whether the narrative arc is landing in practice, not just in theory.

---

The six questions above are a starting point. The [Intelligent Content Maturity Assessment](https://www.intuitivestack.io/assessment) extends that diagnostic to the program level: topic-level structure, purpose clarity, and measurability across your full content set. It takes 30 to 45 minutes and produces a clear picture of where to focus next.

---

# The Strategic Value of Management Information Architecture
> Management information architecture (also called back-end IA) models the structures that govern how content is created, stored, and published, and often depends on coordination with delivery IA and the content strategist.

The diagram below maps Garrett's five planes of user experience (surface, skeleton, structure, scope, strategy) onto three roles that share the work: the content strategist specifies vision at the abstract end, the management information architect tags and models content at the structure plane, and the delivery information architect presents and arranges it at the concrete end, closest to the reader.

![Diagram mapping Jesse James Garrett's five planes of user experience (surface, skeleton, structure, scope, strategy) to three roles: the Delivery Information Architect (present, arrange), the Management Information Architect (tag, model), and the Content Strategist (specify, define), arranged from concrete to abstract.](/blog/images/symbiotic-relationship-five-elements.png)

## Management vs. delivery information architecture: the dependency you can't skip

In [Garrett's five-plane model](https://www.jjg.net/elements/), management information architecture occupies the structure plane, between the scope decisions that content strategy makes and the skeleton and surface decisions that [delivery information architecture](/blog/strategic-value-delivery-ia/) translates into navigation and channel-specific experiences. Content strategy defines what should exist and why. Delivery information architecture designs how users find and consume it. **Management information architecture sits between them, designing the structures that govern how content is created, described, and stored**, so the delivery layer can express what the strategy specified.

![Diagram showing the relationship between the Content Strategist, Delivery Information Architect, and Management Information Architect, connected by Vision, Needs, Feasibility, and Enablement.](/blog/images/content-strategy-mgmt-ia-dev-ia-in-real-life.svg)

That structure lives at the content source, whatever form the source takes: XML under version control, components in a CCMS, structured fields in a headless CMS. From that source, management information architecture produces a content model every delivery channel can draw from, while still accounting for what each channel actually needs out of it. It's a superset of the needs of each unique delivery channel. The content model has to hold it all without forking into separate sources of truth, which is why a structured-content initiative starts here and not at the interface. **The source is what every downstream channel is limited by, so it is the first thing that has to be right.**

## The three structural artifacts of management information architecture

A content model defines what types of content exist (concept, task, reference, troubleshooting), what fields each type requires, and how types relate. It makes content structurally predictable: the difference between unstructured text in containers and structured content that systems can reason about and route. The model also has to define the rules for reuse, beyond just types: which units are approved for reuse, what is allowed to vary when they're reused (a product name swapped per audience, a warning included only for certain configurations), and who owns the canonical version when several teams all want to edit it.

A metadata schema specifies the attributes attached to each content unit: who it is for, what product version it applies to, what lifecycle stage it is in. That schema doesn't have to sit at just one level, either. Metadata on a whole topic routes the piece as a unit. Metadata on a single component inside it makes that fragment individually reusable and retrievable on its own. Metadata on an individual element gives a system something to key off of below the level a human would normally bother tagging. A schema full of optional fields that authors fill in inconsistently is **structurally identical to no schema at all**, at any of those levels.

A [controlled vocabulary](/blog/strategic-value-of-taxonomy/) governs the values that populate the schema (the taxonomy behind the metadata). Without it, a system searching for "installation requirements" misses content tagged as "setup prerequisites." Controlled vocabulary is what makes metadata **machine-resolvable rather than machine-readable**.

These three artifacts are interdependent. A change in any component propagates through the others, which is why management information architecture requires ongoing content governance, not a one-time setup task.

## The structure readiness matrix: a management information architecture example

To illustrate what management information architecture looks like in practice, consider the following audit across four downstream capabilities. This matrix maps each capability's requirement back to the structural artifact it depends on.

| Downstream Capability | What It Needs | Required Structural Artifact | Typical Audit Finding | Gap / Action Item |
| :--- | :--- | :--- | :--- | :--- |
| **Search** | Match a user's query terms to existing content regardless of phrasing. | Controlled vocabulary (`preferred_term`, `synonym_ring`) | Vocabulary maintained ad hoc by whoever last edited the page. | **Blocked:** Relevance tuning becomes a recurring manual fix. Vocabulary must be governed centrally. |
| **Personalization** | Assemble content at a granularity fine enough for a rule engine to select. | Content model (`content_type`, `component_boundary`) | Content authored as long-form documents, not addressable components. | **Blocked:** Segments can be identified but not served distinct content. Content must be remodeled into components. |
| **Localization** | Translate once per reusable component, not once per document. | Content model + reuse metadata (`reuse_id`) | Content duplicated per document instead of referenced from one source. | **Cost multiplier:** Every duplicate is a new translation job. Must model for reuse before the next locale rollout. |
| **AI Retrieval / RAG** | Give a retrieval system clean chunk boundaries and current-state signals. | Content model (`component_boundary`) + metadata schema (`lifecycle_state`) | Chunking follows arbitrary page breaks; no staleness flag exists. | **Strategic gap:** Retrieval can't distinguish current from deprecated content. Content model and lifecycle metadata must both be added. |

## Why weak content governance breaks search, personalization, localization, and AI

**No downstream capability can exceed what management information architecture provides at the structure plane.**

Search relies on consistent vocabulary to match what users ask to what content exists. Uncontrolled vocabulary makes relevance tuning a recurring manual fix, because the problem is upstream and no search platform can solve it.

Personalization requires content structured at a granularity fine enough to assemble selectively. Swisher and Preciado make the same point in [The Personalization Paradox](https://contentrules.com/the-personalization-paradox/): personalizing at scale requires standardizing the content first. Tooling can identify audience segments in unmodeled content but can't route them to components that were never designed to be addressed separately. The pipes work. The output doesn't.

Localization compounds the cost. Rockley and Cooper's [unified content strategy model](https://www.rockley.com/books/managing-enterprise-content) makes the mechanism explicit: a reusable component is translated once, at the source, and every reference inherits that translation automatically. Unreused content might start identical across five documents, but each copy drifts independently, and every edit triggers new translation and review, everywhere it appears. Translation memory can discount similar text; it can't make five drifting copies behave like one. That difference is structural: it only exists if the content was modeled for reuse from the start.

AI retrieval, especially retrieval-augmented generation (RAG), exposes this. Chunking traces back to the content model. Topics authored as addressable units retrieve cleanly; undifferentiated documents don't, whatever tags get added on top. The metadata layer doesn't fix that. Type and lifecycle metadata tell the system what it pulled and whether it's current. **Get the content model wrong, and no amount of metadata downstream fixes it.**

## The business case for management information architecture

When management information architecture is funded as deliberately as the interfaces built on top of it:

- Authors know what to write because the content model makes requirements explicit rather than optional.
- Metadata is consistent because the schema is enforced: two authors describing the same feature use the same terms without a human reconciling them after the fact.
- Components designed as reusable from the start mean localization happens once per component, and it never has to happen again per document.
- Search and AI retrieval both have genuine signals to reason about, instead of guessing at what the content means.

None of those outcomes are visible to a reader either. But they show up as support deflection, localization cost, search precision, and AI accuracy: numbers a business case can already measure. The question is whether the investment that produces them appears in the same budget.

## How to start a management information architecture audit

A [sample job description for this role](https://www.ditastrategies.com/library/sample-job-description-mia), written by Amber Swope, lays out what a management information architect is actually responsible for: developing the content model, defining taxonomy values with stakeholders, setting reuse rules and shared content, documenting guidance for authors, and coordinating with delivery counterparts on channel requirements and legacy conversion.

1. **Audit the content model.** Does a defined content model exist, specifying content types, required fields, and organization standards for each deliverable category, or is structure improvised per document?
2. **Audit the vocabulary.** Are taxonomy values and their relationships defined with stakeholders and enforced across the corpus, or does every author choose their own terms?
3. **Audit reuse.** Is there a real reuse strategy, covering approved shared content like boilerplate, warnings, and product names, plus the rules for how those units are allowed to vary, or is reuse ad hoc copy-paste?
4. **Audit author guidance.** Do authors have documented creation and reuse guidance, working samples, and the tooling they need to follow the model, or are they left to guess?
5. **Audit delivery coordination.** Is there a defined process for coordinating with delivery information architects on channel requirements and for converting legacy content into the model, or does every new channel and every migration start from scratch?

Those five checks map how much management information architecture actually exists, what is enforced versus assumed, and which of the duties in that job description have no one behind them. [Get in touch when the gap is larger than the current conversation can hold](https://calendly.com/intuitive-lief).

---

# The Strategic Value of Delivery Information Architecture
> Delivery information architecture (also called front-end IA) expresses the requirements for a specific channel’s user experience, and often depends on coordination with management IA and the content strategist.

**Delivery information architecture** is the high-level, consumer-facing structure of a site, app, or channel: how content is arranged and presented so a reader can find and act on it. Distinct from micro IA (individual page structure) and management IA (the authoring-side content model and taxonomy that delivery IA depends on).

![Diagram mapping Jesse James Garrett's five planes of user experience (surface, skeleton, structure, scope, strategy) to three roles: the Delivery Information Architect (present, arrange), the Management Information Architect (tag, model), and the Content Strategist (specify, define), arranged from concrete to abstract.](/blog/images/symbiotic-relationship-five-elements.png)

## Multichannel vs. cross-channel: what "omnichannel" actually requires

Each delivery channel has its own unique requirements. Across some channels there may be overlap or similar requirements, but what works for a web portal will be different than a watch, a refrigerator, or a chatbot. This requires that each channel have its own delivery information architecture. And you almost certainly have multiple channels. 

It is no longer uncommon to be using multiple devices simultaneously. You watch a Netflix movie using an app on your TV and simultaneously looking at your phone.

Resmini and Rosati make a related point in their work on [pervasive information architecture](https://www.sciencedirect.com/book/9780123820945/pervasive-information-architecture): design each channel on its own and you get several disconnected experiences. Design the whole set of channels a reader actually uses, and you get an experience that feels cohesive and thought-through.

Consider a reader who consults one topic on your portal on their laptop, searches for the related procedure on a mobile device, and uses voice commands with your in-app chatbot. Three distinct experiences. It's not so far fetched or uncommon.

Multichannel means the same content exists in multiple places. Cross-channel means it behaves as a coherent system across them. That is what "omnichannel" actually requires: not simultaneous presence everywhere, but a coherent system across every channel a reader touches. Resmini's five rules address the second problem, which is the harder one: placemaking, consistency, resilience, reduction, and correlation. Not one of those rules is satisfied by redesigning the primary channel's navigation. Each requires explicit decisions about how every channel expresses the same underlying structure. This is delivery information architecture.

## Delivery IA vs. management IA: the dependency you can't skip

Delivery information architecture is in service of your content strategy. And it can only deliver what's available in the source at the management layer.

For example, you want faceted search on your site. These filters will help your users to find what they're looking for. This requires [metadata facets to exist in the content](/blog/strategic-value-of-taxonomy/). **Delivery IA tells management what must exist in the source before the delivery architecture can work.** 

A content strategist sets the vision for what each delivery channel needs to be. They define the user experience. A delivery information architect knows the tools and technology for that channel. It's their responsibility to implement the content strategist's vision. 

![Diagram showing the relationship between the Content Strategist, Delivery Information Architect, and Management Information Architect, connected by Vision, Needs, Feasibility, and Enablement.](/blog/images/content-strategy-mgmt-ia-dev-ia-in-real-life.svg)

To implement the vision requires having requirements. Sometimes the vision is too big or grandiose for the budget or timeframe. Oftentimes the vision may require custom code. It's the delivery IA's duty to inform the content strategist what is technically possible and what it will take to implement the desired user experience.

Not only does the delivery IA need clear requirements from the content strategist, but they also need the source content to have the necessary structures and metadata to support the user experience. The delivery IA cannot invent information that doesn't exist at the source in the [management information architecture](/blog/strategic-value-management-ia/).

## The channel alignment matrix: an example

To illustrate what delivery information architecture looks like in practice, consider the following audit for a high-priority task: **Troubleshooting a Hardware Error.** This matrix maps specific channel requirements back to the source content model.

| Delivery Channel | User Task / Requirement | Required Source Attribute | Current Source Status (Audit) | Gap / Action Item |
| :--- | :--- | :--- | :--- | :--- |
| **Web Portal** | Filter by Product Version & Error Code. | `prod_version` (Metadata), `error_id` (Metadata) | 60% of legacy topics lack `error_id`. | **Blocked:** Faceted search will fail. Must batch-tag legacy content. |
| **Mobile App** | Quick-scan "Resolution" steps on a small screen. | `procedure_step` (Componentized content) | Content is currently in "Wall of Text" blobs. | **Required:** Refactor source into discrete `<step>` elements. |
| **In-App Help** | Surface "Related Specs" based on the current UI state. | `ui_context_ID` (Mapping attribute) | No mapping exists between UI and docs. | **Strategic Gap:** Need Management IA to add context IDs to the model. |
| **Chatbot/API** | Return only the "Error Description" string. | `short_description` (Semantic element) | Descriptions are inconsistent or missing. | **Content Debt:** Authors must rewrite short descriptions for 400 topics. |

## What working delivery IA looks like

When delivery information architecture is grounded in a sound management framework:

- A reader moving across portal, mobile, and in-app help encounters the same organizing logic on every surface.
- Faceted search returns meaningful results because the metadata behind it was designed to support those facets.
- In-app help surfaces [the right content type](/blog/content-delivery-gap/) because that type was modeled as a distinct, addressable component.
- A team building a new channel knows what the source structure must provide before the first wireframe is drawn.

None of those outcomes are visible to the reader, but they're noticed as "good user experience." And that's our goal.

## How to start a delivery IA audit

Do not start with a wireframe. Instead, build the structural requirements first:

1. **Inventory the channels and their unique tasks.** For each surface (portal, mobile, API), define exactly what the user needs to *do* and which content types are required for that action.
2. **Audit the source content for structural readiness.** Pick your most critical user task and use the **Channel Alignment Matrix** shown above to check if the current source structure (metadata, types, components) can actually fulfill the channel's design promise.
3. **Map the gaps to your roadmap.** Identify the missing metadata or un-modeled components. These gaps are your "technical debt" list for the Management IA and Content Strategist.

A content strategy baseline assessment maps both layers together. [Get in touch to start that conversation](https://calendly.com/intuitive-lief).
```

---

# The Strategic Value of Every Page Is Page One
> The information architecture principle of Every Page Is Page One is a strategic lever you should use to improve customer satisfaction and increase revenue. Seventy percent of B2B buyers say online content shapes their purchase decision before they ever talk to sales.

Whether you acknowledge it or not, your docs are helping sell your products. Your marketing may grab the attention, after all that's what it's supposed to do, but prospects view the technical documentation to confirm facts and check the veracity of your marketing. In other words, every page in your docs is selling.

If every page is selling, you need to treat them differently.

**Every Page Is Page One (EPPO)** is [Mark Baker's principle](https://everypageispageone.com) that content should be written so any page can be a reader's first point of entry: self-contained, explicitly scoped, and not dependent on the reader having already read anything else on your site.

## Why user manuals aren't read like books

Books, especially physical books that you can hold in your hand and feel the paper, are usually linear. You start at the front and read until the end. This applies to novels as well as technical and user manuals.

The internet changed that paradigm for user manuals. 

The thing about user manuals is that although all of the information in them is important, not all information is needed all at the same time. When changing the wiper blades on a car, you don't need to know the tire pressure, even though tire pressure is important to efficient, safe operation of the vehicle.

User manuals serve a purpose distinct from novels. Most people read technical documentation to find an answer to help them complete a task, troubleshoot an error, understand a concept, or verify a fact, not because the prose is compelling. 

## The pre-sales cost of a bad documentation page

Your product and docs are not your customers' primary interest. They have a job to do. If they must read your user assistance content, they want to get in and out fast.

Most readers don't begin at your homepage. They arrive somewhere deep inside your site, for any number of reasons, such as a search engine, bookmark, or emailed link. The first page a user lands on is, for that user, page one.

### From Documentation to Lead Conversion
We often view documentation as a post-sale cost center, but the data says otherwise. Seventy percent of B2B buyers say online content has a moderate-to-major effect on their purchasing decision, according to research cited by Patrick Bosek. [Heretto's 2024 self-service survey](https://www.heretto.com/self-service-report/) found that one in five organizations already treat prospective buyers, not customers, as their self-service platform's primary audience.

In this context, a documentation page is a sales touchpoint. What's more, if they're reading the documentation, they are deeper in the sales funnel. They are implicitly telling you that your product is of great interest to them, making them a much more valuable lead than a person perusing the marketing content. 

When a prospect cannot find a value-prop or a technical requirement because it's buried, your brand suffers. More effort is required to convert the prospect to a sale. 

For a growing product, [this pre-sales exposure is the stronger business case to make](/blog/strategic-value-user-assistance-content/).

## Solving for the 30-second reader

From a content design perspective that means we need to abandon the "Fantasy Reader"—the mythical user who starts at the beginning and systematically builds context. That person may exist, but they are the exception, not the rule.

Instead, we must design for the **Economic Reader**. This user has an "attention budget" of about 30 seconds if we're lucky. They arrive via search, a Slack link, or a chatbot citation. They bring only their immediate problem, and they need the page they land on to provide immediate value without prerequisite "debt." 

EPPO principles support this thinking, and the same discipline is what keeps your content usable when [an AI, not a human, is the one retrieving it](/blog/eppo-in-the-age-of-generative-ai/).

## A strategy for self-contained content

EPPO defines characteristics of a well-formed topic. If you're a content leader, you want your content seen as a strategic asset:

**Start with purpose, not structure.** A topic should be defined by a unit of human-scale work. Not a fragment of a procedure, but a complete, successful task.

**Establish context without requiring prior reading.** Every topic must locate itself. What product? What version? What role? A topic that starts with "Now that you have completed..." fails the Economic Reader.

**Link by subject affinity, not document hierarchy.** Traditional cross-references ("See Chapter 4") are dead-ends for search users. EPPO links ("This task depends on the permissions model") build wayfinding into the content itself, improving findability instead of forcing users to backtrack through a hierarchy they never read. That's the same findability failure that shows up as [an underfunded information architecture](/blog/strategic-value-information-architecture/): the shelves look fine, the structure underneath doesn't hold.

**Govern metadata as a revenue-driver.** Titles like "Configuration" are invisible to the market. Specific, accurate titles ensure the right content reaches the user at the moment of evaluation or need.

## The ROI of Every Page Is Page One

Organizations that embrace EPPO see measurable outcomes: support ticket deflection, accelerated onboarding, and higher lead conversion from documentation portals. 

Documentation stops being an invisible cost and becomes a strategic differentiator. When your content works for the user arriving at "Page One," it works for the business.

---

If you want to understand where your current content stands against these principles, the most direct first step is a conversation about what you have and where the gaps are. [Schedule a call](https://calendly.com/intuitive-lief/discovery-initial-consultation) to work through the distance between where your documentation is and where it needs to be.

---

# Ctrl+F Means You Fail
> When readers press Ctrl+F on your content pages, they are not using typical search. They are hope-searching: scanning for an exact word and hoping it appears. Unlike a typical search engine, there is no synonym matching. That behavior is worth noticing. It usually points to a structure problem, not a writing problem.

When readers press Ctrl+F on your content page, they have already given up on your structure. **The string is either on the page or it is not.**

For some readers, that is a shortcut. For others, it is the moment they give up on finding an answer.

Of course, understanding which is which requires distinguishing between three things that look identical from the outside.

## Why readers use Ctrl+F instead of your navigation

A developer scanning an API reference for a specific parameter uses Ctrl+F to save time. They know the content is there and want a shortcut to jump down the page. A returning visitor does the same. Both are a sign that your page has value to them.

Then there is the reader who arrived expecting your content to deliver an answer, typed a word into the find bar, and hoped it appeared somewhere on the page. No fallback. No second attempt at a different term. Just a direct question: is this here? **The problem belongs to the page, not the reader.**

## What makes readers give up and search instead

Three things send a reader to the Ctrl+F bar.

**The page covers too much.** When a reader arrives with one specific question and has to wade through a topic that also covers four other things, the page is doing too much. (Naturally, the topic that generates the longest Ctrl+F sessions is usually the one where several distinct questions share a page because they share a category.) [How big a topic should be](/blog/how-big-is-a-topic/) is the practical question to ask before that happens.

**The page leaves the reader without context.** If a reader arrived by following a link, landing from search, or opening a shared URL, they may reach for Ctrl+F not because the page is too large, but because it opened without the context they needed to make sense of it. Session recordings often show this: rapid scroll-to-bottom followed by a Ctrl+F attempt. The reader is scanning for entry points the page did not provide. The [Every Page Is Page One](/blog/strategic-value-every-page-is-page-one/) principle is built on exactly this observation: a page that cannot be understood without having read something else first has already lost any reader who arrived cold.

**The reader is on the wrong page.** Sometimes the content is right for someone, just not for the person who landed on it. That is a metadata and linking problem. Something upstream sent them there. A navigation label, a search result, a cross-reference. The search term is what tells you which of these three problems you are actually looking at.

## What a failed Ctrl+F search costs you

When a reader hope-searches and comes up empty, the session ends one of two ways: they leave, or they find a phone number or a chat widget.

(Hint: These tend not to be your least capable readers. Google search researcher Dan Russell found in 2011 that around 90% of US internet users don't know how to search a page for a specific string by any method other than scanning it visually. Today, in a mobile-first world, that shortcut is an even rarer "power user" move. If your most tech-savvy, persistent readers, the ones actually using desktop shortcuts, can't find what they need on your page, your mobile users (who don't even have a Ctrl+F key) were gone five minutes ago.)

**Exits mean unresolved questions.** Depending on the context, that is a support ticket that was not deflected, a purchase was not made, or a task that was not completed. Most organizations can calculate the cost of a support ticket. How many of those came from a content structure problem is harder to know. Standard analytics will not tell you.

## How to track Ctrl+F behavior in your analytics

Standard analytics will not surface Ctrl+F behavior on their own; GA4 has no built-in event for it. Session recording tools like Hotjar and FullStory are generally the better window here: a page-level script can often catch the keypress itself, since it fires before the browser opens its native find bar. What you likely won't get without extra setup is the search term, since that gets typed into the browser's own find UI, not anything on the page. (To capture the specific terms readers type, you will need a custom script listening for that keystroke and passing it to your analytics tool.)

So what are you actually looking for?

- **Which pages** trigger Ctrl+F most often. Start there.
- **What terms** readers type. Terms that are not on the page at all tell you something is missing. Terms that appear but are buried deep suggest a scope problem.
- **Whether they find it.** A find bar that closes quickly after the first match usually means success. One that stays open, cycles through multiple matches, or is followed immediately by a back-navigation means the page either does not contain what they needed or contains it in a form they did not recognize.
- **What happens after.** A reader who finds their answer and keeps reading is fine. A reader who exits is not.

**High Ctrl+F frequency combined with short sessions and exits is the clearest pattern that a page has a structural problem.** The search terms tell you which one.

## How to audit your pages for Ctrl+F failures

Pull your Hotjar or FullStory recordings (if you have them) for your five highest-traffic support or documentation pages. Look for Ctrl+F sessions. Note the search terms. Map them back to your page structure.

**You are probably not looking at a writing problem.** You are looking at a scope problem, a context problem, or a linking problem. All three are fixable. None of them requires rewriting everything from scratch.

And if you are not currently running session recording on your content pages, that is the first step. **You cannot fix what you cannot see.** The data is there to collect; it just requires a tool that operates at the browser level rather than the server level.

What are your pages actually making your readers search for?

---

# Your Experts Need Your Deepest Documentation
> Novice users need short, structured content they can act on immediately. Expert users need depth, reference detail, and edge cases. Here’s the five-level pattern behind that split and how to design for it.

I recently started a new hobby: disc golf. On its face it seems fairly simple. Throw a frisbee (disc) into a basket. At first I had typical beginner problems. As a right-hand player who throws backhand, my frisbees would fly up and crash out to the left. To fix this I had to correct a number of issues, introducing me to an overwhelming amount of new vocabulary: hyzer, anhyzer, stable, overstable, understable, forehand, sidearm, launch angle, nose angle, x-step, power pocket, turn, fade, overpowered, hit point, arming the disc, and more. 

As a beginner, it was too much and confusing. I just want to throw straight, ideally as far as possible. I don't really want to understand the physics of how a wing (the disc) creates lift as it moves through air. I didn't really need to know that a tailwind will push a disc to the ground faster.

And yet, so many explanations of how to throw far go into the minutiae of your footwork, coil, wrist position, or, yes, wind direction. There is a 90-minute video on YouTube explaining the [aerodynamics of disc flight](https://www.youtube.com/watch?v=-0JKHuzJ67A). But it's not what a beginner needs. (It's excellent, by the way.)

Documentation teams naturally want to cover everything: anticipate every question, explain every term, walk through every step. The impulse is common. It's also, quite often, wrong. **Novice users need structure, not volume.** They need short, self-contained bites they can act on right now, not detailed guides they're not yet equipped to use. Meanwhile, your power users are the ones who actually benefit from depth or the minutiae. 


## Documentation needs by experience level

User experience runs along a continuum: novice, intermediate, advanced, practitioner, and expert. Each level brings distinct cognitive characteristics and, as a result, distinct documentation needs. (Skill-acquisition researchers Hubert and Stuart Dreyfus mapped something functionally identical in their five-stage model of adult skill acquisition. The same pattern shows up wherever people move from following rules to working on instinct or from muscle memory.)

When I started disc golf, the rule that mattered wasn't about lift or spin rate. It was "keep the disc flat on release." That's all I needed: one clear instruction. An expert — a power user — operates intuitively. They've internalized so many patterns that what to do next is obvious. Power users even have different approaches to achieve the same result.

These groups need fundamentally different documentation:

| Level | Content that serves them |
|---|---|
| **Novice** | Step-by-step procedures, no assumed context, explicit rules |
| **Intermediate** | Rules plus situational examples, recognizable patterns |
| **Advanced** | Goals, decision tables, conceptual overviews |
| **Practitioner** | Pattern-level guidance, cases and anti-patterns |
| **Expert** | Quick-reference lookups, edge cases, exceptions; full context assumed |

Completeness means different things at each level. For a novice, it means "don't make me think, tell me what to do." For an expert, it's the nuances or in-the-weeds details that provide even greater context. The same document cannot serve both well. Of course, in practice, you're often designing for a population that spans multiple levels, which is where the architecture decisions become consequential.

So what does this mean for how you structure a documentation set? It means **you can't optimize for one level without creating problems for another.**

## Macro content vs. micro content by experience level

**Content volume runs in opposite directions depending on which type you're writing.**

![Content volume by user experience level: macro content needs grow toward expert, micro content needs grow toward novice](/blog/images/who-needs-macro-micro-content.png)

*Macro content grows with expertise. Micro content shrinks with it — the same five levels this piece uses throughout.*

## The documentation minimalism debate

As documentarians, we have wrestled with this question for decades. John M. Carroll published *The Nurnberg Funnel* in 1990, showing short, task-focused documentation outperformed the detailed manuals of the era. Users with 'just enough' documentation completed tasks faster and made fewer mistakes.

Experts need detailed reference material, conceptual explanations, or to look up edge cases. Optimizing for novices doesn't serve them. In fact, it actively frustrates them: step-by-step instructions of things they already know gets in the way of the information they actually came for.

This brings us to topic-based authoring: Concept topics for the advanced-to-expert user who needs to understand *why*, task topics for the novice-to-intermediate user who needs to know *how*, and reference topics for the expert who needs the quick lookup. (DITA formalized this as its three core topic types, and the logic holds regardless of whether you're working in DITA or not.) Or perhaps you subscribe to the [Diataxis framework](https://diataxis.fr/) that uses a different but similar approach with tutorials, how-to guides, explanation, and reference. Both approaches provide an architecture for combining content types.

Like disc golf professionals discussing where they put thumb pressure on the disc, there are multiple approaches to reaching the same outcome. DITA and Diataxis are the equivalent of different grips on the same throw: **split content by what the reader needs to do with it, not by how much they already know going in.**

## Vocabulary by experience level

Novice users also have a different vocabulary from experts, and this affects more than writing level. UX practitioner Harry Court, [writing about a redesign for a local government website](https://harrycourt.medium.com/designing-for-an-audience-with-a-diverse-level-of-expertise-a7f036c078c8), observed that experts shift to more specific, domain-level terms when naming things. A building professional calls it a "DA" rather than "permission to build." Naturally, both groups are searching for the same information using different words. This difference is more pronounced with medical and health writing, where the vocabulary is drastically different between the trained and the layperson.

The solution from Mr. Court's project: **reserve titles for novice vocabulary and descriptions for expert vocabulary.** Page titles used accessible, everyday language. Descriptions surfaced the technical terms practitioners rely on. Both audiences could find what they needed without either group having to translate across the other's language first. (Hint: search logs supported this — expert-specific terms like "DA" and "CDC" appeared consistently in query data, which was what led the team to put them in descriptions rather than ignoring them altogether.)

This kind of design requires knowing how your novices actually talk about their tasks. That knowledge comes from user research.

## Macro content for expert users

At the expert end of the spectrum, brevity starts working against you. A power user has spent years accumulating domain knowledge. They can absorb information quickly. What they're looking for is the specific fact they don't yet have: a parameter range, a behavior exception, an example of the anti-pattern they've been warned about.

The implication for information architecture is that **deep reference material is not overhead.** It's the content your most skilled users depend on most. It should be well-structured and indexed for fast scanning.

Release notes are an example of content for experts. They contain the what's changed and what's new details. For novices everthing is new, so they don't care about what's changed. For the advanced users for whom change has a big impact, release notes are core content.

## Exceptions to the experience-level pattern

Some novice users do need depth. Safety-critical tasks, complex system configurations, and situations where action-first learning carries real risk all require detailed procedural information regardless of who is performing the task. And some experts, particularly when moving into an adjacent domain, benefit from the same short, structured entry points that serve beginners well.

A power user's fluency comes from repetition. Think of an app you know well, perhaps the one you use the most on your phone. You're a power user. You know exactly where to tap. How do you feel when the user interface (inevitably) is 'improved'? It throws you for a loop until you relearn the UI. 

Product teams get this wrong constantly when developing new features. They equate power users with one feature to mean they're a power user in all features. **A user who has never seen the new feature cannot be considered an expert in it.** Because of previous experience or context, they may not be a novice, but they cannot be considered an expert in something they've never seen. 

This has an implication for [how new features should be introduced](/blog/strategic-value-user-assistance-content/).

## Auditing your documentation by experience level

This five-level range gives you a practical lens for reviewing your current documentation. Pick a set you suspect isn't working well for one segment of your audience. Identify where most of your users sit on the novice-to-expert range. Then ask whether the content was designed for that level or for a different one.

If your user population skews expert and your documentation reads like a novice tutorial, that's a structural mismatch. If your users are novices and your documentation assumes knowledge they don't yet have, that's a different mismatch with different consequences. **Both are fixable. But not with the same solution.**

Use these questions to start:

1. What percentage of your users are performing this task for the first time versus the hundredth time?
2. Does your content assume knowledge that novice users won't have?
3. Is the edge-case and exception detail your experts need present and findable — or buried, missing, or only available through support channels?

The answers will tell you where the mismatch is and which direction to move. For more on designing the structured, self-contained content units that serve novice users well, see the [strategic value of micro content](/blog/strategic-value-of-microcontent/).

---

# The Strategic Value of User Assistance Content
> The business case for user assistance content depends on where your product sits in its lifecycle. Growing products need to accelerate revenue. Mature products need to protect margin. Most content teams are making the wrong case to the wrong person.

The business case for user assistance content has been made the same way for a long time. You pull the support ticket data, isolate the how-do-I-configure-this and where-is-that-setting requests, and estimate how many your docs should have answered before they became tickets. Multiply by agent cost. The sum is usually compelling. **But is it the right question for you?**

That scenario makes a fundamental assumption: **the value of user assistance content is solely about customer support.** That might be true for you, but depending on your product, it might be just half the picture. To an executive looking to spur growth and interest in a new product, reducing support costs is not the number one priority. To a leader of a mature product looking to hold margins steady, it could be the right calculation.

Your product’s stage of maturity should shape [the case you make for its user assistance content](/blog/what-do-you-need-your-content-to-do/). Early-stage products need one kind of value story; mature products need another.

This is a product-by-product analysis, not a company-wide one. A single company usually has several products, each sitting in a different phase of its lifecycle at the same time, and each needs its own business case made separately. You can take the lens down even further: a new feature inside an otherwise mature product behaves like a young product of its own, and the same growth-versus-deflection logic applies to it.

![Product maturity cycle diagram showing four stages: Introduction (launch to market), Growth (adoption accelerates), Mature (growth flattens), and Decline (demand fades).](/blog/images/product-maturity-cycle.svg)

## Pre-sales value vs. support deflection: the two business cases

For a product that is **new or actively growing**, adding customers and competing for market share, **support deflection is not where the attention should go.** The primary audience for your technical writing is not the established customer with a configuration question. It's people looking to make a purchasing decision, and [technical documentation serves that decision as much as it reduces support calls](/blog/strategic-value-every-page-is-page-one/).

Twenty to thirty percent of all visitor sessions in technical writing occur before purchase (Heretto 2024; Zoomin 2024). These are prospective buyers. **Technical documentation is the second most-interacted-with element of a product, right behind the product interface itself,** and over 50% of B2B technical evaluations involve documentation before a deal closes (Iantosca 2025). Where's the value now?

![The same product maturity cycle with the business case mapped onto it: technical documentation accelerating revenue for growing products during Introduction and Growth, then supporting case deflection and protecting margins for established products during Mature and Decline.](/blog/images/product-maturity-cycle-with-captions.svg)

For a **mature product with an established customer base**, **support deflection is the dominant value lever and the deflection argument is the right one.** Your user assistance audience is overwhelmingly existing customers who need to do and understand things they've already purchased. 

Gartner found that even among issues customers describe as “very simple,” only 36% are fully resolved through self-service (Gartner 2024). That means roughly two-thirds of straightforward information requests still become tickets, and with good-to-excellent user assistance, that should change. Zoomin (2024) showed organizations reaching **58% case deflection.** 

If you have a mature product and are not deflecting that percentage of support calls with your technical documentation, you have a significant opportunity. When the fully-loaded cost of a support agent in North America runs between $50 and $80 per hour, [the math should be compelling](/blog/content-delivery-gap/) to start a conversation with the VP of Support or Customer Success. 

## Time to value and feature adoption: the growth-stage case

For a product in growth mode, in addition to the pre-sales research, technical writing supports two more value contexts, each connected to a different stakeholder who cares about a different metric.

**Time to value**. If your business is SaaS or any product where you cannot recognize revenue until the customer is actively using the product, you care deeply about getting them onboarded…fast. Poor onboarding content produces longer deployments, higher services dependency, and the need for expensive hand-holding and white glove service. [You need your content to get new customers to up and running quickly](/blog/strategic-value-saas-onboarding-ia/). The Customer Success manager cares deeply about how your content helps the customer and the team perform. **Are you producing the right content?**

**Feature adoption and stickiness**. People use features they know about and will solve a problem them have. They renew and upgrade when those features make their life easier. User assistance content is not just long-form docs. It's the microcontent too. When a capability that could drive upsell revenue goes undiscovered because users cannot find or understand it, that gap produces a measurable signal in feature adoption rates and expansion conversations that never happen. Product Management cares about feature adoption and microcontent. **Have you tracked the correlation between feature descriptions and activation?**

## Building the right business case as your product matures

This doesn't mean support deflection stops mattering for a growing product, especially if your portfolio also has established products. It means **the business case should be built from wherever the highest unrealized value sits,** and that location shifts as the product ages.

Use support deflection as the business case for a young product, and leadership will tune out. They know they'll get more long-term by selling five more licenses than deflecting five support calls. The levers that matter shift as the product matures. So should the conversation you bring to leadership.

---

# What Do You Need Your Content to Do?
> Most documentation teams are measured on output, not business outcomes. Your technical writers are looking to you to answer one question. Can you?

When executives can't articulate what they need content to accomplish, there's no documentation strategy, just
individual contributors optimizing to how they're measured and their paycheck: topics written and tickets closed.

![Technical Writers Asking For Clear Direction](/blog/images/what-do-you-need-your-content-to-do.png)

## Why documentation teams optimize for the wrong metrics

Revenue is the number one priority that drives decisions for business leaders. For technical documentation teams, it
ranks dead last. What is that?

It happens because the writers don't know what business value they were supposed to produce with their content.
And when that direction is missing, writers do exactly what you'd expect: they optimize for what gets measured. Number
of closed tickets or pages written or their sprint velocity. If they do that well, they'll get their
bonus. It is not a failure of the writers. **Nobody can clearly articulate “What do you need your content to do?”**

So the content gets thrown over the wall. Everyone moves on to the next task. 

## Self-service documentation and buyer behavior

Writers see their own work as post-sales content. That view needs to change, for writers and leadership alike. This doesn't mean documentation should look like marketing pages. Just the opposite: buyers trust documentation because it's perceived to be free of sales intent.

Your documentation gets the first, unmediated shot at every skeptical buyer.

In software specifically, [67% of buyers' first meaningful product interaction is self-service](https://heretto.com) (help portals, knowledge bases, documentation sites) before making a buying decision. Twenty percent of those sessions are prospective buyers doing pre-purchase technical due diligence.

When your content fails to answer “can this product do what I need it to do?”, the prospect takes longer to decide or abandons and goes to a competitor.

Every year at planning time, budget reviews don't ask what you produced. They care about ROI: what it was worth. Does the output justify the headcount? Eventually you're the one hearing the question every manager dreads, like in Office Space: “*What would you say you do here?*”

## Four steps to improve documentation ROI

Executives want to increase revenue, brand loyalty, and scope. These improve the business's market attractiveness. On the expense side, competitiveness improves by managing risk and increasing efficiency. Both paths lead to the same place: profit. These are how business leaders choose to invest.

![Content Strategy Business Case for Documentation ROI](/blog/images/content-strategy-business-case-plus-stats.png)

Every documentation task should trace to at least one before writing starts.

You need to know whether the content serves growth, reduces support costs, or both. That's the 
[strategic value of content](/blog/strategic-value-user-assistance-content/).

Before the next planning cycle, get these four things right in your technical documentation strategy.

**Identify the business goal the content is supposed to serve.** Be specific. “We have to have it” is not a business goal. “This onboarding guide reduces time-to-first-value for new users, because time-to-first-value correlates with 90-day retention” is.

**Define how you'll measure documentation success before the work starts, not after.** Meghan Casey's _Content Strategy Toolkit_
has a MadLibs-style exercise for this:

```
Our content will help [audience] accomplish [goal] by providing [content type] that 
[differentiator]. We will know we've succeeded when [measurable outcome].
``` 

Have your stakeholders complete it for each project. If they fill in different words, excellent. That disagreement is the point. It surfaces misalignment that would otherwise show up months later. 

**Metrics vs. KPIs.** Metrics are raw measurements: page views, session counts, topics published. They're useful as inputs, not decisions. A KPI is different: it has a threshold, triggers a decision, and is calibrated for the stakeholder who has to act on it. So different teams have different documentation KPIs. The KPI for a VP of Support might be deflection rate and net savings; page views tell that executive nothing actionable. The right KPI for a VP of Sales isn't the same as for a compliance officer or a localization manager. A single dashboard serves no one well.

**Give writers a story, not just a backlog.** After the business goal and success criteria are set, tell writers what the work is actually for. Let them see the connection to business outcomes and how their work matters elsewhere in the business.