Write signup confirmation that matches the actual state

Name the state before writing the message

The website can receive a request, a service can accept it, a person can confirm an address and a resource can become available. Write down which event has happened at each screen before deciding what that screen should say.

This prevents a common mismatch: celebrating an active subscription when the person still has an action to complete. It also makes support easier. A reader who knows the current state can describe a problem more accurately than someone who only saw a generic success banner.

Describe any confirmation step precisely

In Mailchimp’s documented double-opt-in journey, the signup thank-you page asks the person to check for a confirmation email. The contact becomes subscribed after using the confirmation link, and a separate confirmation page can then appear. Other services and configurations may have different states, so inspect the actual setup rather than copying those words blindly.

Do not turn a technical confirmation method into a universal statement about legal requirements. For a working publication, choose the appropriate process with the people responsible for its obligations, then make the interface describe that process accurately.

Worked example: a newsletter with a separate confirmation

Consider a new newsletter that uses a separate email confirmation. After a valid request, the page could say that the request has been received and that the reader should check for the confirmation message. After confirmation, the page can explain the next edition or point to the promised resource.

If a connection fails after a submission, the interface should explain that the result cannot be confirmed and avoid encouraging immediate repeated submissions. These are illustrative wording patterns, not evidence that a particular service has completed the operation.

When “no message was sent” is true: dry runs and real tests

A test needs its own message only when that message is accurate. “No message was sent” is justified for a dry run: a run the system knows did not invoke any transport, for instance because it was configured only to validate input and render the text. It is not justified by the name of the environment. A staging or test setup can be configured, with authorisation, to make a real send, and telling its operator that nothing was sent would then be wrong.

The wording should therefore come from a recorded property of the run, such as a dry-run setting the system can report, and not from an assumption about where the form is running. For a real test, report the result the system actually established, and say what it did not check, such as whether a message reached an inbox. The form review checklist is the place to look at the whole form from the first promise to the final result.

The matrix, part one: from request to resource

Each row pairs an established event with a message, what that message may promise and the reader’s next step. The messages are specimens, to be adapted to the operation your system has actually confirmed. The rows are not interchangeable: if two rows would receive the same message, check whether they are really different events.

• Row 1, request received and confirmation pending. Established: a valid request arrived and this setup requires a separate email confirmation. Message: “Your request was received. Check your email for the confirmation step before joining the digest.” May promise: that a confirmation step is still needed and that the subscription is not yet active. Must not promise: that the subscription is active, or when an email will arrive. Next step: follow the link in the confirmation email; a support route is shown for readers who cannot find it.
• Row 2, subscription confirmed. Established: the reader used the confirmation link and the service shows the contact as subscribed. Message: “Your subscription is confirmed. Here is what the digest covers and where to change your preferences.” May promise: that the subscription is active and what the digest covers. Must not promise: a specific delivery date unless one is known. Next step: read what to expect and find the preferences route, which the unsubscribe and preference guide discusses.
• Row 3, confirmed and resource available. Established: confirmation is complete and the intended edition has been checked as accessible from the resource page. Message: “You are confirmed. The worksheet is on the resource page.” May promise: that this page holds the current edition. Must not promise: that the file opens on every device. Next step: open the page; if the file fails, use the support route and name the edition shown.

The matrix, part two: failures, uncertainty and tests

These rows cover events where the system either knows it failed, does not know, or is not sending to a real reader at all. Keeping them apart matters because the permitted promise is different in each.

• Row 4, known failure from invalid input. Established: validation rejected the request and nothing was accepted. Message: “Check the email field. This request has not been accepted.” May promise: only that nothing was accepted and which field needs attention. Next step: correct the field, with other safe input preserved; the error appears next to the field as well as in the overall result.
• Row 5, known failure from a system error. Established: the system received an error and knows the request was not processed. Message: “Your request could not be completed. You can try again, or contact us if it keeps happening.” May promise: that the request failed. Invite a retry only if the system knows nothing was recorded; otherwise treat the event as Row 6. Next step: try once more, or use the support route.
• Row 6, uncertain transport result. Established: the request was submitted but the response was lost, so it is unknown whether it was recorded or a confirmation email was handed over. Message: “We could not confirm the result. Please avoid submitting the same request repeatedly while it is checked.” May promise: only that the result is unknown. Must not promise: that an email has been sent, or that it has not. Next step: wait and watch the inbox, while the operator checks the service’s own record of the request.
• Row 7, dry run. Established: the system knows this run did not invoke transport. Message: “Dry run: no message was sent.” May promise: that, and nothing more. Next step: the reviewer checks the rendered text and the run log.
• Row 8, real test. Established: an authorised test used transport and the system recorded an outcome. Message: it states that recorded outcome, for example “Test: the confirmation message was accepted for sending to the test address; inbox delivery has not been checked.” May promise: the recorded outcome only. Next step: check the test inbox and record what actually arrived.

Give feedback people can act on

W3C’s form-notification guidance recommends feedback about the result and clear instructions for resolving errors. In practice, keep a problem near the relevant field and provide an understandable overall result. A notice that relies only on colour can be missed, and a hidden error at the top of a long page can leave the person unsure what to change.

Preserve safe input when correcting a form rather than forcing someone to start over. Avoid placing their complete address or private details in a public URL to make the success page personal. The accessible-form guide develops the relationship between labels, instructions and feedback.

Check the follow-on page as part of the form

Historical form configurations associated with Tygodnik Przegląd and other publishers contain post-subscription destinations on those operators’ own sites. That is useful evidence that the page after the form was part of the designed journey. A configured destination alone does not prove that every submission reached it.

For your own system, test each state deliberately and retain a short result record. Connect the page to an appropriate welcome message or resource handoff, with a clear route to support if the expected next step is unavailable.