Existing user login page: where sign-in fails

A login form that says invalid email or password gives the same message for every failure. A returning user cannot tell which part is wrong, so they try the password they remember, then the reset link. If the address they typed is an old one, or has a trailing space from autofill, the reset email goes to nobody and the account looks deleted. If the reset link opens a different hostname from the one they signed in on, the page may show them logged out again. You see a working login, because your own account never had the problem.

• The error names the field that failed, not only invalid email or password.
• A reset email arrives in the inbox, and its link opens a page that asks for a new password.
• The reset link opens the same hostname the login page uses.
• A successful sign-in lands on the account page and stays there after a refresh.
• The sign-up page recognizes an address that already has an account and offers sign-in.

The first failure is often the address, not the password. Autofill can add a space after the email, a phone keyboard can capitalize the first letter, and a person who signed up with a work address may now be signing in with a personal one. Many login forms do not say which of these happened. The visitor sees the same red line for a wrong address and a wrong password, so the next move is guessing the password again. A tell you can read on the report: the visitor typed the address, failed twice on the same error, and never tried a reset. Then the form, not the account, is the likelier cause.

A reset is the path most returning customers take, so it carries the most weight. Test it with the address the visitor types. The reset email has to reach the visitor's inbox, and the report shows whether it arrived during the run. Spam filtering is a separate check, covered in the FAQ. A link that has expired, or that opens an error page, looks like a broken account, and the visitor cannot tell a dead link from a dead account. Check that the link in the email opens the same hostname as your login page. A link to a preview address, while the login runs on the live domain, sends the visitor somewhere they appear logged out.

Visitors have a working inbox, so they can open the reset email and follow its link. They cannot receive a text message, so a reset that sends a code by text stops the visitor at the code field. That is a limit of the test, not a fault in your flow. The code screen still needs a look from you: check that it accepts the right code, shows a clear error for a wrong one, and offers a way back to sign-in.

Some sign-ins succeed and still fail. The session cookie is set on one address, such as the version with www, and the redirect after sign-in goes to the other. The account page then asks for the password again, and the visitor sees the login form reappear straight after a correct password. Read the address bar at each step. If it changes between the sign-in and the account page, and the form comes back, the cause is the redirect or the cookie, not the password.

Make the sign-in easy to find for someone who already has an account. Put sign-in and sign-up side by side, using the words a returner uses: I have an account, next to Create account. A sign-up form that answers this email already has an account, with no link back to sign-in, leaves the returner with nowhere to go. The visitor's run shows the message and the next click.

Sign-up flow testing

A site owner changes the login address, adds a redirect, or moves the site to a new domain, and the returner's session stops matching. Rerun the reset and sign-in path after each release that touches the domain, the redirects or the account settings. Run it on every preview, from a phone and a laptop. With paid credits, a test account lets visitors reach the account page, not only the form.