A very brief introduction to content modeling
TLDR: A content model defines the structure of all content in a website or an app
Some context first
- You’re building a website or an app with content
- You’re using a CMS to make content editable
- You need to structure the content so that it’s frontend-ready
- Structuring content is called content modeling
What is content modeling
Breaking down every page or view into basic elements like "text", "image", "date" or "location" – that’s content modeling. It’s very similar to database modeling.
Example: A content model for a blog post. Each type of content is modeled as a separate field.
In a way, a content model is the bridge between content and code: it’s a compromise between completely free-style content design and highly structured content representation on the frontend.
Who is responsible for the content model
Typically a developer who’s setting up the CMS, but could also be someone else, depending on the project: a content strategist or a content manager
When should content modeling happen
As always, it varies from project to project, as each team has their own best practices, but here’s a linear workflow that we consider the most optimal:
- Project specs → Information architecture → Sketches / Wireframes → Visual design → Content modeling → Content creation → Front-end development
Sure there’s a lot of variations to this: some parts can happen simultaneously, sometimes the content can be created in the beginning.
Most importantly, content modeling should only be done when you already know what the content will look like. Otherwise, a content model might turn out to be irrelevant which would lead to either
1) a lot of hacks and inconveniences on the frontend, or
2) redoing the content model and extra work for content managers.
Changing an existing content model is hard
A content model largely defines the UX of a CMS for both developers and authors. Similar to database design, setting up a content model takes only a few minutes, but the implications are long-lasting.
Once a content model is in place and content managers start creating content and developers start building the frontend, every change to the content model is costly: adding or removing 1 field would mean changes both in the code and to the content. Which is why a lot of thought should go into the content model before implementing it.
A content model should be usable for authors, too
The common practice goes like this: developers set up the content model without considering what it’d be like for content authors to actually work with it. It seems reasonable: developers optimize the CMS to simplify development. However, it might turn out that what’s good for developers might be counter-productive and inconvenient for authors. But, since changing an existing content model is expensive (see above), most likely it’ll stay this way.
A better practice would be for developers to get the content teams involved early in the project to collectively figure out a content model that acts as a healthy compromise between developers’ and authors’ interests.