Plan for what happens after the click
A website interaction does not end when someone presses a button. A visitor might submit an enquiry, request a download or save a preference, then wait while the site responds. If nothing visibly changes, they may wonder whether the action worked and try again. Clear feedback answers three questions: Is something happening? Did it work? If not, what can I do next?
Start by listing the important interactions on a page. For each one, sketch its normal state, loading state, success state and likely error states. A small organization might begin with its contact form, newsletter sign-up and event registration. You do not need a separate visual design for every possible failure, but you do need a useful response when an expected action cannot finish.
Make loading states informative, not distracting
Loading feedback should appear close to the action that caused it. After someone submits a contact form, for example, the button might change to “Sending…” while a short message says, “Sending your message.” Keep the entered information visible so the visitor does not think it has disappeared. If the action can take a while, explain that it is still in progress rather than leaving a spinner to do all the communicating.
Decide what should happen if someone presses the button again during loading. Temporarily preventing duplicate submissions can be helpful, but the interface should still make clear why the button is unavailable. Do not replace the entire form with a blank panel or animate unrelated parts of the page. A loading state is most useful when it preserves context and signals that the site has received the request.
Confirm success with a useful next step
A success state should describe the completed action, not merely display a green tick or the word “Success.” For an enquiry form, “Your message has been sent” is clearer than “Done.” If it is appropriate and reliable, add what the visitor can expect next, such as “You can return to the services page.” Avoid promising a response time unless the organization can consistently meet it.
Match the confirmation to what actually happened. A file being uploaded, a registration being received and a payment being completed are different outcomes. If an action only starts a process, do not suggest the whole process is finished. Keep the confirmation visible long enough to read, and consider whether a visitor returning to the page needs a persistent record of the result.
Write errors that help people recover
An error message should explain the problem in plain language and offer a practical next action. If a required email field is empty, place a message beside it such as “Enter your email address.” If the form could not be sent, explain that the submission did not complete and invite the visitor to try again. Where possible, preserve their entries so they do not have to start over.
Distinguish between errors a visitor can fix and problems with the site. “Choose a date” is useful when a date is missing; it is not useful when a server fails. For a general failure, provide a way forward, such as retrying or using another published contact method. Avoid exposing technical error codes as the only explanation, and never imply that the visitor caused a problem when you do not know the cause.
Check clarity and accessibility across the whole journey
Do not rely on color alone to communicate a state. Use clear text, and connect field errors to the relevant fields so visitors can locate and understand them. When content changes after an action, check that people using assistive technology can discover the update without losing their place. Keyboard focus should move only when there is a good reason; for example, moving it to a confirmation heading may help after a form has been replaced by a success message.
Test the interaction as a sequence, not as isolated screens. Submit an empty form, correct one field, submit again, wait for feedback and confirm the result. Repeat with a keyboard, a narrow screen and a slow connection if you can. Ask a colleague unfamiliar with the page what they think happened at each stage. Their hesitation can reveal where a short message or more predictable behavior would make the experience clearer.
