3 Rules for Painless Account UX: Login

Jessica Enders
Tweet
'Welcome. Come in this Door' elegantly painted onto a glass door frame.

Photo: SeeMidTN.com (aka Brent)

In the first part of this article, we outlined how following three little rules can make account management less painful.

To quickly recap those rules:

1. Don’t make the user guess
Almost every service on the web handles account management slightly differently. As a result, you have to be explicit about the requirements for your service. Otherwise, you’re just being cruel.
2. Balance security with usability
Often, security folk will insist on an approach that compromises the user experience. This is foolish, because poor usability will lead to workarounds, and workarounds in turn lead to weakened security. Instead, aim for a design that is both secure and usable.
3. Keep it simple
Account management is one of your biggest potential barriers to usage. Make the barrier practically invisible through a simple, seamless, pain-free design.

In that first part, we showed how to apply these rules to improve the process of creating new accounts. Now let's take a look at using those same rules to improve the experience of logging in.

The Login Process

Rule #1: Don’t make the user guess

Log in screens are usually relatively minimal, with a field for a username and another for password. Minimal doesn’t always equal simple, though, especially if you hide information that helps explain things to users.

  • If the username is an identifier that the user didn’t create — e.g. an electricity account number — tell users what the username is and where they can get it (e.g. “at the top right corner of your bill”).
  • If the username is an email address, tell users.
  • If the password is a numeric pin, tell users.
  • If space allows, instead of “Remember me” use “Remember username on this computer”. (“Remember me” doesn’t really tell the user what will happen.)

Example: What not to do

Roam Express, a provider of electronic tags for paying road tolls, doesn’t tell you where you could find your tag number.

Roam Express

Example: A better approach

LG do better, being specific about the username being an email address, and what the “remember me” checkbox will do.

LG Login

Rule #2: Balance security with usability

With logging in, the main challenge security versus usability challenge relates to how you deal with incorrect attempts. The more information you can give the (legitimate) user, the more able they are to recover and log in correctly. However, this information can also be used by black-hat hackers to ascertain usernames and passwords.

The solution is to:

  • give a moderate amount of information (e.g. tell the user when log in has failed and, if you can, whether the problem was with the username or the password);
  • give users at least two and preferrably three attempts — typos are easy to make; and
  • apply time limits and penalties, rather than locking people out altogether.

Time limits and penalties are best described by Thomas Baekdal in his article The Usability of Passwords:

All you need to do is to prevent automatic hacking scripts from working effectively. What you need to do is this:

1. Add a time-delay between sign-in attempts. Instead of allowing people to sign-in again and again and again. Add a 5 second delay between each attempt. It is short enough to not be noticeable (it takes longer than 5 seconds to realize that you have tried a wrong password, and to type in a new one). And, it forces the hacker to only be able make sign-in requests 1 every 5 seconds (instead of 100 times per second).

2. Add a penalty period if a person has typed a wrong password more than, say, 10 times, of something like 1 hour. Again, this seriously disrupts the hacking script from working effectively.

Example: A better approach

Uber tell you which of your two credentials you’ve gotten wrong.

Uber login screen

Rule #3: Keep it simple

You’d think, given how small a log in form is, they must all be simple. Alas, you’d be wrong! Have a look at how these services overcomplicated the process.

Example: What not to do

The West Australian Symphony Orchestra asks for a promo code at log in.

Western Australia Symphony Orchestra login screen

Example: What not to do

The Co-op Bookshop used to make logging in way more difficult than it needed to be. They hid the password field until after the email address had been entered and validated (using the tab key, no less!). (Thankfully, after a recent redesign, they’ve moved to a more standard approach for log in.)

Coop Bookshop login screen

The two examples above show the addition of needless fields or steps, something you should definitely avoid. What else can you do to keep login simple?

  • Make sure the log in call-to-action is easy to find, whenever users might want it. The top right hand corner is a common location.
  • Enable self-service and immediate reset of user passwords (and also usernames, if chosen by the user). Resetting should require sufficient identification (ideally two-factor authentication rather than security questions, which are hard to implement well). Do not send passwords “in the clear” e.g. via email — especially permanent passwords — as email can be intercepted or hacked. This is why resetting is preferable to recovery.
  • If the username is an email address and user is on a mobile or tablet, switch to the device’s email input-optimised keyboard. Similarly, switch to a numeric keyboard for passwords that are pins. See Touch Keyboard Types for more information.
  • You most definitely do not need a “clear” or “reset” button on a log in (or registration) form (see above Roam Express example of what not to do)!
  • Put “Forgot username” and “Forgot password” links in close proximity to their respective fields.
  • Don’t worry too much about “log in” versus “sign in”, there are pros and cons to both. For instance, some argue “log in” is technical jargon, but then “sign in” is more easily confused with “sign up”. Pick one approach and stick with it; in this case consistency matters much more than the specific choice of words. Oh and note that “login” is a noun (e.g. “What’s your login?”) whereas “log in”/”sign in” are verbs (e.g. “Please log in to your account”). See “Login Is Not a Verb”.

Example: What not to do

Computershare put the forgot username/password links not only a long way away from the corresponding fields but also outside the prominent blue login box (which almost guarantees they won’t be seen).

Computershare's login

Example: A better approach

Unlike Computershare, Skype put the forgot username link (“Forgotten your Skype Name?”) immediately below the username field, which is ideal. The same is done for the forgot password link.

Skype's login screen

Example: What not to do

Travel site Kayak doesn’t adjust the keyboard when entering an email address via mobile.

Kayak's login screen

Example: A better approach

The Guardian adjusts the keyboard when entering an email address via mobile.

The Guardian's login screen

So that’s it. For painless registration and log in:

  • Don’t make the user guess;
  • Balance security with usability; and
  • Keep it simple.

Any ways for implementing these rules that I’ve not covered here? Let us know in the comments.

Otherwise, go forth and create great account management experiences!

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • James Edwards

    To clarify the point about changing the mobile keyboard for email input — that’s achieved by using input type=”email” rather than input type=”text”

  • http://ocramius.github.io/ Marco Pivetta

    Please consider removing the suggestion about security+usability, that’s really terrible.

    The Uber form is leaking information, letting possible attackers actually just figure out if a user is registered or not. That’s already too much of an information leakage from my perspective, don’t do it!

    • http://web.lliseil.fr LLiseil Web

      Security vs usability : really?
      Why not help the many users going on straight forward? Christian Busse pointed it out: If a cracker « wants to find out if an username is already in use he just
      needs to try a registration on that username. so the effort isn’t really
      high, where for the user it can be a helpful hint. »

  • http://www.ersws.com/ Elliott Rodgers

    “Uber tell you which of your two credentials you’ve gotten wrong”

    Absolutely terrible idea! This gives a hacker half of the information they need!

  • Mike White

    Are the images swapped for email keyboard?

  • http://www.anthonydamota.me/blog Anthony

    Thanks for the tips !

    I strongly agree with @Elliott Rodger’s answer. Hackers will directly know what information is correct and which are not.

  • http://digivitz.com/blog Jamie Kravitz

    Another bad pattern that shows up in the Kayak and Uber examples is to have the label of the field appear in the field itself rather than outside it. While it takes less space, it’s jarring and disorienting when you are filling out a field with no label on it, even on something simple like a Sign In form. Personally I disagree with your point about Log In versus SIgn In – as with anything in UX, context matters and “log in” definitely is more tech-geek speak. So for broad, consumer applications “SIgn In” is better, whereas for a developer tool for example, “Log In” could be a better choice because the folks using it will feel more at home.

  • Matt McCallum

    Some good advice but some really, really poor advice. Mental note not to use the author’s form design business.

  • http://www.snipe.net snipe

    No, not really. It’s easy to automate login scripts. Registration scripts are harder to automate (as they usually have more fields, and often a captcha). While a more sophisticated registration scanner would have a bunch of default info, keying off of HTML input field names, the measures there will stop most of the crummy ones. An ambiguous error message on login, a small barrier to entry on the registration page plus brute force detection on the login is a much better plan.

  • http://www.snipe.net snipe

    That said, there’s no steadfast rule. It all comes down to who your audience is, what business risks you’re willing to take, and what amount of monitoring and automation prevention you’re doing. IF you’re doing aggressive proactive monitoring on login attempts (plus brute force lockouts) and your users are non-technical, it could be a risk worth taking to use more specific error messages. In other words, IF (and only if) you’re doing enough on the backend to monitor and prevent bad actors from being successful, then you should consider use specific login error messages.

  • Mohd. Mahabubul ALam

    Online accounts give users privacy, control and a personalized
    experience (imagine Facebook without accounts!). Account management —
    registration and log in — is, therefore, a necessary evil. Except when
    it goes wrong, no user likes or cares about account management, they
    just want to access the service. You can make account management less
    evil by