What can go wrong when modeling is hurried

Good things take time

Time pressure and a lot of tight deadlines have become a new standard. Therefore, saving time by speeding up the content modeling phase and omitting the relevant stakeholders is often very tempting. But is it worth it?

The domino effect of design-driven models

Setting up a content model with pages at its core will mean it’s outdated when the design of the pages changes. These days, when changing the website design every couple of years is pretty much the norm, it means that you will need to redo the content model from scratch. The content model is the centerpiece of content. To redo it, it will also require:

• Source code changes
• Other configuration changes
• Content creation process changes

Eventually, a new content model will affect all roles in your company.

Repetitive content creation

Content models quickly patched together often mimic real-life forms or database tables. Not much thought is given if those elements and their content are reused elsewhere. Adding an element for an asset is effortless, but related metadata is often stored in other elements. This approach produces content types that are long forms with dozens of elements needed for your app to work. Do you want the authors to re-add the same description, alt tag, or categories every time they use a shared asset? These consistency issues force content creators into a lot of copy-paste work that no one enjoys. They’ll start to resent the content model, steering you away from the current setup or overall solution. That will lead to another migration, content model creation, configuration, training, and process creation.

Copy-pasting channel-specific content

A widespread approach to covering multiple channels is to add elements for a specific delivery medium. Some CMS vendors have these in their 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 time adding new fields, hooking up the business logic – and then what do the editors do? They copy-paste the content from other elements, which hinders their productivity.

WYSIWYG pressure causes more harm than good

Overuse of WYSIWYG elements and embedding layout information into text has given editors layout-changing powers since the release of Microsoft FrontPage. This approach might be great for a one-person business, but companies with complex content operations value consistency over layout editing freedom. Developers struggle when their stylesheet is overridden or when dealing with unexpected inline JavaScript. These are things possible when you decide to go for WYSIWYG. While most online channels use HTML, quite a few don’t. Using RegEx to extract useful information from WYSIWYG HTML elements full of tables is complex and error-prone. Introducing WYSIWYG elements into your CMS will only bring more maintenance. Hurried content models may depend on WYSIWYG because the content model concept isn’t well-thought-out. This will turn out as pleasing for creators in the short term but a more costly and cumbersome problem in the future.

Non-transparent content relationships 

Missing out on useful metadata locks you into using relationships for everything. Linking one item to another will be a must to express any relationship. These tangled relationship dependencies will be a pain to manage and use within the code. If you miss an important relationship, adding it back into the model is almost impossible. 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. Sooner or later, you’ll outgrow such an inflexible content model, having to redo the content model from scratch.

Can doesn’t mean should

Headless CMSs are very open regarding their configuration, and it sometimes gives a false idea that because something is possible, it should be modeled so that creators can always decide whether to use something. However, modeling many edge-case scenario options leads to a bad authoring experience because there are so many options. Similarly, developers must spend significant time implementing and maintaining all model combinations. A future-proof content model has consistency in mind, so it focuses on improving the main scenarios instead of adding more and more functionality that will be used just a handful of times. Hurried content models are, in contrast, full of “what if” functionality that only adds time to both developers and creators.

What all these problems have in common