I spoke with a company’s documentation lead last year. For one of the company’s products, she had 23 open Word documents, each with release notes for a particular department. For every update, she would copy and paste into 4 different places to publish the update. She is a very organized person, but her biggest problem is her information.
That image got stuck in my head for a reason – it is not particularly unique or creative. It is a simple representation of the kind of informational drudgery that teams in hyper-growth are often stuck in.
What we actually mean by “structured”
First of all, “structured” has become a sort of buzzword. Many people have come to associate the term with “stiff”, “bureaucratic”, and they often don’t even consider that there is a different and very normal meaning for the word. When we talk about “structured” in a business context, we’re talking about information that has been set up into defined types, which have been given appropriate labels, and which are organized in a way that clearly shows their relationships to other bits of information. The really critical thing is that the information be readable by a machine, and that humans be able to get around in it.
When a team’s content is structured, it can be very useful. Reused, searched and even automated. As an example, product information could consist of a title, summary and a specs block. A support article could consist of a description of the problem, the cause of the problem and steps to solve the problem.
Where most teams are losing time.
The reuse problem nobody talks about enough
Here’s an example of how information is reused incorrectly. A writer writes a brand new warning notice that could have been written from reusing a portion of another article. A developer wrote a new UI dialog label that could have been written from reusing the exact same text from a KB article. Support Engineers copy and paste out the steps to solve a problem in 6 different ticket templates. Every time content is re-created by someone else, it is wasting the company’s time to re-create work that could have been done by reusing information that already exists somewhere. Since this time is not tracked as actual cost (i.e. it doesn’t show up as an invoice line item), nobody loses any money.
So, what does structured content look like in practice? If you have information organized into discrete, labeled pieces of content, then you can easily reuse them instead of copying and pasting a huge, unbroken document each time you need to use it.
Another note that structured information can have significant impact even when only small amounts of it are present. Its consistency and predictability make it spread fast throughout an organization. I did not find negative effects of unstructured information to decrease at the same rate as structured information is growing. As soon as a team starts to manage and track changes to unstructured information, the problems decrease significantly (turn from extremely loud, constant and stressful scream to mere murmur).
What do teams actually gain here, besides their sanity?
Now that we have defined what we mean by structured information, let’s talk about how that information can be put to work in your business. Information can be put to work when it is given a shape that can be read by a computer, and which also allows a human to quickly and easily find his or her way around the content. When information is structured, it is of greater value than unstructured information. Information can be reused, searched, and even automated when
- Search actually works. When content has metadata and defined fields, search tools can surface the right piece — not just a keyword match buried on page 34 of a 40-page PDF that someone exported from a system that no longer exists.
- Automation becomes possible. Workflows that once needed a human in the loop — routing content, triggering updates, generating outputs for different audiences — can run on their own because the system actually understands what each piece of content is.
- Onboarding gets faster. New team members can find what they need without relying on tribal knowledge or the one person who’s been there since 2019 and has everything memorized purely out of survival instinct.
- Translation and localization costs drop, sometimes significantly, because translators work with clean, segmented text rather than reformatted blobs where the formatting itself has to be rebuilt in every target language.
Information should be treated as an asset with a known shape or structure, and if it’s been exported from somewhere in a strange format then that’s something to be aware of, and to be addressed.
A quick comparison worth sitting with
| Approach | Update process | Search quality | Reuse potential |
| Unstructured documents | Manual, error-prone, repeated across files | Keyword-only, often unreliable | Low, requires copy-paste |
| Structured content model | Update once, publish everywhere | Metadata-driven, precise | High, built into the system |
| Hybrid (partial structure) | Mixed, depends on the team’s discipline | Inconsistent | Limited, requires manual effort |
This isn’t just a tech writing problem
Most information that gets “documented” within a company is created and managed by teams outside of technical documentation. Those are Marketing teams, legal teams, and even HR. Information that a policy update creates for the HR department to work with for weeks end up being untangled by product teams within their own documentation that’s been copied and pasted across many platforms, often with contradictory results. So, the problems of “structured” information that assist in reusing, in searchability, in automatability that we as technical documentation professionals grapple with on a daily basis, are problems that every group of people who produce, manage information, or work with information as a group face.
(There’s a version of this problem in academia too, which I find fascinating and deeply ironic given how much researchers talk about knowledge management in theory. But that’s a different conversation.)
Most teams are frustrated with the amount of work that they are doing with unstructured information. Information that they have not been able to use in order to realize value from the information that they have created. Many teams struggle to even ask the right question. In order to realize value from information, information must be structured to support a number of goals. The first question is: Is the short-term pain of putting information in a structure worth the long-term relief from having to do work with unstructured information? Of course, it is, but there is a lot of short-term pain in auditing the information that you have already created, defining the types of content that you are going to create, and then, perhaps the toughest part of all, getting writers to agree to use a number of templates to create a number of types of information. Those writers have been creating free-form information for years, and the templates look to them like creative straight-jackets. So, there is a lot of short-term pain and that means there is a lot of resistance to putting information in a structure that can be used by others.
As a reminder, the documentation lead I spoke to last year had closed 20 of the 23 Word documents open when I last spoke with her. That’s work in a canal with a structure, as opposed to same work through a canal without a structure, to borrow from that great guru of same work (writing in general and business writing in particular), Ben Yagoda in, (I think), About Town. Again, same work, and burning coat pocket money. That is to say, money that the documentation lead had, all along, even though she had been losing same by the hour for quite some time prior to our last conversation, which had occurred some quarters after she and I last spoke about same. As I recall, she was making very good use of the time, now, saved, as she rewrote the workflow of her team to best take advantage of information with a structure. Hours a week of her time, that had her running around like a, fairly crazed, chicken before the canal construction had been completed, returned to her now. Now, the information she was using (for her documentation work) had a structure. That is to say, it had been written (all of it), using a tool (as we have already established) that the documentation lead had been using for quite some time. It was, then, not the use of that tool, per se, which had lead to her regained hours of regained time. Rather it was that information had a structure.