Success Message UX, and the Screen Most Flows Forget

A success message tells people that what they just did has worked and what happens next, and I think good success message UX starts by matching the size of the message to the size of the action. The end of a flow, such as a booking, an order or an application, deserves a page of its own, a step in the middle of a journey takes a banner on the page which follows, and a routine save only needs the button to change its label to Saved. The flow designs which reach me mostly stop at the submit button, so the screen which tells people they are done is left for the developer to invent, and on one app’s sign-up flows the file had a single shared All set screen at the very bottom, which each sign-up path then needed as its own last screen.

This post goes through the three sizes of success message, what a confirmation page should say, how long a message should stay, and how to make sure screen readers announce it too.

Why the end state goes missing

A flow is mostly designed from its form, so the frames run from the first field to the button, and the screen after the button feels like a detail which can wait. It then reaches the build as a gap, and the developer fills it with whatever the framework offers, which is often a small green toast saying Success. I design every flow as one row of screens from the entry point to its end state, with the confirmation, the toast or the first tooltip as the last frame, and when a flow has no end state in the file, such as log in, a password reset or an add action, I list it and design it in the same round.

Nielsen Norman Group puts visibility of system status first among its ten usability heuristics, which asks a design to keep people informed about what is going on through appropriate feedback within a reasonable time, and the success state is the moment when people want that feedback most, since they have just handed over their details or their money.

Match the message to the action

The GOV.UK Design System draws the same lines. Its confirmation pages pattern is for the end of a transaction, and its notification banner has a green success version for confirming an action in the middle of a journey, which its guidance calls unlikely to be the right approach in a linear service, where the confirmation page ends the journey instead. Apple’s guidance on feedback adds the other side of it, since people expect most actions to succeed, so it recommends confirming the significant ones and leaving routine actions quiet.

What a confirmation page should say

The GOV.UK pattern lists what a confirmation page needs, a reference number if there is one, what happens next and when, contact details, links to what people are likely to need next, a feedback link and a way to save a record. For a business website I would read that as five parts.

What happened, as the heading

The heading states the outcome in plain words, such as You’re booked or Your order is confirmed, so the page makes sense to someone who only reads the heading. The dental booking flow which I designed for my portfolio ends on “You’re booked, see you Wednesday”, which puts the day back in front of the patient as the first thing they read.

The details which they chose

Repeat what was booked or bought, with the date, the time, the place and the reference number, so people can check it without opening their email. On the dental concept the visit details sit under the heading with an icon for each line, followed by Add to calendar and Get directions, the two things a patient does next.

What happens next, and when

Say whether an email is on its way, when someone will call, and what people should bring or prepare, since the most common question after any booking is what to do now. The dental confirmation ends with a short checklist of what to bring to the first visit.

How to change it

Give the link or the phone number for changing or cancelling, because people who notice a wrong date on this page will otherwise start the whole flow again and make a second booking.

A way onwards

End with one or two links to what people mostly need next, such as their account or the home page, so the confirmation is a step in the visit rather than the end of the website.

Messages which disappear on their own

A toast or snackbar which fades out is fine for a routine action, and Material Design’s snackbar guidelines let one without an action dismiss itself after four to ten seconds, but they recommend that on the web it only does so when the same feedback also shows on the page, for example a Save button which now reads Saved. WCAG’s timing adjustable guidance makes the same point with a five second toast as its example, where the disappearing message is fine when people can find the information elsewhere. IBM’s Carbon design system recommends against notifications on a timer for critical messages, so I would keep timed toasts for the small actions in the bottom row of the table above.

Make it heard as well as seen

A success message which only appears on screen is silent for someone using a screen reader, which is what WCAG 2.2’s status messages criterion covers at level AA, with a successful form submission as one of its examples. The usual way to meet it is a container with role="status", which the WAI-ARIA specification gives a polite live region, so the message is read out once the screen reader finishes what it is saying, while role="alert" interrupts and is better kept for errors. A status message should stay where it is and leave the keyboard focus alone, and the one exception in the GOV.UK system is a success banner shown when a new page loads, which takes role="alert" so the focus moves to it. A full confirmation page is a new page with its own title and heading, so a screen reader starts it from the top like any other page.

Check your own flows

I would go through every form on your site once, as a customer would, and write down what you see after each button. A blank form which reloads, a toast which vanishes before you have read it, or a page which says Thank you and nothing else are the three which I find most often, and each one is a small design job with a clear fix from the table above. The same reasoning applies to the screens before any data exists, which my post on empty state UX design covers, and the button which starts the flow, which website button hierarchy goes into. The full dental booking flow, from the first step to the confirmation, is in the Fairday case study.

Frequently asked questions

What is a success message in UX?

The feedback which tells people that an action has worked, from a Saved label on a button to a full confirmation page after a booking, ideally with what happens next.

How long should a success toast stay on screen?

Material Design allows four to ten seconds for a snackbar without an action, and I would only let it disappear when the same change also shows on the page, so nothing is lost when it fades.

Should a success message be a page or a toast?

A page at the end of a flow such as a booking or an order, a banner after a step in the middle of a journey, and a toast or a changed label for routine actions such as saving.

What should a confirmation page include?

A heading which states the outcome, the details and reference number, what happens next and when, how to change or cancel, and a link onwards, which follows the GOV.UK confirmation pages pattern.

How do I make a success message accessible?

Put it in a container with role="status" so screen readers announce it politely, keep the focus where it is, and give it enough contrast and a text label rather than a green tick alone.