Menu Search
Jump to the content X X
Smashing Conf San Francisco

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

New Approaches To Designing Log-In Forms

For many of us, logging into websites is a part of our daily routine. In fact, we probably do it so often that we’ve stopped having to think about how it’s done… that is, until something goes wrong: we forget our password, our user name, the email address we signed up with, how we signed up, or even if we ever signed up at all.

These experiences are not just frustrating for us, but are bad for businesses as well. How bad? User Interface Engineering’s analysis1 of a major online retailer found that 45% of all customers had multiple registrations in the system, 160,000 people requested their password every day, and 75% of these people never completed the purchase they started once they requested their password.

To top it off, visitors who are not logged in do not see a personalized view of a website’s content and recommendations, which reduces conversion rates and engagement. So, log-in is a big deal — big enough that some websites have started exploring new designs solutions for the old problem.

Is This You? Link

Gowalla’s sign-in form (below) looks pretty standard: enter your user name or email address and your password, and then sign in. There’s also help for those of us who have forgotten our password or are new to the website. In other words, all of the most common log-in user-interface components are accounted for.

The sign-in form on Gowalla.

But Gowalla has taken the time to include a few more components to help people log in with more confidence if their first attempt hasn’t worked. If you attempt to sign in with a user name (or email address) and password that do not match, the website not only returns an error but returns the profile image and user name of the account you are trying to sign into as well:

A log-in error on Gowalla.

Including a profile picture provides instant visual confirmation: “Yes, this is my account, and I may have forgotten my password,“ or “No, this isn’t my account, so I must have entered the wrong user name or email address.” In either case, Gowalla provides a way to resolve the problem: “This isn’t me” or “I don’t know my password.”

The Q&A website Quora4 takes a similar approach, but it doesn’t wait until you are done trying to sign in before providing feedback. Quora’s log-in form immediately tells you if no account is associated with the email address you have entered, and it gives you the option to create a new account right then and there:

Quora instantly lets you know if there are no matching accounts for the email address you have entered.

If the address you have entered does match an account on Quora, then the account’s profile image and user name will appear to the right of the log-in form. This confirmation is similar to Gowalla’s but comes right away instead of after you’ve submitted the form.

If the email address you enter on Quora matches an account, you get visual confirmation instantly.

Instant Sign-In Link

Quora’s log-in form also includes an option to “Let me log in without a password on this browser.” Checked by default, this setting does just what it says: it eliminates the need for you to enter a password when re-logging into Quora. All you need to do to enter the website is click on your profile picture or name on the log-in screen.

Quora’s one-click log-in page.

To go back to the standard log-in screen, just click the “x” or “Log in as another user,” and then you can sign in the hard way: by entering your email address and password.

While one-click sign-in on Quora is convenient, it doesn’t really help you across the rest of the Web. For that, many websites are turning to third-party sign-in solutions.

“Single-sign-on” solutions8 such as Facebook, Twitter, OpenID and more have tried to tackle log-in issues by cutting down on the number of sign-in details that people need to remember across all of the websites that they use. With these services, one account will get you into many different websites.

Sign In Options9
A sampling of single-sign-on solutions.

Logging in this way is faster, too. When someone connects their Facebook or Twitter account to a website, they simply need to click the “Sign in with Facebook (or Twitter)” button to log in. Of course, they need to be signed into their Facebook or Twitter account in order for it to work with one click. But with 50% of Facebook’s 750 million active users logging into Facebook10 on any given day, the odds are good that one click is all it takes.

You can see this log-in solution in action on Gowalla (screenshot below). A Gowalla user who has connected their Facebook account needs only to click on the “Log in with Facebook” option in order to sign in — provided they are already signed into Facebook, of course. If they’re not signed into Facebook, they’ll need to do that first (usually in a new dialog box or browser tab). After doing so, they will be instantly redirected to Gowalla and logged in.

Gowalla provides an option to log in using your Facebook account.

New Log-In Problems Link

But with these new benefits come new problems — usually in the form of too many choices. When faced with multiple sign-in options on a website, people do one of the following:

  1. They remember the service they used to sign up (or that they connected to their account), and they log in instantly. This is the best case scenario.
  2. They assume they can sign in with any third-party service (for which they have an account), regardless of whether they have an account on the website they are trying to log into. The thought process for these folks goes something like this: “It says I can sign in with Facebook. I have a Facebook account. I should be able to sign in.”
  3. They forget which service they used to sign up or if they used one at all, and thus hesitate or fail to log in.

To make matters worse, if someone picks the wrong provider, instead of signing in to the service they’re trying to use, they might end up signing up again, thereby creating a second account. While a website can do its best to match accounts from different services, there’s no completely accurate way (that I know of) to determine whether a Twitter and a Facebook account definitively belong to the same person.

So, while third-party sign-in addresses some problems, it also creates a few new ones. In an attempt to solve some of these new sign-in issues, we’ve been experimenting with new log-in screen designs on Bagcheck.

Our most recent sign-in screen (below) is an attempt to reduce confusion and prevent the types of errors I have just described — admittedly, though, at the expense of one-click sign-in. In this design, people are required to enter their user name or email address to sign in. We use instant search results to match their input to an existing user on the website, so someone needs to type only the first few letters of their name to find their account quickly. This tends to be much faster than typing an entire email address. But because more than one person is likely to have the same name, we provide the ability to sign in with an email address as well.

Once someone selects their name or enters their email address, then their options for signing in are revealed. No sign-in actions are shown beforehand.

Bagcheck sign-in12
The current Bagcheck sign-in screen does not reveal any log-in options until you select your name or enter your email address.

True, in this design people can no longer sign in with one click, because the sign-in buttons are not visible by default. But this may be a trade-off worth making, for the following reasons:

  • We keep people signed in until they explicitly sign out. So, hopefully people will rarely need to go through the sign-in process. Remember: the less people need to log in, the fewer sign-in problems you’ll have!
  • The added amount of effort required to sign in is small: just start typing your name and select a search result, or enter your complete email address, and then click the sign-in button. It’s not one-click, but it’s not a lot of work either.
  • Trying to sign in with an account provider that you have not set up on Bagcheck is no longer possible, because the log-in buttons don’t show up until after you have selected your name. This cuts down on duplicate accounts and confusion over which account you have signed up with or connected (especially on different browsers and computers where a cookie has not been set).

On mobile, however, these trade-offs may not be worth it. Logging into a website on a mobile device by typing is a lot more work than just tapping a button. So, in the Bagcheck mobile Web experience, we’ve kept the third-party sign-in buttons front and center, allowing people to log in with just one tap. It’s just another example of how the constraints and capabilities of different devices13 can influence design decisions.

The Bagcheck mobile Web experience keeps one-tap sign-in options visible.

Since launching this log-in experience on Bagcheck, we’ve gotten a lot of great feedback and ideas for improving the interactions. Many people have suggested using browser cookies to set a default sign-in option for returning visitors. While this might help people who return to the website using the same browser, we’ve seen many more sign-in issues when people use a different browser or computer. In these cases, a browser cookie won’t help.

Another common question is whether allowing anyone to search the list of Bagcheck users by name or email address reduces security. While this design does somewhat reduce the security of a Bagcheck account (compared to our previous log-in screen design), it’s no worse than many websites that let you sign in with your public user name, like Twitter.

And because all Bagcheck profile pages are public, users can be searched for on Google and on Bagcheck itself. Despite this, we’ve seen a bit of increased concern over this same search capability being on the sign-in screen. So, if you’re thinking about trying this design, make sure your profile pages are public, and be aware that people may still be a bit sensitive about it.

We’ve All Got Email Link

Although signing into a service with one’s name may be too new for some people, logging in with an email address is common practice for most. Using a solution that brings together a lot of the ideas outlined in this article, Google’s Identity Toolkit15 and Account Chooser16 allow people to sign in across the Web using just their email address:

Google’s Identity Toolkit allows people to sign in with a number of email verification options.

When multiple accounts have been accessed in the same Web browser, each account is listed as a sign-in option, making account selection easier. If you want to try out this sign-in solution, you can opt in18 on Google’s website or implement it on your website with Google’s Toolkit19.

Selecting from multiple accounts on Google’s experimental sign-in page.

The Little Things Matter, Too Link

The Bagcheck and Google examples we just looked at try to rethink log-in pages in big ways. But not all sign-in innovations need to be so comprehensive. Even small changes can have a big impact. For example, I mentioned earlier that inputting text precisely on mobile devices can be harder than on full keyboard computers. Coupled with obscured password fields, this can make logging into a website on a mobile device a challenge.

Facebook’s mobile Web experience21 tackles this in a small but useful way. If you enter an incorrect password when trying to sign in, the website will change the password field to plain text so that you can actually see your input. Facebook also offers an alternate way to log in, using your email address or phone number (screenshot below). It’s a small enhancement but one that can go a long way on mobile.

Facebook does a lot to help you log in on mobile.

It’s Not Over Link

As these examples illustrate, even the most common interactions on the Web (like logging in) could benefit from new ideas and design improvements. Not every idea I’ve walked through here will become part of all the log-in forms we encounter on the Web — chances are none of them will. But without trying, we’ll never know.

So, if you have some new ideas for signing in or any other Web interaction we’ve come to take for granted, try them out and let the rest of us know what you’ve learned!

Online Resources Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26

↑ Back to top Tweet itShare on Facebook


LukeW is an internationally recognized Web thought leader who has designed or contributed to software used by more than 600 million people. He is currently Senior Director of Product Ideation & Design at Yahoo! Inc., author of two popular Web design books, and a top-rated speaker at conferences and companies around the world. You can follow Luke on Twitter at lukewdesign or by using RSS.

  1. 1

    Most of these techniques would allow a third part application to know that an particular email, person, name … is registered on a website.

    Which totally helps for fishing.

    Or for identity theft.

    • 2

      I agree with you Simon.

      I have recently been creating a secure log in page for my own login page for my own application. If you offer a returned list of people on the name/ email input then you are showing people who have an account.

      However, this is still a nice feature and is a shame that security/ user protection will always be at the top of the list when creating secure applications.

    • 3

      Diego Fernandez

      August 22, 2011 6:16 pm

      Actually the display of the login picture is for security reasons: is to make phishing more difficult. Other technique is split login: first the user name, then show the avatar before entering the password (in that way is more difficult to make a fake version of the login).

      I learn about this technique while talking with an online banking security expert about the usability of login forms and security.

      As other commenters I agree that’s a solution with ugly consequences.

  2. 4

    Surely any service that presents a list of valid usernames at the point of login has just reduced their security (increased hackability) by 50%. I have to say i’m not a fan!

  3. 5

    As a side note to Quora section. By saying “There is no account with this email address” you may also be exposing that there _is_ an account with an email address (when the form returns only a password error) if someone is attempting to login maliciously and therefore halves the amount of information they have to guess.

    This might expose that a person is a member of a website that perhaps they should be e.g. having an account on a sports betting website.

    At (a sports betting website funnily enough) we didn’t show a “your account exists, but you password is wrong” message like this on the front end (because of the risk of ‘outing’ members). What we did do was email the member behind the scenes saying that someone (perhaps themselves) was trying to log into their account, and if it was malicious then to get in touch.

  4. 6

    What if I don’t want people knowing I’m a member of a site and they start typing in the same first name I have? Sounds like a horrible implementation from a privacy standpoint.

  5. 7

    I wouldn’t be happy, as a user, if I saw that information like this was made public about me on a site.

  6. 8

    Craig Villamor

    August 22, 2011 3:06 pm

    As Luke says, It’s very interesting to see how context changes the perception of security. The absence of a user search on a site with public profiles would be considered a huge oversight in a product, but when put in the context of sign in it is perceived as a security risk.

    It reminds me of my first time on a ski lift. With the safety bar up, I felt like I was sitting on an incredibly narrow and precarious seat; like I could fall out of the lift at any moment. I hung on for dear life. As soon as the bar came down, I felt as comfortable as if I were sitting on the living room couch. Did the seat suddenly get bigger? Of course not. But my perception of risk was completely changed thanks to a thin little bar placed in front of me.

    Luke, I think this illustrates that even though your solution solves a usability problem, it introduces a perception problem. Sometimes UIs need to be made less convenient in order to communicate more clearly to the user or, in this case, to alleviate fears.

  7. 9


    From a UX perspective, these are all interesting and more user-friendly approaches to traditional login forms. However, some of the examples you list make TERRIBLE security decisions in order to achieve this “simplified” user experience. Bagcheck & Gowalla are the worst in this regard—they’re just begging to be brute force hacked. Here’s why:

    First, both sites tell you if the user you’ve entered is a valid user. Heck, Bagcheck even SUGGESTS users for you. Strike 1!

    But “a public user name (or real name) is public whether or not there is an auto-suggest feature”, you say. “The auto-suggest just makes it easier to log in.” Sure, and it makes it even easier for others to find out your username since it’s all nice and AJAXified (no trial-and-error necessary). With one look at the network inspector, I now have the URL to get your user ID (or whomever’s I want): (urls stripped by comment system)

    Second, both allow a seemingly unlimited number of invalid password attempts without any ReCaptcha or lockout. C’mon, this is web security 101. Strike 2!

    Finally, both password entry pages are accessible via a simple GET request with the user ID as a query parameter. Strike 3!
    Bagcheck: (urls stripped by comment system)
    Gowalla: (urls stripped by comment system)

    Guess how long it would take someone to write a simple Perl script that takes a list of randomly-generated user IDs and hits the above URLs with a set of common passwords?

    These issues can be resolved very simply without throwing away your trendy new login flow:
    (a) Show a ReCaptcha form after X number of failed password attempts
    (b) Make the password entry page a POST, not a GET request. Ironically, this comes straight from the W3C and your former employer’s own “security best practices” document: developer dot yahoo dot com slash security

    I apologize if I came off a bit harsh, but I cannot let insecure practices like these be lauded and spread without educating others about their risks. I hope you understand the severity of these risks and take the necessary steps to protect your users while maintaining your desired UX.


  8. 10

    Jason Featheringham

    August 22, 2011 6:18 am

    These are interesting methods, and definitely improve the experience, but at the cost of privacy. Some of these methods could allow a person to narrow down the list of people they are trying to brute force hack. I would be very cautious using most of these techniques.

    • 11

      Exactly. In the first example shown here, where an image is returned upon entering an existing email address, that will allow the world to know (particularly spammers and hackers) that a particular email address is valid. That is a major security issue if not handled properly.

      An unsuccessful login attempt should NEVER specifically state whether the email or password was incorrect. Rather, it should state that “the username and/or password were incorrect” or something to that effect. That way, someone who may be up to no good, won’t know if anything they’re typing in is actually valid.

      • 12

        I agree with Jason and Jesse. I liked the ideas and thought process about sign-in, but I am concerned about the security aspect of the solutions.

      • 13

        Kage Edwards

        April 12, 2013 9:21 pm

        It’s still a security issue though, as if its returned an account, its evident the email was the one correct.

  9. 14

    I really like this topic since login has become very standardized and I think it’s a good idea to challenge that convention. But I’m afraid I have to agree with some of the other comments that a number of these techniques appear to present security issues. The two things that jumped out at me were the ability to possibly discover a users real name by entering a random email address, and connecting other account logins through Facebook.

    I’m not a security expert, but it seems like hackers could easily exploit both the free information (let’s see what personal info I can find on Luke Wroblewski online. Oh, your favorite color is blue, hope that’s one of your security questions), and connectivity stemming from using your Facebook account to access other online accounts (in other words, if someone hacks one account they could possibly access them all before you realize it, thus causing even greater damage). Once again, I’m no expert, but some of these concepts seem risky.

  10. 15

    Auto-Suggest is a great feature for something internal or for features that require you to be logged in. Using it as a log-in ‘feature’ is at best a silly practice designed to fake some sense of being a member of a community and at worst a gross breach of privacy, made worse by those that not only display your full name but also your associative profile image.

    Hopefully they have an opt-out option for those users who don’t wish to have their name associated with the website or are otherwise concerned with their privacy.

  11. 16

    ID theft risk is in part a function of how well users understand login processes. Responsible users know they should log out of sites logged into, especially on a shared device.

    Using an umbrella login for many sites (but not all) increases login management complexity. Logging in logs you into the ‘meta’ identity, but logging out of subscribing sites does not. This requires users to remember to log out on 2 levels or risk exposing all content accessible via their meta identity.

    It’s also a little scary to offload security considerations to a third party who will bear no responsibility in court.

  12. 17

    Adam Patterson

    August 22, 2011 7:31 am

    I don’t mind using the Facebook and Twitter logins if the site I’m logging into needs access to those services.

    But I avoid using them for unrelated sites/apps.

    We had a discussion around using Facebook, Twitter, and Google as options for our web app but came to the conclusion that people might get the impression that those services might gain access to their Data in our app (legal documents).

    I think people need to stand on their own two feet and let the user take responsibility for their own credentials. If your product is good people will take the 30 seconds to join.

    • 18

      How about this idea:

      Step 1 – The user connects to.
      Step 2 – The user enters his/her e-mail address.
      Step 3 – The user access his/her e-mail account and then opens up a link which authorizes the session and returns a special key to the user (this is the part that could still use a lot of brainpower, the key should be unique and hard to generate, but comparably easy to remember, it’s a real toughie).
      Step 4 – The user can now use this special key (or “access pass”), on every site connected to this centralized login-system.

      An important part of this is that whenever a user enters his/her contact information on any site (this would only be necessary if no information can be found in the login-system already), this information is stored in the login-system.

      It wouldn’t take long for extension developers to spread a small plug-in which can help you keep track of the once-or-twice inevitably inescapable hard-to-remember access keys.

      The similarities are really close to that of “Login with Facebook” or OpenID, but the idea is to eliminate the usual email/password scenario. I’m tired like a mother(…) not simply having a universal key to go where I need to go and let me do my own thing. The whole authorization process is in this way transferred to your e-mail service, like, for instance, Google’s Gmail. The generated “access pass” can be used on your smartphone, laptop, workstation, a random public computer and anything else you might be standing in front of with access to the Internet.

      • 19

        Check out LaunchKey. Widget gets integrated to web site. All authentication is done via mobile phone.

  13. 20

    AND. How hard would it be for a malicious site to create a fake version of this login system where a popup visually identical to Google’s collects meta identities? Ooops.

    If you are going to whip out the master key, it should be something you do securely BEFORE you start visiting

  14. 21

    Mário Almeida

    August 22, 2011 7:34 am

    I’ll just repeat what has already been said, but…

    Looks nice, but all these examples lead to little or no security. Login forms should never state which field is incorrectly filled.

  15. 22

    cancel bubble

    August 22, 2011 7:48 am

    Everyone has already said what I came here to say: Privacy and security. The auto suggest on login is especially bad.

  16. 23

    complete security compromise for what? Convenience? I don’t think so!

  17. 24

    To everyone calling out security issues… a site with public profile pages by default has a searchable index of members. You can search that list through Google, Bing, the site’s search feature, etc. This is NOT something new being added to just the log in feature.

    A site with public user names has the same level of security. You can search by user names using any of the methods above. These sites allow logging with username and password.

    So please tell me what the “security compromise” is here??

    • 25

      I think security concerns vary according to the nature of the site. But publicly associating real names, email addresses, and avatars by default is not a good idea. If people want to expose themselves to whatever risks may come from it, that should be their call. But it has been shown that a screen cam and facial recognition software can identify random people reliably from public facebook profiles.

      IMO this meta ID approach is not very secure. It’s better to have it sandboxed in the browser. As it is, it requires the user place a lot of trust in any site that uses it.

      On your Bagcheck site, for example, you have this language:

      “This application will not be able to:
      Access your direct messages.
      See your Twitter password.”

      IMO, that shouldn’t be necessary.

  18. 26

    When a login fails, my understanding is that security best practice prescribes to not tell the user (potential hacker) if the email address / username or password caused the login to fail.

    Some of the other sites mentioned above do break this security rule as well but you are making this information more easily and explicitly accessible, which I think causes the above comments.

  19. 27

    This is an excellent article, but you don’t entirely cover one point which is pretty important that I’d love to hear your thoughts on. How best to authenticate and identify users? This is actually a very difficult problem to solve. I can see that you have approached it with the management of user accounts + ‘integrate’ it with a few providers. But that presents one major failure with OpenID, which is the issue of merging accounts and email address changes. How do you solve that problem in the least confusing way?

    A question was recently asked on Quora which details this point further:

  20. 28

    @Ian what information? Your name or username? Cause that’s what Facebook, Google+, Gowalla, Quora, Twitter, Bagcheck, etc, etc do. They have PUBLIC profile pages. You can choose what you show on these pages but joining the service creates a public page for you. That’s what happens when you sign up (which is your choice).

    @Kevin that’s still a good best practice but in the case of a service like Twitter (or any service with public user names that allows you to log in with username & password), it’s a moot point. Anyone can see there is an account with the username by searching, browsing, etc. on the site. So the only part that’s unknown is the password.

    Same thing is true for Facebook. Type an email address into the search field at the top of any Facebook page and you will find the user with that email address on the site.

    Just between the Twitter (200M accounts) and Facebook (750M accounts) examples, there’s 950 million accounts in this “insecure state” you are concerned about.

    I’m NOT saying public profile pages are for every site on the Internet. But for the sites that have them… they already have the level of insecurity you are describing. It is NOT an artifact of any of these log in page designs.

    Hope that clarifies things?


↑ Back to top