Login

General Guidelines

When to use

The Log In page is presented to users in the following scenarios

• When a user wants to gain access to an app
• When a user has logged out voluntarily - they will see a confirmation message after which they will be automatically redirected back to the Log In page
• When a user has been logged out due to inactivity - they should be redirected to the page they were on when they log back in

Anatomy

• Title: Located at the top. For consistency, the title should include the words “Log In” rather than another variant. The title can also include the product name if that makes sense for your situation. If necessary, the title can wrap to the next line.
• Create account link (optional): Provide quick access to the digital form to register for an account; location of this element can vary with layout
• Required fields: The user ID and password fields are both required, although user IDs are usually in the form of an email address.
• Remember ID (optional): Saves the user ID and presents the completed input field the next time the user logs in; it is located under the required field. Clarify what is being remembered (that is, “user ID”) to avoid confusion.
• Log In button: Button label should be “Log In” for the primary call to action. When clicked, the email address and password are validated and should provide error message if credentials are not valid.
• Forgot password link: Takes users to a page where they begin the flow for recovering their password.

Behavior

Authentication

Do not give users an error if they enter an email or username that is not valid until after they have clicked “Log in”. This protects valid email addresses and usernames from being exposed and helps keep your product secure.

Errors and validation

Effective error messaging is important for creating great experiences. Not being able to log into an application is frustrating and blocks users from accomplishing their tasks.

Always present error states on the Log In screen, and use inline errors whenever possible. The error state you use will depend on whether the validation happens on the client or the server.

Server-side errors

If there are server-side errors when the user submits the Log In form, the page should reload, the password field cleared, and the user returned to the username input field. Unlike longer forms, the guidelines for the Log In form can utilize one general message for server side errors. It is still recommended to use an inline notification, when possible, to display errors and provide clear direction on how users should resolve the issue. If there are multiple server errors, the inline notifications should stack.

Incorrect username and/or password are the most common server errors. The application should wait until both the username and password have been submitted before checking they are valid. The same generic error message is suggested for incorrect usernames or passwords. As mentioned earlier, this protects valid email addresses and usernames from being exposed and helps keep your product secure.

Content guidelines

Error messages should be clear and concise. They should help users understand what went wrong and give users steps to resolve the error. Be as specific as possible in your error messages. If the message is written as a complete sentence, always use a period. If the message is a short fragment, then feel free to omit the period.