Design & UX
By Jessica Enders

3 Rules for Painless Account UX: Login

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

Photo: (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

Tripadvsor adjusts the keyboard when entering an email address via mobile.


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!

  • 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”

  • Ryan

    I’m confused as to what the difference between Kayak and the Gaurdian is. They both show # keys.

    • Stroudie

      The example wasn’t good the benefit is when on abc the at sign is still usable. Most email addresses are all alpha.

  • 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!

    • gero

      I concur! Leaking out the email address is a BAD practice.

    • 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. »

    • eriklydecker

      Google does this. Are we going to discuss how they think of security?

    • Dennis

      Ofcourse leaking email addresses is a bad thing. But again the impact is very, very low. Everyone has it’s email address hanging around the web somewhere, so why bashing the idea of “leaking” email addresses? Just a fact! Your email address is not secret, it’s as secretive as your name, which everyone knows (or can figure out). Your password or even the 2FA is your secret entry, and only you know how to get in. The article is more about the fine balance between security and experience. Google uses the email address check in the first field. They have more than one reason why they do this. Another fact is, that most passwords we use are not that safe. If you really want security. Use 2FA!

  • “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?

  • Christian Busse

    the security&usability suggestion is a good one. if a hacker 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.

  • Thanks for the tips !

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

  • 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.

  • Mike White
  • Matt McCallum

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

  • 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.

  • 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

  • Debi N.

    Thanks for this clearly written article. Just wanted to point out that the keyboard displayed for The Guardian is not an email keyboard either.

    • Thanks for the heads-up on that, Debi. Good point. We’ve updated that image.

  • eriklydecker

    At Rule #3 you say that “not showing the password field is wrong”, but yet Google does this and they have around 94 UX experts woking full time?

    • Formulate

      Hmm. You’re right. Places like Google, Apple, Microsoft and Amazon never make usability mistakes, and people always find their products completely easy to use.

      • Formulate

        But in all seriousness, one would be wise to not blindly follow what the big tech companies do. Amazon, for instance, has started showing passwords while they’re being typed, by default. This is a really bad idea as it exposes very private information without the user’s consent.
        There can be lots of other, non-usability related, reasons why a company designs an interface a particular way. User experience isn’t the only reason companies do what they do.
        Also, 94 UXers in a company the size of Google – by which I presume you mean Alphabet – is not many, especially considering the huge number of different products they have. Plus we know Alphabet has a strong history of engineering and data science, but not necessarily user research. Who knows what testing they’ve done on this part of their experience? Maybe they’re just doing a big trial run now and are not yet committed to that design going forward.

        • eriklydecker

          That was a long reply. I did ask a friend of mine who is a security expert and he said “it depends on the type of service and the information hidden by the account”, but he said that it’s not best practice to inform the user what information was wrong, i.e. username or password. All the big names you mentioned do various mistakes with regards to UX, especially Microsoft. Apple tells you what is wrong, username or password. Google checks your username before going forward to the password section of the login process. I believe in simplicity and clarity from all angles, if there is any security concerns then the fault is done by “the other guys” and that shouldn’t bring about useless UX. But I stand firm and hence behind both Google and Apple, inform the user what went wrong.

Get the latest in Design, once a week, for free.