This is content systems design
Every organisation runs on content – yet almost none of them manage it as infrastructure. Here's what changes when they do.
Every meaningful digital system depends on content.
It’s the unit of organisational meaning that bridges the gap between an organisation’s goals and its users’ needs.
Despite this, most organisations still treat content as a commodity cost centre rather than the infrastructure that it actually is.
Produced channel by channel (pages needed for the website, articles for the knowledge base please, who’s sorting copy for the app?) – and owned within fragmented silos.
A cost centre is something you spend as little on as possible. Infrastructure, on the other hand? That’s something your business can’t actually operate without.
This is an article about the move from content chaos to content systems design: the practice of treating organisational content as the infrastructure it has always been.
From chaos to order: understanding the four domains of content capability in most orgs
Most organisations don’t have a unified system for managing their content lifecycle. They have multiple content functions operating simultaneously.
When organisations treat content as a channel-bound commodity, when it’s produced reactively on instinct, what emerges isn’t a content system.
It’s content chaos:
Multiple teams creating and maintaining the same or similar information in different places.
Contradictory guidance and messaging between channels and platforms.
No clear ownership and accountability for critical information.
Content that cannot be reliably reused, maintained, or governed.
Constant content production without corresponding investment in content systems.
The first step away from content chaos is recognising the different domains that typically make up an organisation’s content ecosystem.
Most cross-organisational content activity can be grouped into four broad domains:
Brand content – expresses an organisation’s identity, narrative, and voice
Marketing content – articulates and presents the org’s core propositions – its products, services, features, and use cases
UX content – the language and assets that shape the interactions users have with an organisation’s products and services
Knowledge content – the guidance, documentation, and support that helps people to understand things, resolve queries, and complete tasks.
The challenge for most organisations is that while these domains operationally exist, they rarely exist as designed systems. Instead, they operate as fragmented, channel-bound activities.
Websites, knowledge bases, apps or AI assistants are not systems. They’re examples of user-facing interfaces through which content is created and interacted with.
But a content system is the thing they all need to draw from. Most organisations have never built the system – they’ve only ever created outputs.
Despite their differences, every content system is built from the same underlying components.
Understanding them is the next step toward treating content as infrastructure rather than a commodity.
The universal components of any content system
Whether we’re talking about Brand, Marketing, UX, or Knowledge content domains, the same three questions determine the quality and effectiveness of their underlying system:
What is the substance of what is known and needs to be communicated?
How is that information organised and structured?
How is that content, as a system, maintained over time?
Each of those questions is answered by the three universal components of every content system.
Substance
Substance is the content itself.
The webpages, articles, blog posts, documents, research reports, and so on that make up the organisation’s information corpus.
Structure
Structure is the semantic architecture layer that organises content, individually and collectively, so that it can be consistently found, navigated between, and cross-related.
In other words, the content templates, models, taxonomies, metadata, and information architecture that allow content to be found, retrieved, connected, and reused in meaningful ways.
Governance
Governance is content’s ‘people layer’, determining how content is sustainably handled, produced, evaluated, and maintained.
We’re talking roles & responsibilities, documented workflows, standards, guidelines, policies, and tools – all of the stuff that makes all of the actual labour of content operations, well... content operations.
Where AI or agentic execution is in scope, Governance also holds the machine-operable context: routing instructions, evaluation rules, source-priority rules, skills, and boundaries.
Together, the three layers form the foundational framework of every content system.
Ok, good. So… what does a system built on these three layers actually look like? Let’s cover that, next.
The file repo as content system
Software engineering separated code storage from code application, decades ago. Git-hosted repositories made codebases version-controlled, maintainable, and reusable single sources of truth for engineering to draw from.
Visual design has gone through this breakthrough as well. The creation of design systems – composed of definitive tokens, components, reusable design elements – has given designers the ability to reliably draw from one centralised source for the creation of multiple products and platforms.
Content has only ever partially reached its equivalent breakthrough. The evolution of content design systems within the UX design domain, and docs-as-code within technical documentation, offer genuine precedents for content already being treated as infrastructure, rather than commodity ‘add ons’ within those fields.
But notice how both of these examples, in their own way, treat content as a subordinate subcategory of a more important, defining discipline? Docs-as-code makes it a citizen of the engineering world – content in code’s repositories, on code’s terms. The content-design-system movement – valuable in its own right – makes it an annex of design, with content bolted onto the design system.
My suggestion here is simpler and more ambitious: content is more than just a branch of engineering or an influencing factor of design. It’s a peer. Engineering has its codebase. Design has its design system.
Content deserves the same – its own repository, on its own terms, holding its own schema and significance. Not a seat at a broader discipline’s table, but a table of its own.
In practical terms, a designed content system is a file repository: a structured, channel-agnostic set of lightweight text files (with markdown being the most obvious format of choice at the time of writing) that the organisation can open, inspect, maintain, version, and use.
The website, the help centre, the app, the agent – these are all platform expressions of a content system.
Here’s what individual instances of such content systems could look like.
Illustrative examples of content systems
A Marketing content system might include propositions, audience needs, campaign messaging, offer models, proof libraries, CTA patterns, claim governance, adaptation rules, and evidence standards.
A Brand content system might include approved positioning, narrative, terminology, claims, proof points, voice and tone, messaging architecture, review workflows, and rules for changing public language.
A UX content system might include the actual live UI strings for a product: screen copy, labels, forms, validation messages, error states, empty states, notifications, onboarding, settings, and permissions. It would also include the structure around those strings: screen inventories, string schemas, localisation keys, component content models, and release-change governance.
A Knowledge content system might be a customer help-centre system, a technical documentation system, an internal staff knowledge system, or a connected version of all three (where it would be useful for an underlying knowledge base to be powering those different interaction mode contexts). It would hold the answers, procedures, product truths, troubleshooting logic, documentation models, metadata, permissions, review workflows, escalation rules, and agentic context needed for people or systems to act from it.
Before wrapping up, I want to consider a repeatable process for designing content systems.
Content systems design: a methodology
I’ve defined three logical steps for developing valuable content systems both within and between different content domains.
Phase 1: A content capability assessment
Phase 2: Content system design
Phase 3: System implementation
For the purpose of this article, I’m just going to focus on what the first phase of work involves, as that’s what the true ‘unlock’ piece of work that subsequent phases rely on.
Content capability assessment and profile creation
This is an in-depth analysis of content – either within a single scoped domain or across multiple domains – scored against defined quality criteria within each layer of its content infrastructure.
Substance criteria: strategic purpose, accuracy, clarity, consistency.
Structure criteria: taxonomy, metadata, information architecture, page templates and content models
Governance: roles and responsibilities, workflows, standards and guidelines, tools, enablement and training
The output is a clear, scored content system capability profile produced per domain.
Scaled up, a cross-domain content capability assessment creates a full content ecosystem capability profile that directly correlates to specific user-facing platforms and interface surfaces, through the lens of relative content infrastructure strengths and constraints…
From here, the capability profile directly translates into digital platform requirements and content systems to be designed and integrated.
Most organisations do not need all their content systems designed at once. They need to start with the system that represents the highest priority in relation to business goals and user needs.
For example, the above capability profile would point to knowledge content systems work – and specifically in relation to customer support content infrastructure work – as the area of critical strategic investment.
The point is not to systematise content in order to ‘make it tidier’ for its own sake. Nobody needs a beautifully organised repository of irrelevance.
The point is to make the content the organisation actually, genuinely depends on more explicit, governable, and usable across the channels and systems that need it.
It’s about creating a direct throughline between content capability and requirements, and bottom-line areas of business impact.
Content was always the thing that so much of business operations depended on.
Content systems design is what it looks like to finally manage it that way.