What can go wrong
There are several things that can go awry if your content model was hastily designed. Let’s say you designed your content model with the front-end design in mind. You may have created a content type representing your page structures. Within these pages, you used text elements, and you hierarchically linked them directly within these pages.
Setting up a content model this way will mean it’s outdated when the design changes. These days, when changing the website design every couple of years is pretty much the norm, it means that you will have to hack your existing model to fit the new trend, switch the CMS because the old one is “not flexible enough,” or redo the content model from scratch.
Another thing to watch out for is sufficiently chunking the content. It’s really easy to design a long form with dozens of elements needed for your pages to work. Often, not much thought is given about if any of those elements and their content are being reused somewhere else. It’s very easy to add an element for an asset, but often there is related metadata stored in other elements. That picture of a mattress will always need the same type of metadata. Do you want the authors to re-add the same description, alt tag, or categories every time they use a shared asset? This approach introduces consistency issues and forces a lot of copy-paste work that no one is a fan of.
A very common approach to covering multiple channels is to add elements for a specific delivery medium. Some CMS vendors have these in their content type templates. Often, there is a Facebook post description or a Twitter summary in the long list of elements. So with every new social network, a new element is added, but when do you stop? This isn’t how you create a future-proof content model. No developer wants to spend their time adding new fields, hooking up the business logic—and then what do the editors do? They copy-paste the content from other elements.
Missing out on useful metadata locks you into using relationships for everything. Linking one item to another will be a must in order to express any relationship. These tangled relationship dependencies will be a pain to manage and to use within the code. If you miss an important relationship, it’s almost impossible to add it back into the model. A metadata-driven approach is much easier to enhance, maintain, and utilize to surface information in the right context.
Designing content models that are not future-proof wastes everyoneʼs time. There are some winners though. Sooner or later, the client will outgrow such an inflexible content model and if you are lucky, you get to design a new one. If you are not, another agency will happily take your place.
Weʼve got you covered if you need even more reasons why to learn content modeling.