I’ve been doing this long enough to have a pet theory about technical writers. We are, almost universally, extremely good at understanding the user in front of us — the person using our software right now, hitting the error message we wrote, trying to follow the procedure we structured. We develop sharp instincts about what that person needs at that moment. What we are less naturally good at is thinking about that person’s entire journey: where they came from, what they already know, what they’ll need three steps after the thing we just documented, and what the content landscape around them looks like.
Chapters 12 through 24 of Paula Land’s Content Audits and Inventories have been sitting with me for a few days now, and the idea I keep returning to — the one that feels most alive and most useful for where I want to take my career — is the customer journey map combined with gap analysis. On the surface, this seems like a marketing tool. A UX artifact. Something that lives in a product roadmap presentation or a strategy deck, not in the documentation repository where I spend most of my time. But the more I’ve thought about it, the more I think that framing has been limiting me, and probably limiting a lot of technical writers who haven’t made this particular conceptual connection yet.
What a Journey Map Actually Does
Land’s chapter on personas and customer journeys (chapter 24) describes the journey map as a way to capture the step-by-step experience of a user as they move through all the touchpoints of a content ecosystem — not just a single page or a single doc set, but everything from the moment they first encounter a problem through the moment they feel genuinely supported and capable. She’s explicit that this is a content strategy tool, not just a UX design tool: the map documents what content exists at each step, what the user needs to know or feel to take the next step, and — crucially — where those two things don’t match.
That last part is the gap analysis, and it’s what makes the whole exercise matter. You can build beautiful journey maps that communicate nothing actionable. The gap analysis is what turns the map into a work order. It answers the question: given what we know about where users are and what they need, what content is missing, misplaced, or just wrong?
Technical writers do a version of this informally every time we sit down to plan a new doc set. We think about what users know coming in, what they need to learn, and in what order. But we usually do it for a narrow slice of the experience — the installation, the API reference, the troubleshooting guide — without systematically connecting it to everything else a user might encounter before they opened our doc or after they closed it. The journey map makes that wider context explicit and gives you a framework for identifying where your documentation is leaving users stranded.
The Documentation Desert
Here’s a pattern I’ve seen more than once in documentation projects: a product has thorough reference material and decent tutorials for getting started, but almost nothing at the middle stages — the awkward stretch between “I got it installed” and “I actually understand how to use this effectively in my specific situation.” Users fall into this gap constantly. They exhaust the getting-started content, find the reference docs too abstract to apply without more context, and end up either on a forum, on a support ticket, or quietly giving up.
This is a gap analysis result. But without a journey map to make it visible, it tends to get diagnosed as a resource problem (“we just need more content”) rather than a structural problem (“we’re missing a specific type of content at a specific stage of the user journey”). Those diagnoses lead to very different solutions. The first leads to more of what you already have. The second leads to identifying exactly what’s needed and where it needs to live.
Land frames this precisely in the gap analysis appendix, showing how content can be mapped to audience and journey stage to reveal not just what’s missing but who it’s missing for. An IT professional evaluating a product for purchase needs different content at the awareness stage than a developer who’s already committed and is now trying to implement. A new user who’s uncertain and cautious needs different support at the learning stage than an expert who wants to move fast and just needs accurate reference material nearby.
Technical writers tend to write for a composite user — a kind of averaged person who is neither completely novice nor fully expert. The persona-driven journey map forces you to split that composite into real, distinct audience segments and ask honestly whether your documentation serves each of them, at each stage. In my experience, it usually doesn’t serve all of them equally well. And knowing which segment you’re underserving, and at which point in their journey, is actionable in a way that a general sense of “the docs could be better” simply isn’t.
Accessibility and Global Content Are Gap Analysis Problems Too
Something I appreciated about this section of the book is how Land’s chapters on accessibility (chapter 19) and global content (chapter 22) slot naturally into the gap analysis framework, even though they’re typically treated as separate concerns.
The accessibility chapter covers the familiar checklist — alt text, heading hierarchy, link text, transcripts for audio and video, plain language, reading order. For technical writers, most of this should already be part of standard practice, and yet it rarely is. Alt text on documentation screenshots is often perfunctory or absent. Heading structure in long procedures frequently skips levels in ways that break screen reader navigation. Complex error messages are written for people who already understand the system well enough not to need the message.
When you frame these as gap analysis findings rather than compliance checkboxes, they become more urgent and more meaningful. A user relying on assistive technology who hits a documentation page with no alt text on a critical diagram isn’t just experiencing a technical failure — they’re hitting a content gap. The information they need exists; the pathway to it is blocked. That’s the same structural problem as any other gap, just with higher stakes for a specific segment of your audience.
The global content chapter made me think about a dimension of documentation I don’t engage with often enough. Land’s point about localization-readiness — using clear sentence structures, avoiding idioms, spelling out acronyms, not embedding text in images — is ostensibly about preparing content for translation. But every one of those practices also makes documentation better for non-native English speakers who are reading it in English, which is a substantial portion of many technical audiences. Writing for localization and writing for clarity are, to a significant degree, the same project.
What This Changes About How I Think About My Role
I’ve spent a lot of my career thinking about my job as producing documents. Good ones, hopefully — accurate, clear, well-structured, appropriately scoped. But still: documents as the output, documents as the thing I’m responsible for.
The journey map reframes that. In the journey map view, documents aren’t the output — supported users are the output. The document is infrastructure. It’s one node in a network of content that either successfully moves a user from where they are to where they need to be, or fails to do that and leaves them stuck. My responsibility isn’t the document in isolation; it’s the user’s experience at the moment when they need my document, which means I need to understand what came before that moment and what comes after it.
“Personas tell you what the priority is and how deep to go. Some customers are worth 80% of your time, some are worth 20%. Apply that metric to how much time you spend on the audit.”— Paula Ladenburg Land, Content Audits and Inventories, 2nd ed.
This is a useful corrective to a trap technical writers fall into: we can spend enormous amounts of energy perfecting content that isn’t actually the bottleneck for users. A beautifully written and carefully structured reference page for a feature that confuses users at the conceptual level before they even reach the reference docs doesn’t solve the problem. The gap is upstream — in the conceptual documentation, or in the onboarding flow, or in the product design — and until someone maps the full journey and identifies where users are actually getting lost, the reference docs keep getting polished while the real problem goes unaddressed.
Where I Want to Take This
Reading these chapters in the context of an actual content audit I’m preparing for has made me want to push my own practice further than I usually do. Specifically, I want to build a real customer journey map for the documentation ecosystem I’ll be auditing — not a theoretical exercise, but a working artifact that maps the product’s actual user segments to their actual content needs at each stage of their journey with the product.
That kind of artifact doesn’t traditionally come from the documentation team. It comes from UX, or product, or marketing. But there’s no reason it can’t come from — or be heavily shaped by — a technical writer who understands the product deeply and has spent real time thinking about how users learn it. And producing that kind of artifact changes the conversation. It makes visible things that were invisible: the places where users are expected to make a leap without any content to help them, the documentation that exists but sits in the wrong part of the journey to actually help, the audience segments that are well-served and those that are essentially on their own.
That’s the kind of work that earns a seat at the table in product and strategy conversations. Not just “the docs are done” but “here is a structured analysis of how our content ecosystem is or isn’t serving our users across their entire experience, and here is what we should build next.” Technical writers have the raw materials for that analysis. The content audit framework — especially the persona and journey mapping chapter — gives us the tools to turn those materials into something that can drive real decisions.
I’m still working through what that looks like in practice for this particular project. But I’m clearer than I was a week ago about what I’m aiming for. That feels like progress.