Introduction to Structured Writing

There were words on the page, but the page lacked the information needed.

I did not realise this immediately. I had come from creative writing, where the world you build is entirely your own. You invent the characters, the rules, the logic. If a detail does not exist, you create it. Research, when it happens at all, serves the story you have already decided to tell.

So when I was commissioned to write a review for a product I had never used, I approached it the same way. I gathered what I could from the surface, found the right words, and arranged them into something that looked like documentation. It read well. The grammar was clean. The structure was there.

But I had documented a product I did not fully understand. And that meant every reader who followed my words was walking a path I had not actually walked myself. I was not guiding them through the product. I was leading them toward a dead end, confidently.

The moment I understood this was the moment I understood the difference between creative writing and technical writing. In creative writing, you build the world. In technical writing, you step into a world that already exists, fully formed, with rules you did not make and details that are not yours to invent. Every assumption you bring with you is a risk your audience will pay for.

This is where structured writing begins. Not with a template. Not with a style guide. It begins with the discipline of understanding before you document.

What Structured Writing Actually Is

Most people hear “structured writing” and think about formatting. Headings, bullet points, numbered lists, style guides. And while those things matter, they are not structure. They are the surface of structure. Confusing the two is like mistaking a painted wall for the foundation of a house.

Structured writing is the discipline of organising information before you organise words. It is the decision, made before you open a blank document, about what your reader needs to know, in what order, and why. It is the understanding that documentation is not writing about a product: it is building a path through it.

This distinction matters because most documentation problems are not writing problems. They are thinking problems. When a user gets lost in a help article, it is rarely because the sentences were unclear. It is because the person who wrote it had not fully mapped the territory before drawing the map. And the reason they had not mapped the territory is because they started with words instead of understanding.

Technical writing carries a responsibility that most other forms of writing do not. When someone reads a novel and misunderstands a scene, they lose a moment of pleasure. When someone reads a technical document and misunderstands a step, they lose time, money, or trust in the product entirely. The stakes are different. Which means the preparation has to be different.

Because assumption means you are documenting what you think is true rather than what is true. And in technical writing, the gap between those two things is where your audience gets lost.

The Shift: Sentience vs. System

The Three Stages Before You Write

Structured writing is not a single action. It is a sequence. And that sequence begins long before you open a document.

In the posts that follow this one, we will go deep into each stage. But here is the foundation you need to understand first.

The first stage is research. This is where you close the gap between assumption and accuracy. You use the product. You walk the process. You ask the questions your audience will ask. You do not move forward until you understand what you are documenting well enough to explain it to someone who has never seen it before.

The second stage is audience analysis. Research tells you what is true. Audience analysis tells you what is relevant. Not everything you learn belongs in the document. The question is not what does this product do: it is what does this specific reader need to know, at this specific moment, to complete this specific task. Answering that question shapes everything that follows.

The third stage is information architecture. This is where you decide the order. What comes first, what comes next, and why. A document that contains the right information in the wrong order is still a document that fails. Architecture is the discipline of arranging what you know into a sequence your reader can follow without effort.

These three stages are the skeleton of every document you will ever write. Master them, and the writing becomes the easiest part of the process.

The Work Before the Work

There is a reason experienced technical writers spend more time before the document than inside it. It is not perfectionism. It is not overthinking. It is the understanding that a document built on a weak foundation cannot be saved by strong sentences.

When I sat down to write that product review without fully understanding the product, I was not being lazy. I was being unconscious. I did not yet know that the work before the work was the work. I thought documentation began when you started typing. It does not. It begins when you start understanding.

That shift in thinking is what separates documentation that informs from documentation that merely exists. And it is the shift this series is built around.

In the next post, we go into the first stage in depth. Research: not as a preliminary checkbox, but as the foundation of everything accurate you will ever write.

The words come later. First, you have to understand.