Anyone who has done content modeling for a content management system (CMS) has probably had a discussion—internally or out loud—about whether or not a content type is getting too complex. Knowing how to balance model complexity is part science, part art.
What is complexity, though? Well, maybe you know it when you see it? I’m not sure I can clearly define it, so let’s look at some warning signs that your content type is getting too complex.
Presentation is part of the model
For scalable, future-friendly content, you ideally want content separate from how it gets presented. However, sometimes teams have to make pragmatic tradeoffs that start to mix the concerns, and other times teams don’t know better.
If you find yourself putting in fields to be used as layout controls, you’re making presentation part of the model, and you’re limiting that content type to a small set of uses. This is a sign of complexity in your content type that is best avoided.
A digital experience platform (DXP) is a way to separate presentation from content, and many DXPs give you the ability to put the layout controls in a presentation layer completely outside the content model, with a way to map what content types and fields relate to design system components.
If you don’t have a DXP, then consider having what I call “content primitive” content types that hold your content and “assembly” content types where you reference content primitives and have layout controls. Pro tip: Use naming conventions for your content types, including emoji like 📝(content primitive), 🏭(assembly), or 🎨(presentation/layout).
The content type represents more than one concept
I worked on a migration from an unstructured system to a headless CMS, and one trade-off we made was to have a single primary content type, a topic. The problem was that we wanted to have topics that leaned on the technical writing DITA standard that had three distinct kinds: concept, task, and reference.
The inherent structure of those three was drastically different, and by using a single topic content type, we essentially had none of the structure for any of the three. We had a title and a body.
In a sense, our model wasn’t actually overly complex. It was overly simplistic. But it was three things—concepts—masquerading as one.
I’ve also seen teams flip the approach from our overly simplistic approach and put in ALL the fields for the different things that the content type represents. For our example, the complex version would have the concept fields, the task fields, and the reference fields. You can see how that complexity leads to a bunch of questions.
If you find that a content type is representing more than one thing, consider making content types for each thing.
The content type has too many fields
In many cases, there’s not a hard number of what “too many fields” is. Many CMS vendors have no limit, or a limit of hundreds or dozens of fields. In Contentful, there is a hard limit of 50 fields per content type.
Field count, though, is a technical consideration of “too many fields.” An oft-forgotten aspect of “too many fields” is what I call the author experience. Others call it the editorial experience.
Think of your authors as users (see also: Who is the user, really?) and test your content models with them creating and modifying content.
There is no right number of fields, but you need to structure the model to represent the proper user-facing fields for the content type, along with any appropriate metadata fields you may need, depending on the CMS you’re using. That said, I don’t think I’ve ever really approached 50 fields.
If you do start getting dozens of fields, consider abstracting out fields into new content types that you reference from the original content type. For example, you might pull out Schema.org fields into a Schema content type or address fields into an Address content type, giving those related fields a distinct place in the larger content model. Even if they won’t be reused anywhere, it’s clear what they are.
The thing to recognize here is that reuse isn’t the only reason to have a content type. Sometimes we need content types for logical groupings, governance, authoring experience, and so on.
References are deeply nested
The beautiful thing about content modeling is the ability to connect from one content type to another, something generally referred to as a reference.
You’d be hard-pressed to find a content type that I’ve created that doesn’t reference (outbound) at least one other content type—or that isn’t referenced (inbound) by another content type.
However, when you have a content type that references another content type that references another content type that references another content type that … That’s a series of nested references. (I stopped at 4 levels of nesting.) Some nesting is unavoidable and maybe even good, but deep nesting starts to run into technical concerns.
Contentful’s Content Delivery REST API has a limit of 10 levels of nesting. Their GraphQL API doesn’t technically have a nesting limit, but there are complexity limits and queries with more nesting are more complex. Adobe Experience Manager doesn’t have a hard limit but recommends no more than 10 layers. Sanity has a hard limit of 20 layers of nesting.
Personally, I start paying attention if my references are 3 layers deep. I like to think of my references more like a flat, interconnected web and less like a tree.
The model relies heavily on conditional fields
Some CMS vendors support conditional fields, which are fields that display to authors only under certain circumstances. This makes total sense if you have content types that are largely similar with a few key differences.
It’s not that you need to avoid conditional fields, but they should be deployed strategically. If your content type relies heavily on conditional fields, you may need multiple content types. If you break a content type into multiple content types, then you might be glad to have already abstracted groups of related fields into their own content type that the new multiple content types could reference.
At some point, you’ll need to be able to ask and answer the question: When does this conditional variant cross the line from “variant” to “new concept”?