Designing a schema editors can actually use

A schema is a design document that happens to be executable. The studio draws its form from it, so every decision in it is a decision about what an editor sees first, what they can skip, and which mistake they are going to make on a Thursday afternoon.

The form is the schema, read out loud

Titles, descriptions and placeholders are not decoration. A field called `summary` with no description is a field somebody fills in wrongly once and then copies wrongly forever. The twenty minutes it takes to write "two sentences, used in lists as written" is the cheapest documentation a content team ever gets, and it is attached to the thing it describes.

Groups matter more than order. Somebody filling in a post is doing two jobs — writing the thing, and filing it — and a form that puts the publish date between the intro and the body interrupts both. Two groups, named for the jobs, remove most of the scrolling.

Every optional field is a question. If you cannot say who answers it, it should not be on the form.

Four rules that hold up

• Put the field the editor writes first at the top, always, even when it is not required.
• Group by job rather than by type: content, then metadata.
• Use a picker for anything with a closed set of values, and a free string only when the value is genuinely open.
• Mark a field required only when an empty one breaks something you can name out loud.

None of that is specific to Achar. It is what editorial designers have known for a century, applied to a form that a machine also has to read — and the second reader is the reason it has to be written down rather than agreed.

The list a studio draws is the same schema, projected: a title, the field the type says names it, and the two fields worth sorting by.

*[_type == "post"] | order(publishedAt desc)[0...20]{ title, "author": author->name, publishedAt }