Designing login and sign-up screens

In short

Login and sign-up screens are short forms, but they are the door to the product. Anyone who gets stuck at the door never sees what is inside.

With this pattern I first check whether the door is needed at all. Then I move on to the password rules and the error message. Finally I check whether the browser can fill in the fields. General rules on field layout and when to validate are on the form design page.

Bad and good login screen

Below are two screens for the same account. On the left is the bad example I often see in audits; on the right a screen that follows the rules on this page. On narrow screens they stack.

Bad and good sign-in screen

Test account: [email protected], password blue-door-42. Copy the password and paste it into both screens.

Bad

Blocked password, vague error message

On paste: the password field blocks pasting. There is no show button, and autocomplete is off.

On clicking Sign in: “Invalid input” appears at the top and both fields are cleared. There is no “Forgot password” link.

Good

Visible label, error at the field

Email

PasswordForgot password?

On paste: the password lands in the field. With “Show password” you check what you typed.

On clicking Sign in: next to an empty or wrongly formatted field it says what you need to do. If the details don’t match, only the password field is cleared.

Forgot password: in the real product a page opens with a single field for the email. Afterwards it says “If this address is registered, we’ve sent a reset link”.

Both screens have the same two fields. Submit both empty first. Then paste the password and try a wrong password. The demo sends no data.

You see the difference fastest when you paste the password. The bad screen locks out the password manager. On the good one, copy and paste works, and the show button helps you find typos.

Login and sign-up are two doors

Someone who wants to sign in is looking for something different from someone opening an account. One wants two fields; the other wants to know what they are signing up for. That is why I build the two flows on separate screens or in two clearly separated tabs.

The heading of each screen should say what it does: “Sign in” or “Create account”. Below it is a short path to the other door: “No account yet? Create account.”

Jared Spool’s 2009 article shows why this separation matters. At one online store, 45% of customers had several entries in the system, some as many as 10. Returning customers often no longer remembered which email or password they had signed up with.

The guest option

If the user can finish their task without an account, don’t force them to sign up. That includes paying, booking an appointment or a one-off application.

In the case Spool describes, the designers replaced the Register button with a Continue button. Next to it they wrote that you don’t need an account to make a purchase. The number of customers buying rose by 45%. The extra revenue was $15 million in the first month and $300 million in the first year. The whole story is on the page The $300 million button.

In the Baymard Institute’s list on checkout abandonment, 18% of those who abandoned (excluding the “just browsing” answer) give the reason “The site wanted me to create an account”. Raluca Budiu of NN/g also recommended guest checkout in 2014. In her view, the account offer should come only after the purchase.

For personal products such as online banking or email, a login wall can’t be avoided. For other products I try to put up the door only after the product has shown its value. Where the guest flow belongs is described in the checkout pattern.

Password rules

For password rules I look at SP 800-63B-4 from NIST, the US standards institute. The final version came out in July 2025. These points affect the sign-up screen directly:

• A password used on its own must be at least 15 characters long. If it is only part of a multi-factor sign-in, the minimum is 8 characters.
• Passwords of at least 64 characters must be allowed. The system checks the whole password without truncating it.
• There should be no composition rules such as “uppercase letter, digit and special character”.
• Users shouldn’t be forced to change their password at fixed intervals. A change is required when there is evidence that the account has been compromised.
• A new password is compared against a list of common and leaked passwords. The service name and the username belong on that list too.
• Password managers and autofill should be allowed. Allowing paste is recommended.
• Password hints are not stored, and security questions are not asked.

State the rule from the start. Katie Sherwin of NN/g called in 2015 for the requirements to be visible while the password is being created. She also advises against squeezing the requirement into the label.

A “Confirm password” field is usually unnecessary. The GOV.UK Design System advises against it, because the show button is enough for the user to check what they typed.

Show password

A masked password field hides typos. The user only notices their mistake from the error message. NIST also recommends the option to show the password while typing.

Sources differ on whether the password should be visible from the start. GOV.UK hides it by default because the user may not be in a private space. Sherwin, on the other hand, recommends showing the password from the start on phones and tablets, with a hide button next to it.

I start masked and put the button right next to the field. The button’s state must reach the screen reader too. In the example above I did this with aria-pressed.

Forgot password

This link sits right next to the password field and is always visible. A link that only appears after an error comes too late for the person who needs it.

The site in Spool’s case received about 160,000 password requests a day. 75% of those who requested a password never tried the purchase again. A forgotten password costs revenue directly.

The reset screen asks for a single field: the email. The message after submitting shouldn’t reveal whether the address is registered. OWASP’s authentication cheat sheet gives this example: “If that email address is in our database, we will send you an email to reset your password.”

Social login

Signing in with Google or Apple opens an account without typing a password. I offer these buttons alongside email sign-in, not instead of it. Not everyone has one of these accounts, and those who do may not want to link it.

The problem I see in audits: the user no longer knows which way they signed in last time. That is why I keep the order of the buttons the same on every screen. Where possible, I mark the most recently used option.

Don’t ask users who come through social login for their details again. Show the name and email from the account, and the user just confirms.

When email verification should come

I don’t require verification at the door but where it is needed. After signing up, the user can use the product right away. Verification comes before a step such as paying or sharing, or in the first few days.

A “Verify your email first” wall right after sign-up sends the user out of the app into their inbox. Anyone who doesn’t come back from there is lost.

If verification is a link sent by email, it is among the sufficient techniques the W3C lists for 3.3.8. With verification by code, the code field must allow pasting. Add autocomplete="one-time-code" to the field.

Login error messages

There are two kinds of errors on the login screen, and they are worded differently. A format error appears at the field and says what is wrong: “Enter the email address in the format [email protected].”

If the details don’t match, the message shouldn’t say which field is wrong. GOV.UK writes that revealing the source of the error can help fraudsters break into accounts. OWASP also calls for a generic response that doesn’t reveal whether the account exists.

GOV.UK says to clear the password field after a failed login. I leave the email field as it is. At the end of the message I add a way out: “Try again or reset your password.” I collected the rules for wording such messages in the error messages pattern.

Autocomplete attributes

autocomplete tells the browser and the password manager what a field is. If the value is right, the password manager fills in the fields itself. The meanings of the values according to MDN:

Field	Value	Meaning
Sign-in: email or username	username	According to MDN, the username or account name.
Sign-in: password	current-password	The user’s current password.
Sign-up and password change: new password	new-password	Lets the browser avoid filling in the old password by mistake and suggest a strong password.
Sign-up: email	email	The email address.
Verification code	one-time-code	A one-time code required as an extra step at sign-in. Usually arrives by text message, email or authenticator app.

For sign-in I put username on the email field, because that field is the account’s name. MDN also notes that browsers may ignore autocomplete="off" on login fields. In my view, turning it off achieves only one thing: it makes life harder for anyone using a password manager.

Accessible authentication: WCAG 3.3.8

Success criterion 3.3.8 Accessible Authentication (Minimum) in WCAG 2.2 is level AA. No step of authentication may require a cognitive function test. Remembering a password or solving a puzzle are examples.

The criterion has four exceptions: another method without a cognitive test, a mechanism that helps with the test, object recognition and recognising content the user provided themselves. As examples of such a mechanism, the W3C names the password manager and copy and paste.

The W3C’s Understanding page spells out the consequences:

• A login that blocks password managers or pasting fails the criterion if there is no other method.
• A service that makes users type the verification code by hand is not conformant. The code field must allow pasting.
• A puzzle check also needs a method without a cognitive test. An audio alternative where you type what you hear doesn’t replace that method.

I explain this criterion and the other changes in WCAG 2.2 in the WCAG guide.

My note

The mistake I see most often on login screens in audits is the paste block. The team thinks of it as a security measure. Yet NIST recommends allowing paste, and WCAG counts the block as an accessibility failure if there is no other way to sign in.

In second place are messages like “Invalid input”. A generic message is right for security but mustn’t leave the user at a loss. Put the reset link in the message and you have both.

On the sign-up screen I count the fields being asked for. First name, last name, phone and date of birth are usually not needed on day one. I start with just email and password and ask for the rest when it is needed.

Checklist

Before a login and sign-up flow goes live, I go through this list. If you want me to check your own screens against it: the UX audit covers every point.

• If the user can finish their task without an account, there is a guest option.
• Login and sign-up are separate, and the headings say what they do.
• The password rule is on the sign-up screen from the start, with no composition rule.
• Pasting into the password field works, and the password manager fills the field.
• There is a “Show password” button, and its state is passed to the screen reader.
• The “Forgot password?” link sits next to the password field and is always visible.
• Format errors appear at the field; the login error is generic but shows a way out.
• Email, password and code fields have the right autocomplete value.
• The verification code can be pasted.