How to model content in Sanity so a marketer can actually use it
The schema is only half of a content model. The other half is what the editor sees when they open the Studio on a Tuesday afternoon.
Most writing about content modeling is about the schema: what the types are, how they relate, which fields are structured. That matters, and I've written my version of it for healthcare sites in chapter 3 of the migration playbook. But a correct schema can still produce a Studio that a marketing coordinator opens once, can't make sense of, and never opens again.
This post is about the other half: the same model, seen from the editor's chair. The test at the end is the one I run before every handover.
What does the editor see first?
The Studio's left-hand structure, and it should be organized by what the editor thinks about, not by what the developer named the types.
Sanity's default is a flat list of every document type in alphabetical order. That's a developer's view. An editor at a health system thinks in terms of patients, providers, and the site itself, so that's how I group the structure: a Patients group with pages and posts for that audience, a Providers group with the referral-facing pages, and a Site group with providers, locations, services, FAQs, legal pages, redirects, and one settings document. Singletons (settings, navigation) open directly instead of showing a list of one.
Naming matters more than it seems. "Service" is clearer than "offering", "Location" than "facility", and the plural in the list should match what the team calls the thing in meetings. If the schema type has to be called something else internally, the title in the Studio doesn't.
How many fields should a document have?
As few as the site actually renders, and every one of them with a description.
A provider needs a name, credentials, a title, specialties, a headshot, whether they're accepting patients, a short bio, and the locations they work at. That's eight fields and the editor can see all of them without scrolling. When a document has thirty fields, half of which were added "in case", the editor stops reading and starts guessing which ones matter.
Each field's description answers two questions: what goes here, and where it shows up. "As it should appear on the site, without credentials. e.g. Priya Raman." "Used in cards and as the default meta description." That second half is the one developers skip and editors need most, because the alternative is publishing and looking.
Group fields into tabs when a document has more than one job: content, medical review, SEO. The editor writing a service page shouldn't have to scroll past the reviewer fields to reach the body.
Which fields should be structured, and which should be prose?
Structured for anything that renders in more than one place or feeds something a machine reads. Prose for the article body and nothing else.
Hours are the example I use. "Mon to Fri, 8 to 5" in a text field looks fine on the location page. Then the site needs the hours in the structured data that gets a clinic into the map results, and the text can't be parsed reliably, and a developer is rewriting the field while the editor re-enters every location. Days, opens, closes, as three fields per row, costs the editor ten more seconds per location and never has to be redone.
The same logic applies to a phone number (display text, dialable link derived), credentials (a separate field, not part of the name), and the reviewer of a clinical page (a reference to a person, not a typed name). Rich text is for the body of a post or a service description, where the editor needs paragraphs, headings, links, and lists, and where the site renders it in exactly one place.
How do you stop editors from breaking the design?
By making the schema unable to express a broken design, so the editor never has to be told not to.
Page-builder sections have fixed layouts: a hero, a text block, a list of cards, a set of FAQs, a providers list. The editor chooses which sections and in what order, writes the content, and the design system renders it. There is no font size picker, no colour field, no "custom HTML" block. Images require alt text. Navigation is capped by validation at six links and one button per audience, because the header was designed for six and the seventh breaks it on a phone.
Editors don't resent this. What they resent is a system that lets them make a page look wrong and then blames them for it. Constraints that match the design are the thing that makes an editor confident.
What should be automatic?
Everything that has one right answer.
Slugs generate from titles. The meta description falls back to the summary. The publish date is set when the document is published. The byline comes from the author reference; the review line comes from the reviewer reference and date. Structured data for a provider, a location, or an FAQ comes from the fields; the editor never sees the word "schema". Redirects are documents an editor can add, and the site compiles them at build time.
Every one of these removes a step the editor would otherwise get wrong occasionally, and "occasionally" across two hundred pages is a lot of wrong.
How do you know it works?
Run the handover test before launch: a new editor, with the written guide and no help, adds a provider, adds a location, links the two, and publishes a page that lists them.
If they finish without asking a question, the model works. If they ask one, that's a field description to fix. If they ask three, the structure is wrong and it's cheaper to fix it now, before two hundred documents are in it, than to explain it in every training session for the next three years.
The schema I use for this is public in the Healthcare Sanity Starter; the Studio structure, field descriptions, and validation rules there are the ones this post describes.