Field-level help text that prevents mistakes
Help text is pre-emptive support
Field label: "Meta description"
Bad help text: "Enter the meta description for this page."
Good help text: "140–155 characters. Shown in search results. No HTML. Example: 'Compare pricing, features, and setup time for lightweight project trackers built for teams under ten.'"
The bad version wastes space restating what the label already said. The good version specifies format, sets boundaries, and demonstrates tone and structure with a concrete example.
Help text should answer the questions people ask right before they make a mistake.
Show the format explicitly
Ambiguity creates support requests. If a field expects a specific format, say so.
"Publish date" — bad help.
"Publish date: YYYY-MM-DD (e.g., 2025-03-15). Future dates will schedule the post." — good help.
Don't assume users know whether you want slashes or dashes, month-first or day-first, or what happens if they pick tomorrow. Eliminate the guesswork.
Explain what the field controls
Some fields affect things outside the immediate page. Help text should make those consequences visible.
"URL slug: appears in the address bar and in links. Changing this after publishing breaks existing links unless you set up a redirect."
Now the editor understands scope and risk. They know this isn't a cosmetic choice.
State the constraint and the reason
If there's a character limit, explain why it exists.
"Page title: 60 characters max. Search engines truncate longer titles in results."
The reason matters. It shifts the rule from arbitrary to purposeful. Editors are more likely to comply when they understand the system they're working within.
Provide format examples for ambiguous fields
"Author byline" could mean anything. Help text should show what good looks like.
"Author byline: First Last, Title (e.g., 'Jordan Kim, Senior Editor'). Appears at the top of articles and in article metadata."
One example eliminates hours of inconsistency across contributors.
Differentiate similar fields
If your CMS has both "excerpt" and "meta description," editors will confuse them. Help text should clarify the distinction.
"Excerpt: 1–2 sentences. Displays on archive and category pages. Can include emphasis or links."
"Meta description: 140–155 characters. Plain text only. Shown in search results and social shares."
Now the difference is explicit. Editors know which field to prioritize and what formatting is allowed where.
Link to docs for complex fields
If a field requires knowledge of a system—taxonomy rules, embed codes, schema markup—help text should link to internal documentation.
"Schema markup: JSON-LD structured data for search engines. See [our schema guide](#) for supported types and examples."
Don't try to teach the entire system in help text. Point to the resource and keep the inline help focused on the immediate task.
Review help text when you review content
If you're getting the same support question repeatedly, your help text failed. Treat recurring questions as bugs in your field documentation.
Every support request is an opportunity to improve help text so the next person doesn't need to ask.