Sanity Studio for People Who Don't Read Docs

I tried reading the Sanity documentation. I really did. About four paragraphs in, somewhere around "content lake" and "structured content," my eyes glazed over and I closed the tab. If you've had the same experience, this article is for you.

This is the guide I wish I'd had: Sanity Studio explained by someone who doesn't write code, doesn't read docs, and still managed to build a working content system. With a lot of help from Claude Code, obviously.

You don't need to understand how the engine works to drive the car. You just need to know where the steering wheel is.

What Sanity Actually Is

Let's start with the basics. Sanity is a headless CMS. That term sounds complicated, but it's simple: it's a place where you write and organize your content, separate from the website that displays it.

Think of it like Google Docs but for your website's content. You write things in Sanity, and your website pulls that content in and displays it with your design. The "headless" part just means the writing tool and the website are two separate things. WordPress is like a head glued to a body — Sanity is just the body. You bring your own head.

Why does this matter? Because you can change your website's design without touching your content, and update your content without touching your code. They're independent. That separation turns out to be incredibly useful.

The Spreadsheet Mental Model

Here's the mental model that made everything click for me: schemas are like spreadsheet column headers.

When you create a spreadsheet for, say, tracking articles, you set up columns: Title, Author, Date, Category, Body Text. Those column headers are your schema. Each row is a document. That's literally what Sanity schemas do — they define what fields your content has.

The difference is that Sanity gives you much richer "column types" than a spreadsheet. Instead of everything being a text cell, you can have date pickers, image uploaders, rich text editors, dropdowns, references to other documents, and more. But the concept is the same: define the structure, then fill it with content.

Your First Document Type

Let's say you want to create a blog. You need an "article" document type. Here's what the schema looks like:

// schemas/article.js
export default {
  name: 'article',
  title: 'Article',
  type: 'document',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
    },
    {
      name: 'author',
      title: 'Author',
      type: 'string',
    },
    {
      name: 'publishDate',
      title: 'Publish Date',
      type: 'date',
    },
    {
      name: 'category',
      title: 'Category',
      type: 'string',
      options: {
        list: ['Tutorial', 'Opinion', 'Case Study'],
      },
    },
    {
      name: 'body',
      title: 'Body',
      type: 'blockContent',
    },
  ],
}

Read it line by line. It says: "An article has a title (text), an author (text), a publish date (a date), a category (chosen from a list), and a body (rich text)." That's your spreadsheet column headers. Sanity Studio then generates a beautiful editing interface from this definition — no design work required.

Getting Claude Code to Write Schemas

Here's the part that changed everything for me. Instead of learning schema syntax myself, I describe what I want to Claude Code and it writes the schema for me. The conversation usually goes like this:

Me: "I need a schema for portfolio projects.
     Each project has a title, a short description,
     a cover image, a list of tags, a client name,
     and a rich text body for the case study."

Claude: [generates the complete schema file]

Me: "Add a 'featured' toggle so I can mark
     certain projects to show on the homepage."

Claude: [adds a boolean field to the schema]

That's it. I describe it like I'm explaining it to a colleague, and Claude Code handles the syntax. If the Studio throws an error, I paste the error back to Claude and it fixes it. This is how non-technical people build real systems now.

GROQ: Asking Questions About Your Content

Once your content is in Sanity, you need a way to get it out and display it on your website. That's what GROQ does. It's Sanity's query language, and it's genuinely simpler than SQL if you've ever encountered that.

Here's a plain English query and its GROQ equivalent:

// "Give me all articles, newest first"
*[_type == "article"] | order(publishDate desc)

// "Give me only tutorials"
*[_type == "article" && category == "Tutorial"]

// "Give me the 3 most recent articles,
//  but only their titles and dates"
*[_type == "article"] | order(publishDate desc) [0..2] {
  title,
  publishDate
}

The * means "everything." The square brackets are your filter. The curly braces say which fields you want back. The pipe | chains operations together. That's the entire language, practically speaking.

You can test GROQ queries live in Sanity's Vision tool, which is built into the Studio. Type a query, see the results instantly. It's the most satisfying part of the whole experience.

Portable Text: The Rich Text Editor

This is the part of Sanity that most impressed me. The body content editor — called Portable Text — is not just a "bold and italic" text box. It stores your content as structured data, which means your content isn't locked into any particular format.

Write your content once in Sanity, and it can be rendered as HTML on your website, as native components in a mobile app, as plain text in an email, or as anything else you need. The content doesn't know or care how it's being displayed.

Content should be like water: it takes the shape of whatever container you pour it into. Portable Text makes your content water.

In practice, Portable Text is a rich text editor that feels like Notion or Google Docs. You write with formatting, add headings, insert images, create lists. The magic happens behind the scenes — it's all stored as clean, structured data instead of messy HTML.

The Schema Building Blocks

Once you understand the pattern, building schemas becomes like assembling LEGO. Here are the most useful field types:

• string — Short text. Titles, names, labels.
• text — Longer text without formatting. Descriptions, summaries.
• blockContent — Rich text with formatting. Article bodies, bios.
• image — Image upload with automatic CDN hosting.
• date — A date picker. Publish dates, event dates.
• boolean — A toggle. "Featured?" "Published?" "Show on homepage?"
• reference — A link to another document. "This article's author is [Justin]."
• slug — A URL-friendly version of a title. Auto-generated from the title field.

Here's a more complete schema that uses several of these:

// schemas/project.js
export default {
  name: 'project',
  title: 'Project',
  type: 'document',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: Rule => Rule.required(),
    },
    {
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: { source: 'title' },
    },
    {
      name: 'coverImage',
      title: 'Cover Image',
      type: 'image',
      options: { hotspot: true },
    },
    {
      name: 'description',
      title: 'Short Description',
      type: 'text',
      rows: 3,
    },
    {
      name: 'featured',
      title: 'Featured',
      type: 'boolean',
      initialValue: false,
    },
    {
      name: 'tags',
      title: 'Tags',
      type: 'array',
      of: [{ type: 'string' }],
      options: { layout: 'tags' },
    },
    {
      name: 'body',
      title: 'Case Study',
      type: 'blockContent',
    },
  ],
}

Notice validation: Rule => Rule.required() — that makes the title field mandatory. And options: { hotspot: true } on the image lets you set a focal point, so the image crops nicely at different sizes. These details matter when you're managing real content.

What's Next

This is Part 1 of a series. We've covered what Sanity is, how schemas work, and the basics of GROQ. In Part 2, we'll connect Sanity to an actual website — pulling content out and rendering it with HTML and CSS. No frameworks, no React, just straightforward web stuff.

The core idea to take away: Sanity is a place to store your content in a structured way, and schemas are just descriptions of what that content looks like. If you can describe it, you can build it. And if you can't write the code yourself, Claude Code can write it for you.

The best CMS is the one you actually use. Sanity becomes that CMS the moment you realize you don't need to understand all of it — just enough to start publishing.