A form can look finished while leaving the user with three questions: what goes here, why was it rejected, and did anything actually happen?
Those questions belong in the design. Form UX includes the instructions, the rules behind each field, and the way back when something fails. A clean default screen is only one part of it.
Ask for what the task needs
Consider a project enquiry form asking for a name, work email, phone number, company, website, budget, and description. It looks ordinary. But what happens to each answer?
If the first response goes by email, a required phone number needs a reason. Someone starting a business may not have a company name yet. Someone commissioning a new website may have no existing URL to share.
For this hypothetical enquiry, an email address and a project description could be enough to start. Other questions can be optional or asked later. That is a decision about this task, not a universal limit on form length.
Before adding a required field, write down which next step depends on its answer. If there is no clear dependency, reconsider making it compulsory.
Keep instructions visible while people answer
A label names the field. Help text explains what belongs in it. A placeholder can give an example, but it disappears as soon as someone types.
Project description
A long instruction placed only inside an empty field is gone when the answer begins.
What do you need help with?
Describe what you are building and what needs to change. A few sentences are enough.
Keep this text above the answer.
This is an illustrative comparison, not a screenshot from a client project. The point is to keep useful guidance available during the task. W3C's form instructions tutorial explains the problems with relying on disappearing placeholder text.
In implementation, associate the visible label with its control using matching for and id values. Additional guidance can be connected with aria-describedby. W3C documents the label association; the relationship needs to exist in the markup as well as the layout.
Validate the meaning, not just the format
One example from my work on a restaurant management interface was the opening-hours form. It needed to represent shifts that cross midnight. An end time earlier than the start time could be correct.
A rule that requires the end clock time to be later would reject this range. The form needs an explicit way to represent the next day before it can decide whether the answer is wrong.
That is the broader lesson: establish what valid information means in the business before writing the validation rule. A more polite error message cannot fix a rule that rejects legitimate input.
Write the repair into the error
“Invalid input” tells someone the system is unhappy. It gives them little to work with.
Upload failed
The user has to guess whether to rename the file, change its format, or try again.
Choose a file smaller than 10 MB
Useful only when the file exceeds a real 10 MB limit. The explanation must match the failure.
For a missing email address, “Enter your email address” is enough. For a rejected format, show an example. For an unsupported file, name the formats the service accepts.
Do not blame an answer for a service problem. A failed server request does not mean the user chose the wrong file. GOV.UK's error-message guidance separates errors people can correct in their answers from problems with the service.
Put the message beside the affected field. For a longer form, an error summary can help people find all the corrections. Link each summary item to its field and use the same wording in both places. GOV.UK's summary pattern also moves keyboard focus to the summary after failed submission.
For a short form, directing focus to the first invalid control may be enough. Test the complete sequence: submit, find the error, reach the field, correct it. A red border alone does not explain the repair.
Do not make correction mean starting over
Someone correcting their email address should not have to rewrite their project description. Preserve the answers when validation fails, including the answer that needs correction. GOV.UK explicitly includes this in its error guidance.
A service failure also needs a recovery path. “We couldn't send your enquiry. Your answers are still here. Try again.” is appropriate only when the application knows the request was not accepted and really has retained the answers.
A timeout is different. The server might have accepted the request before the connection failed. The interface should communicate that uncertainty, and the retry behavior should account for possible duplicate submissions.
File inputs and sensitive fields need their own handling. If a file has to be selected again, say so. Preserving ordinary text does not require storing every answer indefinitely.
A click is not a confirmed result
Design the states around the action, not just the button's default label. The examples below describe an enquiry, not a confirmed booking or a completed payment.
01ReadySend enquiry
The action is available. Required information and instructions are visible.
02SendingRequest in progress
Acknowledge the attempt. Avoid inviting repeated submissions while the request is pending.
03Needs correctionAnswers remain in place
Identify the affected fields and explain how to fix them.
04Service failure or uncertaintyExplain what is known
Distinguish a confirmed rejection from an unknown outcome. Give a recovery action the system can support.
05AcceptedYour enquiry has been sent
Show persistent confirmation after acceptance. Add a response-time promise only when there is a real process behind it.
W3C's notification guidance covers feedback for both errors and successful completion. The product still has to define what completion means. Receiving a request and confirming a booking are different outcomes.
Review the failure path on a phone
Try a long answer with the keyboard open. Submit with a required field missing. Correct it. In a test environment, trigger a service failure and check the recovery.
- Can you still see the labels and instructions?
- Does focus move somewhere useful, with the field visible above the keyboard?
- Do long errors fit without sideways scrolling?
- Do answers survive correction and retry?
- Does the confirmation stay visible?
Repeat the flow with a keyboard, and check error announcements with the assistive technology the product supports. These are review steps, not a complete accessibility audit.
A form is ready for handoff when the team agrees on what it asks, what counts as a valid answer, what survives a failure, and what confirms completion. Those decisions deserve as much attention as the first screen.
Conversation
Discussion
Loading comments…