The right picture, delivered into the wrong rectangle
Resolution, crop and reserved space solve different image problems. Design all three around what the reader needs to see.
Engineering7 min read
The route back from a form error
Readable error text is only the beginning. Three failures show how focus, retained input and the next action complete the recovery.
The form is now asking for more work
Someone has typed the email, chosen a date and written the job description. Submit returns an error. Before they can continue, the page owes them an explanation of what happened to that work. A malformed address, a slot taken by another booking and an uncertain server save need three different next actions. The fact that all three can be displayed in red is not much help in deciding which one to offer.
That is why error design is more than choosing a friendly sentence and a sufficiently visible shade of red. The person needs to discover that submission failed, locate the relevant information, understand the correction and try again without losing the work already done. Those steps form a recovery journey. Good typography helps someone read it; it cannot supply a missing step.
Consider a fictional booking enquiry with three fields: email address, preferred date and a description of the work. We will follow three failures through the same page. First, the email lacks a domain. Second, the chosen slot becomes unavailable while the person completes the description. Third, the server cannot establish whether the enquiry was saved. These failures should not produce the same instruction, because the person has a different amount of control over each one.
I would follow the recovery the page offers, rather than stop after finding an error message. Can the person reach the relevant control, see the information they entered and understand what the next button will do? A keyboard, magnification and a few less cooperative server responses reveal more about that than the polished first screen. They turn the design into a task someone can actually finish.
Begin with the error the person can correct
For the malformed email, retain the entered address and describe the problem next to the field. “Enter an email address including a domain, such as name@example.com” gives a repair direction. Use the same field label in an error summary at the beginning of the form, with a link to the control. Someone who has scrolled through a long description should not have to hunt for the one border that changed colour.
W3C’s forms notification guidance recommends clear feedback, an overall error list and links to the relevant controls. Its validation guidance also distinguishes the convenience of browser checks from server validation. The browser can catch a missing part of an address before a round trip. The server still has to enforce the application’s requirements, including when scripting is unavailable or a request bypasses the page.
In a custom implementation, associate the field with its hint and error text, and mark the current invalid state programmatically. A label identifies the control; an error explains its present problem. One should not replace the other. Preserve a stable label after correction, clear an obsolete error and avoid leaving the field announced as invalid after the application has accepted the new value.
Choose a clear starting point for recovery. A labelled summary can collect several errors and link to their controls in a useful order. If the page also moves focus elsewhere, opens a modal and announces several messages, those individually helpful ideas can compete for the same attention. Test them together from submission through correction, so the person can follow one route rather than work out which of the page’s simultaneous instructions should win.
Follow the malformed email back to its control
The proposed keyboard recovery route for the booking enquiry’s missing-domain error.
Follow the labelled arrows. On a narrow screen, scroll sideways if needed.
A correct value can become unavailable
The preferred slot introduces a different failure. At the time it was selected, Tuesday at 10:00 was valid. Another booking took it before submission. Calling the field “incorrect” blames the person for a change they could not see. Explain what changed, retain the rest of the enquiry and offer currently available alternatives.
Keep the unavailable choice visible enough to explain the transition. If the application silently replaces 10:00 with 14:00, the page may submit a booking the person never intended to make. A useful response says that the original time is no longer available and asks them to choose again. Availability must be checked at the authoritative booking boundary; a refreshed list is helpful evidence, not a reservation by itself.
The summary needs to take the person to a clearly named date or slot group, with alternatives usable from the keyboard. If the page updates the list dynamically, decide how that change will be communicated as part of the same journey. Then test the focus and announcement behaviour in the supported browser and assistive-technology combinations. An attribute can express the intended relationship, but the person still needs to encounter and use the changed choices.
The interaction also depends on whether selecting a slot reserves it. A temporary hold could protect someone completing a long description, but requires an expiry policy and a clear explanation. A business that cannot reserve before confirmation can still offer a usable form, provided the interface presents the choice as provisional and explains when authoritative availability is checked. The wording needs to match that service contract.
Do not ask the person to repair the server
Now suppose the save request loses its response. The entered email and date may be perfectly valid. Adding red errors to those fields would send the person into a pointless editing exercise. The page needs to distinguish a rejected submission from an unknown result and an unavailable service.
When the service knows it failed before saving, it can say the enquiry was not submitted and preserve the draft for a retry. An unknown outcome needs a different operation: check the existing submission identity, if the service supports it. Starting again could duplicate an enquiry already accepted. The recovery button is where that systems distinction reaches the customer, so name what it will do rather than leaving three meanings inside Try again.
A durable enquiry reference can help a status page or support colleague find the existing attempt. An error number is useful only if it serves an equivalent investigative purpose. Give the person a safe way to copy the reference and an accessible contact route when automatic recovery cannot settle the outcome, so asking for help does not require submitting the same uncertain enquiry again.
Preserving input also needs judgement. Keep ordinary draft text through a recoverable validation failure, but do not place sensitive values in a URL, analytics event or indiscriminate log. Explain meaningful expiry or sign-in requirements before discarding a long draft. Recovery should not quietly create a second privacy problem in its enthusiasm to solve the first.
Three failures, three recovery contracts
A proposed review sheet for an illustrative booking-enquiry form.
Scroll sideways to see all columns.
| Failure | Keep visible | Next action |
|---|---|---|
| Email lacks domain | Entered address + specific field error | Correct the address |
| Selected slot was taken | Original choice + available alternatives | Choose another slot |
| Save result unknown | Draft + existing submission reference | Check existing outcome |
Review the whole return journey
A practical review can use a compact record for each of the three failures: what the server knows, what the screen says, where focus goes, which values remain and what the next action does. The distinction between a person’s correction, a new availability choice and a status check should survive that record. If every row ends in “try again”, the design has probably collapsed different states too early.
Walk the email case with a keyboard from submit to summary to field to resubmission. Then repeat at a narrow viewport and with enlarged text. Check whether a sticky header covers the destination, whether the error wraps beside its control and whether the summary remains visible long enough to use. The important observation is the path someone can complete, not whether the initial screenshot contains every required element.
Inspect server validation too. Submit a request without relying on the browser’s checks and confirm the response preserves the relevant draft and error association. Exercise the unavailable slot after the page has loaded. Exercise a failed response after a save. These are different points in the service lifecycle, so a single mock “error mode” cannot prove all three recovery routes.
The email case should lead back to a correctable address. The unavailable slot should lead to a fresh choice, with the rest of the enquiry intact. The uncertain save should lead to information about that same submission. Once those routes work, warm wording has something useful to explain. The person can continue with an accurate account of what the service kept, instead of spending another attempt discovering whether the original one succeeded.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotReferences & further reading
Primary sources behind this article. Living documentation may change.
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A few more things
worth a read.
Back to the reading room 
What does £240 belong to?
A readable table preserves relationships between values, row labels, column headings and actions across different ways of reading.
When two calculations agree on the wrong answer
A shadow comparison exposes differences. Independent rule examples explain whether those differences are bugs, corrections or changed assumptions.