The result page must name the next actions that can be taken

What it is

People already know it worked. The next beat is “what can I do now.” Naming the next actions means the success (or accepted) screen offers a small set of next steps bound to the object just submitted: view the record, fill another, pay, download a receipt, go home. “Submitted” with no exit makes people press Back, and Back after success often destroys context or submits again. Confirming success is the previous sentence; a long wait is the process; this is navigation after success.

Why it happens

Submit exhausts the previous goal. People need a new goal gradient, or they stall on an empty success page and feel through browser history. Back in that stack often returns a still-editable form. The model is “I want to change what I just sent”; the actual page may be an empty form that will submit again. A second layer: next steps must point at the object just created. A generic “Home” is not a next step; it is leaving. View the application, save the receipt, finish payment—those are actions on the object. More than three options become a new maze; a success page is not a sitemap. If the business truly has nothing a person can do (queued for later), write “you can close; the result will be emailed,” making “no action” a legal end, not a blank.

Studying it

Watch the first action after submit. Compare success copy only, one primary “View record,” three equal buttons, and no button except Back.

Independent variables: count and labels of next steps, whether Back returns a submittable form, whether a download or emailed receipt exists. Dependent variables: resubmit or lost context from Back, hit rate on the primary, time spent stuck on the success page, whether the object can be found after leaving.

The lab will make “view the record” the task and inflate hits. Use “do what you would normally do after submitting.” Clicking any button is not success—Home then being unable to find the record is a failed next step.

Where it stops holding

“Next” in the middle of a wizard is not a result page; do not stack success CTAs at the end of every step. After a small embedded form (a comment box), the next step is often seeing one’s comment appear in the list; insert in place rather than jump. Guest submit without an account, if the next step is “sign in to view,” must first say which receipt is already saved, or the sign-in wall loses the object just created. On partial failure the next step is “handle the failed items,” not a success-state “keep browsing.”

Applying it

• Give the success page one or two primary actions bound to the object (view, download receipt, continue to pay), with copy that names the object, not “Back.”
• Say where system Back will go. If it would return a submittable form, replace that with a read-only review after success, or intercept Back.
• If there is nothing to do, write the end state (“you can close; we will email you”), do not leave a blank for people to invent an action.
• Verify with no spoken prompt after submit: the first tap should be the primary. Press system Back and confirm a second submit is not sent. Leave only “Submitted” with no buttons as a stuck control. On a guest path, confirm a receipt can be kept without signing in.

Related

• Within the group: H1.16.1 Successful submit needs an explicit confirmation, not a silent redirect · H1.16.2 Long processing needs a progress cue so people do not resubmit · H1.16.4 When some fields fail to submit, distinguish the success and failure scopes
• Adjacent: H7.05 Order confirmation · G4.01 Back stack and back semantics · H2.02 Empty-state guidance
• Search terms: next action · success page · post-submit