AI for Drafting Useful Form Error Messages
As of 2026-10-19 · the AZET team. We prepared this writing exercise for fun and reference. The form, validation rules, and messages below are hypothetical examples.
Something went wrong tells a reader almost nothing about what to do next. A longer message can be equally unhelpful if it invents a cause. When a form rejects an entry, the writing task is to communicate the information the product actually has and make the next available action understandable.
An assistant can help compare message drafts when you supply the underlying rule. It cannot determine that rule from a screenshot or decide what the application is able to recover. Start with a small error-state brief, then ask for wording that stays inside it.
Describe the state before drafting the sentence
Consider an imaginary workshop signup form with a display-name field. For this exercise, the fictional product team has chosen a limit of twenty characters. That is a supplied rule, not a recommendation for other forms. The form knows that an entry exceeds the limit and keeps the entry visible for editing.
The brief should include the field name, the observed condition, the action available, and what remains preserved. It should also list unknowns. If the system cannot distinguish a network interruption from another service problem, the writer should not confidently announce that the reader's internet connection has failed.
These details constrain the draft. A message saying Try a shorter display name fits the known condition. A message saying Your account is invalid introduces a different claim and may send the reader in the wrong direction.
Compare wording against one shared brief
Here are three fictional drafts for the same display-name state:
| Draft | Editorial assessment |
|---|---|
| Invalid value | Names neither the field nor the adjustment |
| Display name must use twenty characters or fewer | States the supplied limit |
| Shorten your display name to twenty characters or fewer | Adds a specific action |
The third version may suit this exercise, but the choice still depends on placement and surrounding text. If the message appears next to a clearly labeled field, repeating every noun might feel heavy. If it appears in a summary at the top of the page, the field name becomes more useful.
Ask the assistant to explain which pieces of the brief each draft communicates. That gives you a reason to choose a sentence beyond whether it sounds friendly.
Give the assistant a small writing contract
Try this prompt:
Write three error-message options using only the supplied state brief. Identify the affected field and an available next action. Do not invent a technical cause, a support channel, or a recovery promise. Keep the language calm and direct. Explain any uncertainty separately from the user-facing wording.
Supply your real constraints, including whether the interface can highlight a field or preserve an entry. If those behaviors are undecided, keep them out of the message. Copy should not quietly create a promise that implementation has not made.
Request a short and a fuller version when the design has different spaces. Compare the pair for meaning. A shorter message that drops the only useful action is not equivalent merely because both versions use the same tone.
Keep blame and unsupported reassurance out
You entered the wrong information places emphasis on the person. A more useful draft identifies the condition: Add a display name before continuing. The instruction is concrete and leaves the reader with an action.
Reassurance also needs a basis. Your work is saved is appropriate only if that state has been established. If the application has retained the text in the current view but has not saved it elsewhere, describe the narrower behavior accurately or omit the reassurance.
Avoid making every failure sound cheerful. A failed submission may require patience and clarity rather than a playful apology. Read the message while imagining the reader's immediate task: understand the issue, decide what to change, and know whether another attempt makes sense.
Test the wording with a simple reading exercise
Show someone the fictional field and message without explaining the intended action. Ask what they think happened and what they would do next. Record their answer in their words. This is a small comprehension check, not evidence that the wording works for every reader.
If they change the wrong field, inspect placement and labeling as well as the sentence. If they expect a missing action, check whether the text implied something the interface does not provide. Rewrite the brief when the problem is missing information; rewrite the message when the brief is clear but the words obscure it.
Finally, review several errors together. A form can become confusing when individual messages use different names for the same field. Keep a small terminology list and compare the actual visible states against it.
FAQ
Should every error include an apology?
No single wording fits every state. A missing entry may need a short instruction. A failed submission may merit acknowledgment. Choose words that explain the next step without burying it under repeated apologies.
Can AI infer validation rules from existing messages?
It can propose interpretations, but those interpretations need confirmation. An old message may be incomplete or outdated. Supply the actual approved rule before treating a new draft as ready for use.
Does this exercise test the form itself?
No. It reviews the relationship between a stated condition and its wording. Separately check that the implemented form detects the condition, displays the intended message, and handles the reader's next action correctly.
A writing exercise, with a dated product reference
These examples do not document an AZET form-writing capability. Our October 3, 2026 maker introduction describes an AI assistant and an early-access waitlist; it is a historical baseline rather than a live status check. For the AZET waitlist, visit azet.io.