Ask what a field is for
One question, asked of every field before it exists, does most of the work in our content modelling: who reads this value, and when? Here is why it matters more than it sounds, the index-card exercise we built around it, and what ends up in the pile.
Every content model I have inherited has a field called something like extra_info. It is a long text box. Nobody remembers who added it. On some entries it holds a phone number, on others a disclaimer, on one a recipe for banana bread. It cannot be removed, because someone, somewhere, might be using it.
extra_info is what happens when a field is added because someone needed somewhere to put something. My job, more or less, is to stop that happening, and I do it by asking one question, over and over, until people are sick of me:
What is this field for?
For whom, and when
"What is it for" sounds like it has an obvious answer. It rarely does. The useful answers name two things: who will read the value, and when.
Take a field called summary on an article. Ask what it is for and you will hear "a short description". Push a little:
Is it read by a person deciding whether to click, on a card on the home page? Then it needs to make sense without the title, and it should be short enough to fit two lines.
Is it read by a search engine, in a meta description? Then it has a different length, and probably a different tone.
Is it read by someone scanning search results inside the site? Then it should repeat the words people search for.
Three readers, three moments, three different fields that all called themselves summary. Sometimes one value can serve all three. Often it can't, and the editor who writes it is quietly trying to do three jobs in one box, and doing all three a bit worse.
When the answer is "it's for the page", I keep asking. Pages are not readers. Which part of the page, seen by whom, doing what?
The exercise
We run a workshop that is mostly this question, applied with index cards. It goes like this:
Pick one thing. One real thing the organization publishes. An article, a product, an event. Not "content" in general.
Write every field on a card. Everything people say the thing has. Don't argue yet. Twenty minutes, usually forty cards.
Interrogate each card. For every card, the group answers: who reads this value, and when? Write the answer on the back. If nobody can answer, the card goes in a pile in the middle of the table.
Look at the pile. This is the interesting part. Some cards in the pile are fields nobody needs. Some are two fields pretending to be one. And some turn out to be an entirely separate thing, with its own fields, that the original thing should point to.
That last case is the one that changes models. The classic example is the author. Teams start with author_name as a text field on an article. Then someone asks for a photo, so author_photo appears. Then a bio. Then a link. Five fields in, the article is describing a person, badly, and the same person is typed out slightly differently on every article they wrote. Ask what author_bio is for, and the answer is "to tell readers about the person". The person is a thing. Give them a card of their own.
What it isn't
It isn't a way to keep models small for the sake of it. Sometimes the answer to "what is this field for" is very good, and the field stays, and is better for having a written reason on the back of its card. We keep those reasons, by the way. They become the help text editors see under each field, so the question gets answered once and stays answered.
It also isn't a way to win arguments. The question is just as useful when it is asked of a field I wanted. Last year a client asked me what my lovely tone_of_voice field was for, and the honest answer was "so I would feel better". It went in the pile.
Coming up
We are about to start a project where this question will get a real workout. The client keeps their entire collection on index cards, in six oak drawers. I have been told that each card has eleven typed lines, and that the best content is written in pencil on the back. I can hardly wait.
