Designing content models editors actually enjoy
Good content models read like the way your team talks. Here is how we design them.
Daniel Okafor2 min read
Most CMS projects fail quietly. The site launches, the team publishes for a month, and then everything goes back to the engineers because editing is slow, confusing or risky. The cause is almost always the content model.
Start with the people who publish
Before we draw a single schema, we sit with the editors. We watch how they work today, collect the documents they already write, and note the words they use. If the marketing team calls them “customer stories”, the schema should not call them “case studies”.
- Shadow two or three publishing sessions before you design anything
- Collect real content, not lorem ipsum, to test every field
- Write field descriptions in the team’s own language
Model the content, not the page
Pages change every quarter. Content lasts years. We model the durable things, such as people, products, customers and ideas, as documents, and use a small page builder to arrange them. That way a testimonial written once can appear on five pages and stay correct everywhere.
Constraints are a feature
A small set of well-designed blocks beats an endless toolbox. Fewer choices mean faster publishing and a site that stays coherent over time. NexSanity ships with sixteen blocks, and most pages only need five of them.
Good systems disappear. Editors should think about the story, not the software.
Validate early, in the Studio
Validation rules are documentation that cannot go out of date. Required alt text, sensible length limits and helpful warnings catch problems while the editor is still thinking about them, not after a page goes live.
What we measure
We track time to publish, the number of pages shipped without engineering help, and how often editors ask for support. When those numbers move the right way, the content model is working.
Written by
Daniel Okafor
Engineering Lead
Daniel builds the systems behind our sites, from content models in Sanity to performance budgets in Next.js. He has shipped more than sixty production sites and still reads every Lighthouse report.
