Login Page UX: SSO, Magic Links and Errors
Login is the screen your customers see most, and the one teams design least. A slow or confusing login is a daily tax on every user, and a support ticket waiting to happen.
What makes a good SaaS login page?
A good SaaS login page recognizes how the user signed up and offers that method first, supports password managers with the right autocomplete values, offers a magic link or reset that works quickly, shows errors that say what to do next, and never asks users to solve puzzles to prove who they are.
What should the login states look like?
Design every state, not only the empty form. The mock-up shows the main login screen and the most common error: a user trying a password on an account that uses company single sign-on.
Other states to design: wrong password, locked account, expired magic link, unverified email and a password reset that has just been sent. Each needs a message that says what happened and what to do.
Which technical details make login easier?
Use one form with an email field marked autocomplete="username" and a password field marked autocomplete="current-password", offer a show-password toggle, and make buttons say what they do. Google’s guidance also recommends targets of at least 44 by 44 pixels on mobile and avoiding duplicate inputs (web.dev sign-in form best practices). NIST requires verifiers to allow password managers and autofill (NIST SP 800-63B).
What does accessibility require for login?
WCAG 2.2 added Accessible Authentication (3.3.8, Level AA): logging in must not require a cognitive function test, such as remembering or transcribing a code or solving a puzzle, unless there is an alternative or help such as copy and paste and password managers. It also added a minimum target size of 24 by 24 CSS pixels (2.5.8) (W3C on what’s new in WCAG 2.2). More is on SaaS accessibility.
Design the error states first.
Most users see the happy path once. They see the errors when they’re already frustrated. That’s where login wins or loses trust.
How should password reset work?
Password reset should take one field and one email, confirm without revealing whether the account exists, send a link that works on the device the user opens it on, and log the user in after the new password is set. Error copy for each step is covered on error messages and microcopy, and the signup side on signup form design. On phones, see mobile SaaS UX.
Frequently asked questions
What should a SaaS login page include?
The sign-in methods your users signed up with, email and password fields with the right autocomplete values, a reset link, and helpful error messages.
Should SaaS apps offer magic link login?
It’s a good option for users who don’t want a password, as long as links expire and work on the device where they’re opened.
What autocomplete values should login forms use?
autocomplete="username" for the email field and autocomplete="current-password" for the password.
What is accessible authentication in WCAG 2.2?
Success criterion 3.3.8 says login must not require a cognitive function test, such as a puzzle, without an alternative or help.
How should login errors be worded?
Say what happened and what to do next, such as using SSO, resetting the password, or checking the email address.
Should password reset say whether an account exists?
Usually not. Confirm that an email has been sent if an account exists, to avoid revealing who uses your product.
Sources & further reading
Standards and platform rules change. These sources let you verify the current requirements directly. All screens shown are mock-ups of fictional products.