Figma verification page header examples

The verification screen is the only screen in a product designed to make people leave it. You send them to an inbox, possibly on a device other than the one they started on, and hope they find their way back. Everything about the design should aim at shortening that trip. This set covers the three states the trip has: check your email, enter the code manually, and success.

What the first screen has to say

Step 1 fails on one omission more often than any other. It does not repeat the address. Show the exact address the message went to, character for character, because a typo in the email field is the most common reason nothing arrives and nobody can diagnose that from a screen reading "we sent you an email".

Give people a way to correct it without restarting sign up, a resend control with an obvious cooldown so they do not fire off four identical messages, and one line naming the spam folder.

Say roughly how long the link stays good for. All of that is copy rather than layout, which is exactly why the layout is kept quiet.

Why manual code entry exists

Step 2 is the fallback, and it is not decoration. Magic links break in ordinary ways: a corporate mail scanner follows the link before the human does and burns it, the link opens in an in-app browser with no session, or the message lands on a phone while the sign up sits in a desktop tab.

A short code someone can read and type across that gap fixes all three. Six digits is the convention worth keeping, long enough to resist guessing when there is rate limiting behind it and short enough to hold in your head while you switch windows.

In build, the field wants a numeric inputmode and autocomplete set to one-time-code, so mobile keyboards come up as digits and the operating system can offer the code straight from the message. Paste has to work too, partly because everybody copies the code and partly because WCAG 2.2's accessible authentication criterion treats blocking it as a failure.

Six variants, three steps, two breakpoints

The component has one property, Step, with three values, each drawn at both breakpoints: 1,440px by 960px on desktop and 375px by 960px on mobile. That is the entire flow in six variants, with a duplicate set in dark. The mobile frames deserve the closer look, since this is a screen most people meet on a phone, mid-task, with the inbox one app switch away.

Step 3, success, is the one designers are tempted to cut. Keep it. A confirmation with a single obvious next action is what stops somebody sitting on a blank screen wondering whether it worked, and it is the moment you hand them to the product instead of back to the tab they came from.

The screen and the email are one design

This flow only holds together if the message matches. The address on the screen, the sender name in the inbox, the code in the body, and the button in the email are a single artefact seen in two places, and they are usually made by two people a week apart.

The email templates include a verification layout for exactly this pairing. Upstream, the sign up sections are where the address gets captured, log in sections are where a returning user starts the same trip, and forgot password reuses the same check-your-email shape for a different purpose, so keeping them visually consistent saves your users a beat of doubt about which email they are looking for.

These screens exist in code too. Untitled UI React verification pages are open source, built with Tailwind CSS and React Aria, with code entry focus movement and paste handling already sorted.