Sanity Studio editor experience: why editors avoid it and the fix

If your marketing team avoids Sanity Studio and sends copy over email instead, the problem is rarely the CMS. It is almost always the Sanity Studio editor experience that a developer left at its defaults. The good news is that most of the fixes are configuration, not a rebuild.

This post is for owners of an existing Sanity site who keep hearing "I'll just send you the text." I will walk through the four causes I see most often, what ignoring them costs, and the fix for each, framed as before and after.

Symptoms that the Studio is the problem

You do not need a usability study. The signs are visible in how the team behaves:

• Content arrives in Google Docs, Notion or Slack and a developer pastes it in.
• Editors ask "where do I change the homepage hero?" more than once.
• Published pages contain placeholder text, missing alt text or empty SEO fields.
• Nobody wants to publish without a developer checking the live page.
• Two people created two documents for the same thing because the list was confusing.

Each of these is a process leak. Every time a developer is the middleman for a headline change, you are paying developer rates for a copy edit and slowing the campaign down.

What ignoring it costs

The cost is not a dramatic outage. It is a slow tax. Content updates queue behind engineering. Editors stop trusting the tool, so they stop learning it. Mistakes (broken slugs, missing images, overlong titles) reach production because nothing stopped them. Eventually someone proposes a CMS migration, when the actual issue was a Studio nobody designed for editors. I have seen "we need a new CMS" be the wrong diagnosis often enough that I check the Studio first. If you are weighing that, read what a web CMS actually owes you before spending money.

Cause 1: a flat schema and a cluttered desk

Before: Open the Studio and you see a left-hand list with every document type in alphabetical order: Author, Category, FAQ, Hero Variant, Page, Post, Redirect, Settings, Testimonial. Singletons like site settings sit next to repeatable content. Developer-only types appear alongside things editors actually touch. Inside a Page document there are forty fields in one long scroll.

After: The desk is organised around the questions editors ask: "Pages", "Blog", "Site settings", with developer-only types hidden. Settings open directly as a single document instead of a list of one.

The tool for this is Structure Builder. A minimal version:

// sanity.structure.ts
import type {StructureResolver} from 'sanity/structure'

const hidden = ['siteSettings', 'redirect', 'navigation']

export const structure: StructureResolver = (S) =>
  S.list()
    .title('Content')
    .items([
      S.listItem()
        .title('Site settings')
        .id('siteSettings')
        .child(
          S.document().schemaType('siteSettings').documentId('siteSettings')
        ),
      S.divider(),
      S.documentTypeListItem('page').title('Pages'),
      S.documentTypeListItem('post').title('Blog posts'),
      S.documentTypeListItem('author').title('Authors'),
      S.divider(),
      ...S.documentTypeListItems().filter(
        (item) => !hidden.includes(item.getId() ?? '') && !['page', 'post', 'author'].includes(item.getId() ?? '')
      ),
    ])

Pair it with a rule that singleton types are removed from the global "create new" menu, so nobody makes a second settings document. For deeper patterns see custom ordering and grouping in Structure Builder and hiding draft noise.

If the Studio itself feels slow because of years of abandoned types, the Studio bloat audit covers pruning.

Cause 2: long forms with no field groups

Before: Content, SEO, social sharing, layout options and internal notes are all in one vertical form. Editors scroll past fields they never use to find the one they need, and fear touching anything.

After: Three or four tabs: Content, SEO, Settings. Each field has a plain-language description. Rarely used fields are collapsed.

// schemaTypes/page.ts
import {defineField, defineType} from 'sanity'

export const page = defineType({
  name: 'page',
  title: 'Page',
  type: 'document',
  groups: [
    {name: 'content', title: 'Content', default: true},
    {name: 'seo', title: 'SEO'},
    {name: 'settings', title: 'Settings'},
  ],
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      group: 'content',
      description: 'Shown as the page heading and in browser tabs.',
    }),
    defineField({name: 'slug', type: 'slug', group: 'settings', options: {source: 'title'}}),
    defineField({
      name: 'metaDescription',
      type: 'text',
      rows: 3,
      group: 'seo',
      description: 'Aim for 120 to 160 characters. Shown in search results.',
    }),
  ],
})

Descriptions matter more than developers expect. A field called "eyebrow" means nothing to a marketer; "Small label above the headline" does.

Cause 3: no previews, in the list or on the page

Before: The document list shows rows named "Untitled" or only the title, so editors open five documents to find the right one. They publish blind and check the live site afterwards.

After: List items show title, status and a thumbnail through the schema preview config, and editors see the real page next to the form through the Presentation tool.

The list-level fix is small and worth doing for every type. Select the fields that identify a document and return a readable title, subtitle and media. For page-level previews, wire up draft mode and Presentation; I cover that in Sanity live preview with the Presentation tool. Editors who can see their change before publishing stop asking developers to check it. That single change removes most of the "send it to me" behaviour.

Cause 4: missing validation

Before: Titles run to 120 characters, images have no alt text, slugs collide, and CTAs link to nothing. Problems are discovered by visitors.

After: The Studio tells the editor what is wrong, in plain language, before publish. Required fields are marked as required, warnings are used for advice and errors for things that break the site.

// inside a defineField call
validation: (Rule) =>
  Rule.required()
    .max(60)
    .warning('Titles over 60 characters are usually cut off in search results.'),

Use errors sparingly. If everything blocks publishing, editors get frustrated and look for workarounds. Reserve errors for broken output (missing slug, missing alt text on content images) and use warnings for style advice. More patterns are in custom validation rules in Sanity and blocking duplicate slugs.

When a custom input is worth it

Custom inputs are the last step, not the first. Build one when an editor is repeatedly making a mistake a standard field cannot prevent: picking brand colours from a hex string, choosing from a long list of icons, or assembling a layout by typing JSON. A constrained picker removes the whole class of error. A walkthrough is in building a colour picker input. If a standard options.list or radio layout solves it, use that and skip the maintenance.

What to ask a developer

Whether you hire me or someone else, ask these before agreeing to a Studio clean-up:

1. Will you sit with two actual editors and watch them publish something before changing anything?
2. Which changes are configuration only, and which touch stored content and need a migration?
3. How will singletons, hidden types and role permissions be handled?
4. What is the plan for previews on staging, not just locally?
5. Who maintains custom inputs when Sanity Studio updates?

A good answer to the first question matters most. The right Studio is shaped by how your team works, not by a template. If you want help scoping this, my Performance & Sanity audit, from $800, includes a review of the editor experience alongside the technical findings.

Work I do

This kind of Studio clean-up, covering structure, previews, groups, validation and the occasional custom input, is work I do for teams on Sanity Studio v6 and Next.js 16. You can see how engagements are packaged on the services page.