Why Does Content Become Disorganized?
Why is it that writing can start out clear and organized, with a coherent logic and order, but then progress toward fragmentation, disarray, and messiness? How do you move from an ordered content system to an unordered content system?
The movement towards disorganization describes the natural direction of many things. Our houses get messy each week and must be cleaned. Our computer desktop gets cluttered and must be ordered. Broken eggs don't naturally reconstitute themselves into whole eggs. Sand (which was once rock) doesn't reshape itself into rock.
Content also resists order at every turn. Even when you have multiple contributors working on the content, you can still end up with a content mess, something that's no better than the metaphoric broken egg or random whirl of sand. In fact, the more contributors you have shaping the content, the more problematic it often gets.
Single Person Authoring
When one person writes an entire body of technical content, the content tends to be more organized than scenarios in which multiple writers contribute to the content, especially when the multiple writers come from different departments, writing at different periods in the company's time, with different writing backgrounds and skill levels, and with a variety of styles.
Yet while single author paradigms sometimes result in tighter coherence of content, the single authoring paradigm doesn't scale and tends to be myopic. Content authored by just one person gets outdated and is often incomplete. Modern workplaces can't discard collaborative authoring and still keep pace in the market. So let's examine three scenarios to explore how collaboratively authoring goes awry, resulting in a content mess.
Scenario 1: Avoiding Offense
Tina, a technical writer, writes 50 pages of documentation on the company site. A year later, Mark in Marketing comes along and writes another 50 pages. Mark doesn't want to remove the content Tina wrote, so he recreates some of his own in another section of the site with his own navigation.
Sue in Support adds 25 more pages, following a different style than anyone else. Sue leaves the other content alone for the most part, tacking hers on as an addendum. Then Bill, a business analyst, enters the scene and tries to clean up some of the content, but ultimately just shifts it around to other sections and finds space to insert his own.
This is how you end up with a content mess. Everyone adds their own content without seeing and shaping the content as a whole.
This scenario happens frequently with wikis, which is why wikis often degenerate into content junkyards. But it can also happen wherever you have a collaborative authoring scenario.
The basic problem is that content contributors are too kind. Rather than slashing and burning the forest to regrow the trees, they instead plant new patches of forest here and there in their own little areas, and then wonder why the landscape looks like a jungle.
Scenario 2: Too Much Control
Now let's tweak the variables a little. Tina the technical writer creates 50 pages of content in a help authoring tool (e.g., ACME Builder) and publishes it in a tripane help. Later Sally needs to add another 50 pages. But Tina is the only queen in her kingdom, and doesn't allow outsiders to have tool control, so Sally decides to publish her content on a Google Apps site instead.
Jane has a need to push out 15 more pages, so she pushes it onto her own platform she can control -- a self-hosted open-source wiki (Confluence). Mark then enters the picture to publish some more extensive information on yet another platform -- a WordPress site.
In this model, although each writer creates content on a separate platform, the result is the same content mess, only fragmented across platforms and tools. Sure it's more organized, but no one can find anything because they don't know which site to explore.
Different employees have different publishing needs, and if you stop a group from writing and publishing, they just find their own tool and venue to get the content out. Consistency of tools, both with access and authoring, poses huge challenges with collaborative authoring.
Scenario 3: Process-driven Collaborative Authoring
In my third scenario, the tech pubs group has a tight process to control who can author and publish content. Tina the technical writer creates 50 pages of content. She learns that Sally in Support has a lot of information to get out to customers, so she meets with Sally and edits her content as she integrates it into the existing content.
Tina also learns that Jane in Development has new information to add and has already written it. Tina modifies the information and integrates it into the existing technical content. She does the same with Mark from Marketing and others who have content to publish.
In this model, Tina is the gatekeeper, the editor, and the publisher of content. She carefully integrates the content into the same platform, enforcing judgment about what to cut in order to integrate content in a logical way.
This third model seems to work best because it empowers someone as a content steward. Any site that's going to maintain a coherent and consistent structure needs someone to oversee who adds what and where. Like a soccer game, a content-rich website need a site referee to blow the whistle, hand out yellow cards now and then, and keep order on the field. This person is known as the "chief content officer" in some circles.
The only problem is that as a content referee, Tina has no time to play the game herself. The CCO role takes the most skilled writer in the company and displaces her from an individual contributor position. (Of course, this practice follows standard corporate "growth" models. See the Peter Principle for more details.) The writing quality degrades because there are fewer skilled writers creating content.
Although the content CCO model seems most compelling, it gets more complicated. How does Tina entitle herself as a content gatekeeper and gain authority to prevent others from self-publishing? How does Tina keep up-to-date about all the content publishing needs the organization has without attending nearly every single meeting? How does Tina find time to verify the information coming from other groups? If she doesn't verify the information, what happens to the writing quality?
Ideally Tina needs some technical privilege that entitles her with a Publish button but restricts the button from everyone else. But in order to get this kind of privilege, she has to entrench herself in department politics and strategic maneuvering, usually while keeping up on all her writing and publishing duties. This will spread Tina's time rather thin as well as increase her pressure to perform. The scenario takes the writing out of the writer.
A Final Scenario
There's one final scenario to present: doing nothing. In Scenario 4, Tina authors 100 pages of content, completes her contract with the company, and then leaves. Meanwhile, developers continue to push out new releases, designers modify the interface, users identify gaps and other problems, QA testers find bugs and quirks.
Pretty soon, after about a year, the documentation Tina once wrote, which looked so complete and helpful when she first published it, is now an outdated mess.
Conclusion and a Light in the Tunnel
None of the scenarios are ideal, which is why content so often unravels from a state of order to a state of non-order.
I mentioned at the beginning some commonly held thoughts about entropy, noting that the natural direction of the world moves toward disorder, including content. But that's not entirely true. Planetary dust does swirl into ordered planets. Molecules assemble themselves into intelligent, living helix formations -- all without seeming to have a guiding hand. Content might have a natural destiny that it shapes to, some property that language innately contains that leads it to an intelligent formation. But I doubt it.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.