When you model content in a CMS, it is tempting to think you are designing a data structure. You are not, or at least not only. You are designing an interface that a non-technical person is going to sit in front of, every day, to do their job. The schema is the editor's UI. Once you see it that way, most of the decisions that feel like database modelling reveal themselves as user experience decisions, and you start making very different ones.
I build on Sanity, so the examples here are Sanity-flavoured, but the principle is true of any structured content system. A schema that is convenient for the developer and a schema an editor can actually use are usually two different schemas, and the second one is the job.
The schema is the editor's UX
Every part of a field that you might dismiss as metadata is, to the editor, the interface. The field's title is the label they read. The description is the only instruction they get. The validation rules are the guardrails that tell them when something is wrong. The preview is how they recognise an item in a list without opening it. None of that is decoration. It is the entire experience of using the CMS.
So the difference between a field an editor understands and one that confuses them is not subtle. Compare these two:
1// Convenient for the developer, hostile to the editor
2defineField({ name: "img", type: "image" });
3
4// Designed as an interface for a human
5defineField({
6 name: "heroImage",
7 title: "Hero image",
8 type: "image",
9 description:
10 "Shown at the top of the page. Use a landscape photo at least 1600px wide.",
11 options: { hotspot: true },
12 validation: (Rule) => Rule.required(),
13 fields: [
14 defineField({
15 name: "alt",
16 title: "Alt text",
17 type: "string",
18 description:
19 "Describe the image for screen readers. Leave empty if the image is purely decorative.",
20 }),
21 ],
22});Same data. Completely different experience. The first leaves the editor guessing what img is for, what size to upload, and whether it is required. The second tells them, in their language, exactly what this is and what good input looks like. The extra lines are not overhead. They are the product.
Model around how the editor thinks, not how you store it
The deeper move is to shape the content around the editor's mental model rather than your storage convenience. Developers naturally model data the way it is cleanest to store and query. Editors think in terms of the things they actually manage: a page, a section, an article, a person. When the schema mirrors how they think about their content, they navigate it without friction. When it mirrors your database, they have to constantly translate between the thing in their head and the strangely-shaped fields in front of them, and they make mistakes in the gap.
This sometimes means a schema that is slightly less elegant from a data standpoint but far more legible to the person using it. That is the right trade. You write the schema once. They use it every day for years.
Constrain choices to prevent invalid states
Freedom in a CMS is not a gift to the editor. It is a burden and a source of broken pages. Every field that can hold anything is a field that will eventually hold something that breaks the layout, and every optional setting is a decision you have pushed onto someone who did not want to make it.
The fix is to constrain. Fewer fields, so there is less to get wrong. Validation that makes invalid states impossible rather than merely discouraged: required where required, min and max lengths, a closed list of options instead of a free-text field where someone will eventually type a colour that does not exist in your design. A good schema does not just permit correct input. It makes incorrect input hard to enter in the first place. Every constraint you add is a class of bug the editor can no longer accidentally create, and a decision they no longer have to carry.
Opinionated blocks beat an over-flexible page builder
This is where the principle gets its sharpest test: the page builder. The instinct is to give editors maximum flexibility, a big open canvas with every option exposed, so they can build anything. In practice that flexibility overwhelms them. Faced with infinite choices and no guidance, they freeze, or they assemble something that technically works and looks wrong, because you handed them the controls without the judgement that was supposed to come with them.
A set of opinionated blocks works far better. A focused library of well-designed sections, each constrained to do one thing well, gives the editor a box of pieces that all look good and all fit together. They are not designing from scratch every time; they are composing from parts you already made coherent. The result is faster for them, more consistent for the brand, and dramatically less likely to produce a broken page. The flexibility they actually wanted was never "anything." It was "enough good options to build what I need," and that is a much smaller, much more designable thing.
The throughline
All of this comes back to one shift in how you think about modelling: you are not describing data, you are building a tool for a specific person to use. Name and describe fields as the instructions they are. Shape the structure around how the editor thinks. Constrain aggressively so invalid states cannot happen. And give them opinionated blocks rather than an open canvas. Do that and the CMS becomes something the client can actually run on their own, which is, after all, the entire reason they wanted a CMS instead of calling you every time a word needs changing.
