Content models can be either a friend or foe. A content model can empower content to become a modular and flexible resource when developed appropriately. Models can liberate how you develop content and accelerate your momentum.
However, if the model isn’t developed correctly, it can become a barrier to gaining control over your content. The model ends up being hard to understand, the cause of delay, and eventually an albatross preventing you from pivoting later.
Models are supposed to be the solution, not the problem
Content modeling can be challenging. Those involved with content modeling have likely heard stories about teams wrestling with their content model because it was too complex and difficult to implement.
Some common concerns about content modeling include:
- There’s not enough time to develop a proper content model.
- We don’t know all our requirements yet.
- People don’t understand why we need a content model or how to develop one.
- Most of the content model doesn’t seem relevant to an individual writer.
- Someone else should figure this out.
These concerns reflect an expectation that a content model is “one big thing” that needs to be sorted out all at once in the correct way, what might be called the monolithic school of content modeling.
Rather than treat content models as monolithic plans, it is more helpful to think of them as behaving like LEGO. They should support the configuration of content in multiple ways.
Yet, many content models are designed to be monolithic. They impose a rigid structure on authors and prevent organizations from addressing a range of needs. They become the source of stress because how they are designed is brittle.
In an earlier post, I briefly explored how LEGO’s design supports modularity through what’s called “clutch power.” LEGO can teach us insights about bringing modularity to content models. Contrary to what some believe, content models don’t automatically make content modular, especially when they are missing clutch power. But it’s true that content models can enable modularity. The value of a content model depends on its implementation.
A complex model won’t simplify content delivery. Some folks mistakenly think that the content model can encapsulate complexity that can then be hidden from authors, freeing them from the burdens of details and effort. That’s true only to a point. When the model gets too complex for authors to understand and when it can’t easily be changed to address new needs, its ability to manage details deteriorates. The model imposes its will on authors rather than responding to the desire of authors.
The trick is to make model-making a modular process instead of a top-down, “here’s the spec, take it or leave it” approach.
Don’t pre-configure your content
LEGO pioneered the toy category of multipurpose bricks. But over time, they have promoted the sale of numerous single-purpose kits, such as one for a typewriter that will “bring a touch of nostalgia to your home office.” For $249.99, buyers get the gratification of knowing exactly what they will assemble before opening the package. But they never experience the freedom of creating their own construction.
The single-purpose kits contain numerous single-purpose bricks. The kit allows you to build one thing only. Certain pieces, such as the typewriter keys and a black and red ink spool ribbon, aren’t useful for other applications. When the meme gets stale, the bricks are no longer useful.
One of the most persistent mistakes in design is building for today’s problems with no forethought as to how your solution will accommodate tomorrow’s needs.
Many content models are designed to be single-purpose. They reflect a design frozen in time when the model was conceived – often by an outside party such as a vendor or committee. Authors can’t change what they are permitted to create, so the model will often be vague and unhelpful to not overly constrain the author. They miss out on the power of true modularity.
When you keep your model fluid, you can test and learn.
Make sure you can take apart your model (and change it)
Bent Flyvbjer and Dan Gardner recently published a book on the success or failure of large projects called How Big Things Get Done. They contrast viewing projects as “one big thing” versus “many small things.”
Flyvbjer and Gardner cite LEGO as a model for how to approach large projects. They say: “Get a small thing, a basic building block. Combine it with another and another until you have what you need.”
The textbook example they cite of designing “one big thing” all at once is a nuclear power plant.
Flyvbjer and Gardner comment: “You can’t build a nuclear power plant quickly, run it for a while, see what works and what doesn’t, then change the design to incorporate the lessons learned. It’s too expensive and dangerous.”
Building a content model can seem like designing a nuclear power plant: a big project with lots of details that can go wrong. Like designing a nuclear power plant, building a content model is not something most of us do very often. Most large content models are developed in response to a major IT re-platforming. Since re-platformings are infrequent, most folks don’t have experience building content models, and when a re-platform is scheduled, they are unprepared.
Flyvbjer and Gardner note that “Lacking experimentation and experience, what you learn as you proceed is that the project is more difficult and costly than you expected.” They note an unwanted nuclear power plant costs billions to decommission. Similarly, a content model developed all at once in a short period will have many weaknesses and limitations. Some content types will be too simple, others will be too complex. Some will be unnecessary ultimately, while others will be overlooked. In the rush to deliver a project, it can be difficult to even reflect on how various decisions impact the overall project.
You will make mistakes with your initial content model and will learn what best supports authoring or frontend interaction needs, enables agile management of core business messages and data, or connects to other IT systems. And these requirements will change too.
Make sure you can change your mind. Don’t let your IT team or vendor tell you the model is set in stone. While gratuitous changes should be avoided – they generate superfluous work for everyone – legitimate revisions to a content model should be expected. Technical teams need to develop processes that can address the need to add or remove elements in content types, create new types, and split or merge types.
Allow authors to construct a range of outputs from basic pieces
In LEGO, the color of bricks gives them expressive potential. Even bricks of the same size and shape can be combined to render an experience. I recently visited an exhibit of LEGO creations at the National Building Museum in Washington, DC.
Much online content is developed iteratively. Writers pull together some existing text, modify or update it, add some images, and publish it. Publishing is often a mixture of combining something old with something new. A good content model will facilitate that process of composition. It will allow authors to retrieve parts they need, develop parts they don’t yet have, and combine them into a content item that people read, watch, or listen to.
Content modeling is fundamentally about developing an editorial schema. Elements in content types represent the points authors want to make to audiences. The content types represent larger themes.
A content model developed without the input of authors isn’t going to be successful. Ideally, authors will directly participate in the content modeling process. Defining a content type does not require any software expertise, and at least one CMS has a UI that allows non-technical users to create content types. However, it remains true that modeling is not easy to understand quickly for those new to the activity. I’m encouraged by a few vendor initiatives that incorporate AI and visualization to generate a model that could be edited. But vendors need to do more work to empower end-users so they can take more control over the content model they must rely on to create content.
Keep logic out of your model
LEGO is most brilliant when users supply the creativity rather than rely on instructions from the LEGO corporation.
The DIY ethos of LEGO is celebrated on the Rebrickable website, where LEGO enthusiasts swap concepts for LEGO creations.
Rebrickable illustrates the principle of decoupling content from its assembly. LEGO bricks have an independent existence from assembly instructions. Those who develop plans for assembling LEGO are not the same people who created the bricks. Bricks can be reused to be assembled in many ways – including ways not foreseen. Rebrickable celebrates the flexibility of LEGO bricks.
A content model should not contain logic. Logic acts like glue that binds pieces together instead of allowing them to be configured in different ways. Decouple your content from any logic used to deliver that content. Logic in content models gets in the way: it complicates the model, making it difficult for authors (and even developers) to understand, and it makes the model less flexible.
Many Web CMS and XML content models mix together the structure of types with templating or assembly logic. When the model includes assembly instructions, it has already predetermined how modules are supposed to fit together, therefore precluding other ways they might connect. Content models for headless CMS implementations, in contrast, define content structure in terms of fields that can be accessed by APIs that can assemble content in any manner.
A brittle content model that can’t be modified is also expensive. Many publishers are saddled with legacy content models that are difficult to change or migrate. They hate what they have but are afraid to decommission it because they are unsure how it was put together. They are unable to migrate off of a solution someone built for them long ago that doesn’t meet their needs. This phenomenon is referred to as “lock-in.”
A flexible content model will focus only on the content, not how to assemble the content. It won’t embed “views” or navigation or other details that dictate how the content must be delivered. When the model is focused solely on the content, the content is truly modular and portable.
Focus on basics and learn
LEGO encourages play. People don’t worry about assembling LEGO bricks the wrong way because there are many valid ways to connect them. There’s always the possibility of changing your mind.
Each LEGO brick is simple. But by trying combinations over time, the range of possibilities grows. As Flyvbjer and Gardner say in their book, “Repetition is the genius of modularity; it enables experimentation.”
Start your model with something basic. An author biography content type would be a good candidate. You can use it anytime you need to provide a short profile of an author. It seems simple enough, too. A name, a photo, and a paragraph description might be all you need. Congratulations, you have created a reusable content type and are on the path toward content modularity.
Over time, you realize there are other nuances to consider. Your website also features presenters at live events. Is a presenter biography different from an author biography? Someone in IT suggests that the author bio can be prepopulated with information from the employee directory, which includes the employee’s job title. The HR department wants to run profiles of employees on their hiring blog and wonders if the employee profile would be like the author bio.
As new requirements and requests emerge, you start to consider the variations and overlaps among them. You might try to consolidate variations into a single content type, extend a core content type to handle specialized needs or decide that consolidating everything into a single content type wouldn’t simplify things at all. Only through experimentation and learning will the correct choice become apparent.
It’s a good idea to document your decisions and share what you’ve learned, including with outside teams who might be curious about what you are working on – encourage them to steal your ideas. You can revisit your rationale when you are faced with new requirements to evaluate.
Evolve your model
Embrace the LEGO mindset of starting small and thinking big.
The more experience your team gains with content modeling, the more comprehensive and capable your content model will become.
Flyvbjer and Gardner note: “Repetition also generates experience, making your performance better. This is called ‘positive learning.’” They contrast it with negative learning, where “the more you learn, the more difficult and costly it gets.” When the model starts off complex, it gets too big to understand and manage. Teams may realize only one person ever understood how the model was put together, and that person moved to another company.
Content modeling is about harnessing repeating patterns in content. The job of content modeling is to discern these patterns.
Content modeling should be a continuous activity. A content model isn’t a punch-list task that, once launched, is done. The model isn’t frozen.
The parts that work right will be second nature, while the parts that are still rough will suggest refinement.
While content modeling expertise is still far from mainstream, there are growing opportunities to gain it. Teams don’t have to wait for a big re-platforming project. Instead, they should start modeling with smaller projects.
New low-cost and/or low-code tools are making it easier to adopt modular approaches to content. Options include static site generators (SSGs) like Jekyll or Hugo, open-source headless CMSs like Strapi, and no-code web-builders like Webflow. Don’t worry if these tools don’t match your eventual needs. If you build a model that supports true modularity, it will be easy to migrate your content to a more sophisticated tool later.
With smaller projects, it will be more evident that the content model can change as you learn new things and want to improve it. Like other dimensions of software in the SaaS era, content models can continuously be released with improvements. Teams can enhance existing content types and add new ones gradually.
The evolution of content models will also include fixing issues and improving performance, similar to the refactoring process in software. You may find that some elements aren’t much used and can be removed. You can simplify or enrich your model. Sometimes you’ll find similar types that can be folded into a single type – simplification through abstraction. Other times, you’ll want to extend types to accommodate details that weren’t initially identified as being important.
Continual iteration may seem messy and inefficient, and in some ways, it is. Those who approach a content model as one big thing wish the model to be born fully mature, timeless, and resistant to aging. In practice, content models require nurture and maintenance. Changing details in a large content model will seem less scary once you’ve had experience making changes on a smaller model. And by working on them continuously, organizations learn how to make them better serve their needs.
Regard changes to content models as a learning experience, not a fearful one.
Allow your model to scale up
Flyvbjer and Gardner note: “A block of Lego is a small thing, but by assembling more than nine thousand of them, you can build one of the biggest sets Lego makes, a scale model of the Colosseum in Rome. That’s modularity.”
My visit to the National Building Museum revealed how big a scale small LEGO bricks can build, as shown in this model of London’s St Pancras rail station.
The magic of LEGO is that all bricks can connect to one another. The same isn’t necessarily true of content models. Many models reflect the idiosyncrasies of specific CMS platforms. Each model becomes an isolated island that can’t be connected to easily. That’s why content silos are a pervasive problem.
However, a modular content model focused on content and not assembly logic can easily connect to other modular models.
A content model can enable content to scale. But how does one scale the content model?
The good news is that the same process for developing a small model applies to developing a larger one. When you embrace an iterative, learning-driven approach to modeling, scaling your model is much easier. You understand how models work: which decisions deliver benefits and which ones can cause problems. You understand tradeoffs and can estimate the effort involved with alternatives.
One key to scaling a model is to play well with other models. In large organizations, different teams may be developing content models to support their respective web properties. If these models are modular, they can connect. Teams can share content.
It’s likely when there are two models, there will be overlaps in content types. Each model will have a content type defining a blog post, for example. Such situations offer an opportunity to rationalize the content type and standardize it across the teams. Eventually, separate teams may use a common content model supporting a single CMS. But until then, they can at least be using the same content type specifications. They can learn from each other.
– Michael Andrews