Make a signup error useful by naming the field, explaining the problem, and showing the next action. Keep valid entries in place and test the path from a failed submission to a successful one. The recovery path deserves its own review before you send more traffic to the page.
A form can look finished when every test uses correct input. The more revealing test starts with a mistake.
Write the correction before styling the error
For a fictional workspace signup, imagine that the visitor enters a workspace name with spaces, but the product needs a short URL segment. A red border alone does not explain the rule.
A useful message could say: “Use letters, numbers, and hyphens for your workspace address.” Only use that wording if it matches your actual rule. Show the rule before submission too, so the visitor has a chance to get it right.
W3C's form notification guidance recommends clear error descriptions with instructions for correction. It also describes linking an error summary to the affected controls.
Use the same field name in the label and message. A visitor should not have to work out that “tenant identifier” means the field labelled “Workspace address.”
Connect the message to the field
The error should be available to people using assistive technology. W3C shows how aria-describedby can associate a field with its error message. Here is a small markup example for an error that has already been found:
<label for="workspace">Workspace address</label>
<input
id="workspace"
name="workspace"
value="my team"
aria-describedby="workspace-error"
>
<p id="workspace-error">
Use letters, numbers, and hyphens for your workspace address.
</p>
This snippet shows the relationship between a field and a message. It does not validate input or implement the full submission flow. When you change the message, keep that relationship intact and test what is announced in the finished interface.
Let the browser help, then check the server
Start with HTML controls and constraints that match the data you need. For example, required marks a mandatory field, and type="email" provides an email-format check. MDN's form validation guide explains these built-in features and when JavaScript can add custom behavior.
An email-format check does not establish that someone owns an address. Also, browser checks can be bypassed. MDN recommends validating submitted data on the server as well.
Keep the two layers consistent. If the browser accepts a workspace address that the server rejects, show the server's reason in language the visitor can act on.
Test recovery as a complete task
Use a few deliberate scenarios in your review:
- Leave a required field empty, submit, and correct it.
- Enter an address that fails the product's real format rule.
- Submit a valid form while the service is temporarily unavailable.
- Correct one field and check that the other valid entries remain.
- Complete the same task using the keyboard.
For each scenario, record the starting input, the response, and the next action. Do not record real passwords or customer data in a shared test note.
A service failure needs a different message from invalid input. If the server cannot respond, telling the visitor to “check your details” sends them toward the wrong repair.
Confirm the actual next state
After a successful submission, explain what happened. If an account exists, say so. If the visitor still needs to confirm an email address, explain that step. W3C includes success feedback alongside error feedback because both tell the user whether the task is complete.
Review the words against the product's real behavior. A clear success message is the last part of the same recovery path: the visitor should know when they can stop fixing the form and move on.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)