The ghost of content past: A writing carol

December 14, 2025 · 6 min read

Senior Technical Editor

Welcome to my article series on technical writing! After 30 years in the profession, I’ve seen the field evolve in many ways. Over that time, I’ve learned some lessons (and made plenty of mistakes) that shaped how I work.

In this series, I share practical strategies that I hope you’ll find helpful. Feel free to adapt them to your own writing process. 🙂

When content comes back to haunt you

I’ve created a lot of content during my career and revisited much of it as software and requirements evolved. To be honest, I’ve had more “Why on earth did I do it like this?!” moments than I can count. And if there’s one thing I’ve learned, it’s that content can always be improved, and a little planning now saves a lot of extra work later. Also, coffee will always be there for me (but I digress).

With the festive season approaching, I found myself in the mood to put together a little “Writing Carol”, a set of tips to help you avoid future content hauntings.

If you don’t tag as you go, your work doubles

Tag or format as you go. If you leave it for later, it will take you twice as long. Sure, you could postpone it until proofreading. But if you’re anything like me, untagged or incorrectly tagged content pulls your attention away from the flow, and you end up overlooking things. And once the deadline approaches, you simply won’t have the time to clean things up.

If it feels too complex, it is too complex

If you’re writing content and catch yourself thinking, “That’s a lot of conditions!”, take that as a sign. An overly complex setup might work today, but it can easily turn into a maintenance nightmare. I once set up so many conditions in a topic that one of the outputs ended up with no content at all.

The same goes for overly nested steps. If you, as the writer, are having trouble following the navigation path you’re documenting, your readers will definitely get lost. Try stepping back and considering a different approach. Instead of a single topic full of conditions, split it into two and use fewer conditions in each.

Break down complex, nested tasks into smaller subtasks. For example, instead of one topic with many steps, substeps, and optional paths, create two topics with clearer, simpler flows. It’s always easier to fix these structural issues while you still have the full picture in your head.

If content lives in three places, you’ll miss one

Assume that your content will change (it always does). And when it does, scattered information will cause you trouble (trust me). Definitions you copy from one topic to the next will start to drift apart when the first update comes along. You update two of them and overlook the third.

The same goes for variables, file paths, shared steps, and the like. Try to centralize this type of information whenever possible. Create one leading topic and link to it from the others, or treat it as a kind of content master, the one source that you always update first. That way, inconsistencies won’t quietly slip in over time. As a bonus, reusing content becomes much easier. When content is structured around central pieces instead of duplicated snippets, creating new topics or adjusting old ones becomes way easier.

If you start too many threads, you’ll leave loose ends

When bigger updates roll in, they rarely affect just one topic. You jump between three, five, or ten areas of your documentation. And that’s where things get messy fast. If you try to update everything at once, you lose track of what you’ve already changed, and loose ends start piling up. Instead, try creating a small “to-be-changed” list and decide what to tackle first. Begin with the must-haves, then move to the nice-to-haves. That way, if one update unexpectedly turns into a rabbit hole (I’m told that can happen), you won’t risk a deadline. Instead, you can push the optional parts into your backlog for a future round of updates.

This approach also protects you from half-baked content (fragments of an example, half a procedure, a dangling note). Months later, you won’t remember what you originally meant, and finishing takes twice the effort.

If a change seems small, chances are, it isn’t

When a ticket comes in, it’s completely natural to focus on the one topic it mentions. But in practice, content often doesn’t live in just one place. A term, parameter, or small detail can appear in other areas of your documentation (sometimes in places you wouldn’t expect). So before you start editing, take a moment to run a global search for your key terms. You may find a few side references or small dependencies worth adjusting along the way. It’s a simple habit, but it helps keep your content aligned and saves you from follow-up tickets.

If you don’t set rules, content will drift apart

Consistency doesn’t happen by accident. A style guide (even a lightweight one) reduces second-guessing for your future self. Also, document your decisions. A short note on why you chose a certain term, structured a process a specific way, or left something out entirely can save a lot of time.

Use clear naming conventions and a predictable folder structure. Most tools offer features that help you keep things tidy, but they only work if your content follows a structure in the first place. Setting a few rules now means you won’t have to remember whether to use dialog or window, drop-down list or list, or how to name the graphic you are currently creating. You can simply look it up.

Thanks for reading! I hope that with these methods, you can avoid hauntings of past content. For those interested in exploring further, I’ve compiled a list of related resources from the technical writing community, which I hope you’ll enjoy.