Pick one form you are preparing. Imagine someone has filled it in, tried to continue and received “Something went wrong.” What can they change from that instruction?
Your task is to write a useful correction for each known field problem. Finish with a small message plan: the condition, the words to show, the field they belong to and what should happen after the correction.
Work through the fictional photography-workshop enquiry below, then use the worksheet for your form. These are proposed messages and behavior. No form has been built or tested, and the exercise establishes no ClickFunnels AI validation or delivery feature.
Start with a rule the form actually has
Take the existing field plan. Identify which answers are required, which formats the receiving process accepts and which questions appear only after a particular choice. Confirm those rules with the person implementing or owning the form.
Do not invent a restriction just to write a neat error. If the process accepts an uncertain answer, that uncertainty should not become a fault. An optional field left blank should remain optional.
For a known field problem, write three short notes: what condition occurred, what the person can change and what the system knows. If the system cannot tell which field needs correction, you do not yet have a basis for a specific field error.
W3C's form-notification guidance recommends concise explanations that identify the relevant control and help someone resolve the problem. That gives this exercise a useful direction: name the question and the next useful action.
Work from a small fictional form
Imagine a studio receiving enquiries about team photography workshops. It has already chosen these requirements for its draft:
-
Email for our reply: required. A missing address and an address missing an
@sign are different conditions the fictional process can identify. - What would you like to practise? Required choice: Product photos; Team portraits; Something else; Help me choose.
- Describe the other topic: required only when Something else is selected.
- Company name (optional): can be left blank.
These are invented requirements, not recommended fields for every business. “Help me choose” is an acceptable choice in this example. It does not require an answer to the conditional other-topic question.
The task is an enquiry. Passing these field checks would not prove that a request was saved, an email arrived or a workshop was booked.
Replace four unhelpful messages
Scroll horizontally to compare all columns.
| ID | Known condition | Unhelpful wording | Proposed field message |
|---|---|---|---|
| E01 | Email for our reply is empty | Required field | Enter an email address for our reply |
| E02 | Entered email is missing an @ sign |
Invalid email | Add an @ sign to the email address for our reply |
| E03 | No practice topic is selected | Selection error | Choose what you would like to practise, or select Help me choose |
| E04 | Something else is selected and its description is empty | Tell us more | Describe the other topic you want to practise |
Each message uses the field's language and gives a correction. The email messages are different because the known conditions differ. E02 is appropriate only when that particular problem has been identified; do not use it for every address the system refuses.
Avoid claiming that a corrected address exists or belongs to the visitor. A format check cannot establish either fact. Also avoid guessing a replacement address. The person needs to provide their intended address.
GOV.UK's error-message guidance recommends plain, specific wording aligned with the question. It also distinguishes correctable input problems from service or permission problems. Those are useful design principles here, not evidence of a supplied CFAI component.
Read one of your messages aloud. Does it sound like a practical instruction? If it merely names an internal error code, write what the person can do instead. Keep the underlying technical detail in the implementation record.
Keep the overview and field messages together
Suppose the fictional visitor leaves Email for our reply empty, chooses Something else and leaves Describe the other topic empty. The proposed error overview would contain two entries:
- Enter an email address for our reply
- Describe the other topic you want to practise
Use those same messages beside their respective fields. Each overview entry should lead to the relevant answer. GOV.UK's error-summary pattern describes matching wording and links back to the affected inputs.
This plan gives the implementer two exact pairs to connect. It does not establish working focus movement, an announcement or an association with the control. Ask for those behaviors to be checked in the rendered form, including the keyboard and assistive setup being evaluated.
Do not rely on a red outline alone to explain the correction. Someone should be able to understand which question needs attention from the message itself. Keep unrelated answers available where appropriate instead of asking the person to start the entire enquiry again.
Follow one correction through the form
Now imagine the visitor supplies an address accepted by the fictional format rule. On the next validation pass, E01 should no longer appear. E04 remains because its condition is still true.
Next, imagine the visitor changes Something else to Help me choose. Under the stated rules, the other-topic description is no longer required. E04 should no longer block the form or remain in the error overview.
That second step is easy to miss when writing a list of messages. A conditional question needs a condition for removing its error as well as showing it. Record the selected option and the rule, rather than asking an implementer to infer them from the wording.
The optional Company name field stays blank throughout this fictional walkthrough. It should not acquire an error simply because the other fields are being checked. What happens to any previously entered other-topic text after a choice changes is a separate handling decision for the owner; this exercise does not promise it is saved or deleted.
All of these are expected behaviors in a plan. Mark their implementation checks NOT RUN until someone performs an authorized check and records the actual result.
Set aside problems the visitor cannot correct
Suppose the studio has stopped accepting enquiries for a workshop. A person cannot solve that by repeatedly rewriting a correctly entered email address. That needs an accurate explanation of the service's availability and an available next step, owned by the business.
Likewise, an unknown save result should not be disguised as E01, E02, E03 or E04. Do not tell someone to resubmit blindly when you cannot establish what happened. Record the missing result or recovery decision for the responsible person. Post-submission status and confirmation copy need their own plan.
This boundary keeps the error worksheet small. It contains field corrections the system can justify, not every possible failure in the journey.
Finish one message record
Choose the most confusing current field message. In the form-error copy worksheet, record its exact label, known condition, proposed wording, overview entry and condition for clearing it. Include the rule source and owner so the plan can be checked against the real form.
Then prepare one permitted check of that correction. Record the form version, starting choice, message shown, answer retained and what happens after the correction. Use safe test information and an authorized environment; avoid triggering a real customer workflow merely to review copy.
For a ClickFunnels AI project, keep this plan with the agent guide and its access requirements. The wording is an input to implementation, not proof of working validation or an accessibility certification. You have a useful next task when one known problem has a clear correction and an honest check status.