Website error messages belong to a task the customer still wants to complete. “Something went wrong” does not explain whether to correct an address, choose another time or check the result of the previous attempt. Identify the failure type first, write the message next and then check the recovery route. For a contact form and other actions, it also matters whether entered information remains available and whether the customer understands the current state of their request.
Separate field errors, state changes and missing confirmation
A field error means a specific value needs correction, such as an address format. A state change means previously valid data can no longer complete the task because another person took the time or an object was removed. A missing server confirmation creates a different uncertainty: the operation may have been saved even though the screen did not display the result. These situations need different next steps and should not share one message with an identical retry button.
Take one frequently used screen and ask its feature owner to classify the application’s actual responses into these categories. Do not infer the cause solely from a notification colour or the user’s description. If the failure affects a particular group, also check technical conditions using the approach to errors affecting some users. A recording of the journey shows interface behaviour, but cannot replace confirmation of the operation’s result on the server.
Establish what survived before promising another attempt
A message should explain what remains of the customer’s work, based only on verified behaviour. If the fields really remain filled, you can write “Your other details are still in this form”. If the application does not retain them, do not add that reassurance merely to soften the message. Check a single-field rejection, rejection of the entire task and an interrupted connection separately, because they may leave the form in different states.
Before offering a retry, also establish whether the operation might already have completed. Checking a booking’s current status may be safer than selecting the same button again. Describe that route in customer language rather than asking someone to interpret an internal error code. Preventing duplicates is the feature owner’s responsibility; neither message copy nor an analytics tool guarantees that another attempt will not create an additional record in the application.
Write a message that leads to the right action
A useful message names the problem, explains the change required and offers an action consistent with the actual state. For an address error, an example of the expected format beside the field may be sufficient. For a time already taken, customers need the available times rather than encouragement to resend the same values. The table provides messages for a fictional booking flow that should not be copied without checking your own application’s behaviour.
Scroll the table sideways to see all columns.
| Problem type | Example message | Appropriate recovery |
|---|---|---|
| Field | Enter an email address in the form name@example.com. | Correct the named field without losing other values |
| Task state | This time has just been taken. Choose another time. | Return to the current list of available times |
| Unconfirmed server result | We cannot confirm the booking right now. Check its status before trying again. | Check the actual record and avoid a duplicate |
Avoid “Error 500, please try again” when customers cannot determine what happened to the previous operation. Clearer wording could be: “We cannot confirm the booking right now. Open your booking list and check whether the time was saved before starting another attempt”. This is appropriate only if that list provides a reliable status check. Without such a route, prepare another way to establish the result rather than inventing a button that leads nowhere useful.
Check the message beside the field and in a summary
A message beside a field helps customers correct a value without searching the whole page. Where several errors occur, a summary can identify the changes required, provided it leads to the relevant locations. Check that the field name is unambiguous and the wording stays visible when correction begins. Do not identify errors solely through a border colour, because some readers cannot recognise its meaning or learn the required action from it.
Walk through the form using a keyboard and check the route to the correction and the visibility of the focused element. Also test the notification with assistive technology where it is available in your product verification process. A recording of pointer movements alone cannot establish that a screen reader announced the message correctly. Connect this check with work on accessible contact routes, while keeping this article focused on recovering a task after an error.
The W3C form notifications tutorial recommends clear messages explaining errors and how to correct them, as well as successful completion. The following examples are editorial proposals for the situations described.
Reconstruct the actions after the notification
The analysis should include the moment before the failure and actions after the message appeared. In available recordings, mark the selected action, notification, correction attempt and final screen state. Do not assume closing a notice proves the text was read, or that a lack of another click means the customer rejected the service. Compare several journeys to find a recurring recovery problem, such as repeated submissions without correcting the named field.
Follow the principles of session recording analysis and record the limits of the sample and capture coverage. Field contents may be masked, so do not guess the entered value from the customer’s movements. Confirm a particular failure through a controlled test or appropriate technical data without exposing personal information. A recording points to a place worth checking; it is not a log of every server response and will not reveal every underlying cause.
Connect correction with confirmation of completion
Following a successful correction, customers should recognise that the task is complete and know what happens next. If the application confirms a submitted request, state the achieved status rather than leaving empty fields as the only signal. Do not equate selecting a button with an accepted operation. For measurement, use a defined goal triggered by the appropriate application confirmation where it has been integrated; the analytics tool does not infer the meaning of any arbitrary click.
When reviewing results for several address variants, establish whether they describe the same screen first. The article on URL parameters in reports helps prevent failures being scattered across apparently different pages. In Meetlead analytics, examine the available recordings and journeys, and confirm the outcome’s meaning in the application performing the task. Begin with one failure type and one correction whose subsequent route you can actually observe.
Questions about website error messages
Is changing “Something went wrong” enough? No, if the proposed recovery is still unavailable or loses the customer’s work. Establish the operation and data state first, then match the text and action to it.
Check the whole route from the notification to completion confirmation. Good copy helps people use a working recovery process, but does not replace fixing a broken one.
Will recordings show every form error? No, their scope depends on session capture, data coverage and page behaviour. They may show a visible notification and reaction, but do not establish the cause or saved operation on their own.
Supplement the review with a controlled attempt and appropriate application evidence. An error missing from the recording sample is not proof that it never occurs.
