So, you want to log in…

The first step in any app is a secure login, but does it doesn’t need to be a chore.

In today’s world, we have passwords. And more passwords. As we seek to secure our data and applications, those passwords and their makeup has become even more important. Since this is the first point of entry for a great many users, extra attention should be given to make that experience great. Not only should it be a positive experience, but is should almost always be as simple and fast as possible. Without logging in, most users can’t use your site or give you their money, right?

On top of just logging in, sooner or later someone will need to reset their password as well. This may be because they forgot it, because it is corporate policy, or because they don’t visit your site very often and you made them sign up to see content in the first place (don’t do this!).

So, not only should your login be quick and easy, but you have to offer your users a method to reset their password. Because of onerous restrictions, both of these can get frustrating for a user all too quickly. As “strong” passwords have become the de facto way to handle minimum security requirements, they have added extra pitfalls for users and designers. I’m not going to get into whether password complexity requirements work or not, but they are a modern day reality and users have to deal with them.

While many people see these parts of a workflow as either necessary evils or unimportant, I believe they can be designed thoughtfully to add to an overall positive experience for your users that speeds up the process and builds trust.

Password reset requirements are a modern day reality and user have to deal with them.

People have a lot of logins. LOTS. Unless you are Google or Facebook, they may forget your password. A user may get their login correct within a try or two or they may need to reset their password entirely. If you just deployed an app to sell free range, organic snow tires you should expect your users to be infrequent and resetting their passwords more often. As such, the entire login process must be put under the microscope to make it as smooth as possible.

• Just let your users log in. A recent trend is to have the user enter their email first, then go to a second form to enter their password. This is a direct result of a ‘new users first’ slant many sites have adopted. This gives converted users an extra step even if they use a password manager. Treat your return users as just that, ‘returning users’. They know the score.

Atlassian forces the user to click ‘Continue’ before showing the enter password text field.

• If possible, validate the username as well. This is even more important if the login name isn’t an email address. The user may not remember their username and seeing a positive validation message/icon will assure them and build trust.

This form displays a green checkbox when a valid user is detected.

• If the login is an email, say that. Don’t call the login ‘username’ and expect people to use an email address. Some back end systems don’t make this distinction, and it may be semantics, but your users don’t care. It is super frustrating to have to fetch your username only to find out it is your email the login wanted.
• When the user gets their password wrong, tell them clearly and tell them as close to the login form as possible. Don’t shift page elements around too much, but do leave focus in the password field.
• If the user types in the password incorrectly again, make sure the message re-displays, animates, or calls attention to itself. The user needs to know their subsequent login attempts are still unsuccessful. Hold up a sign and wave it around. Apple famously shakes their password entry box when signing into OSX each time a user gets the wrong password.

Foodkick doesn’t tell you you were wrong but shows a captcha indicating a different problem.

• Don’t wipe out the login form on an unsuccessful attempt. Leave the login name for sure. Put focus on the password and select the text so they user can quickly reattempt.
• If there is a max login attempt, the user should be prompted as they approach this limit instead of after they have surpassed it and locked themselves out.
• Don’t refresh the entire page on a failed login attempt. Not only does this create a disjointed experience, it triggers many password managers to believe the login was successful.
• Lock the UI on the login request. Both login and password fields should be disabled/locked as should the submit button. In addition, display a progress indicator like a spinner or animated icon so the user knows their request has been sent.

This form disables the login button along with the email and password fields.

• Display some feedback immediately. Depending on the technology the site is built on and speed, a small message can be displayed if there is a lag on login redirection/render. Another approach is to display this feedback in the submit button itself as an animated check mark. This is much better than a blank screen, infinite spinner, or slow page load/redirect.

Here the user gets feedback that the login request is processing and then it is completed before redirecting or loading more content.

So, now you are logged on. Great. What if you need to reset your password? Well, that is a bit different. The basics still apply, but when things get complicated features should be added thoughtfully. A ‘new password’ and ‘confirm new password’ field should always been shown, but if there are strength requirements, the user should not be hindered by that requirement.

• When resetting the password, tell you user in a series of separate items what each of the password strength requirements are. Strength indicators are good, but the user should not be made to compare a strength indicator to some other text string to make sure their password is OK.

This form shows ‘Fair’ for the strength. Is that enough, or does it require a ‘Strong’ password? What does ‘fair’ mean? The user has no idea what this form requires.

• As a user types their new password, provide feedback on each requirement when it has been satisfied or is invalid. Remember, the user usually seeing ‘*********’ as they type, so they will not visually reconcile a list of requirements to what they are typing.

Github has a good start, but a vertical list is better for a user to consume.

• Display inline validation, like a check mark, so the user knows their new password is good to go once they have satisfied all the restrictions.

Mint very clearly shows the overall password validation, what conditions have been satisfied, and what is left to do for the user.

• Once the strength requirements are satisfied, enable your submit button. Don’t give the user the opportunity to submit a bad password, just validate as the user is typing. If you do allow them to submit without validation, follow the tips for providing feedback on server-side validation or bad login attempts.

T-Mobile disables their ‘Next’ button until both passwords match.

So, this isn’t huge ground breaking stuff. However, logging in is how your users interact with your core offering, so the feature needs extra attention to ensure an overall positive experience. It doesn’t take much to have a user give up, but with careful consideration you can drive more visits to your app, build trust, and make happier users along the way.