Five UX antipatterns to avoid when designing Log-in & Registration areas

Note: This post might be a little dated. It was published in April 2009.

Registration and log-in areas have been a common feature on the web since – well – since forever really. With this in mind, it’s amazing how many top name sites deliver frustrating registration and log-in experiences that not only annoy their users, but also impact their conversion rates and chip away at their profitability. This post highlights five User Experience (UX) antipatterns, and explains how you can avoid them in your own designs.

input amnesia UX antipattern

Example: youtube.com

Problem: the user fills in the registration form, but makes a few errors. Upon submitting, they not only get an error message but also find their chosen password has been wiped out. So they have to enter it again, and perhaps even a third time if they are unlucky. They get pissed off and a small but notable proportion of them give up.

Solution: where possible, use JavaScript validation to ensure fields have been completed correctly – this avoids the password fields being wiped out. Another common mistake is to forget the user’s email address between the log-in and ‘forgotten password’ page. It’s rude to make users repeat themselves, whatever the context.



wrong destination ux antipattern

Example: Archive.org

Problem: when a new user finds a video that they want to comment on, they are required to register. Upon completion of the registration process, where do you think the site drops them off? At the video they wanted to comment on? No – instead the user is taken back to the home page, so if they want to add their comment they then need to search for the video by hand. By this time, a proportion of users will have lost interest or forgotten what they set out to do. It isn’t a catastrophic failure – but it’s a failure all the same, and if you make this mistake for revenue-critical user journeys, you will pay the price.

Solution: always keep track of any activity the user sets out to do, and pipeline them back into it when they complete log-in or registration. This keeps them focused and will reduce drop out.



dead end ux antipattern

Example: Vimeo.com

Problem: users sometimes attempt to register without realising they already have an account with your site. It’s easiest for developers to just give them an error message, and leave the user to make their own way to the correct form. Vimeo, for example, does exactly this. Again, this isn’t a catastrophic failure. but it’s careless and shows little consideration for your users.

Solution: it’s unkind to leave them in a dead end with only an error message for guidance – it’s much more helpful to reroute them automatically, or at least give them a prominent link through to the log-in area. (Caveat: some large sites are attacked so relentlessly that they will not divulge whether a username is valid, since this is useful information for attackers. However, the risk is mitigated through the use of failed log-in throttling).

unnecessary captcha ux antipattern

Problem: the user has difficulty reading the text in the CAPTCHA. They often have to try more than once, causing frustration and increasing the drop out rate. For example, Sampa.com reported that they achieved a 10% uplift in conversion rates by removing CAPTCHAs. That’s money on the table.

Solution: a CAPTCHA should be a last resort, having tried other alternatives. For example you can use a honeypot technique, that uses a form field that’s invisible to a user but visible to a bot – if it gets filled in, you know it’s not from a human. Or you can experiment with softer CAPTCHAs like riddles or simple math problems. The best tactic is to start as soft as possible, and only ramp up if bots become a real problem.



unnecessary email verification antipattern

Problem: an email verification barrier is a way of confirming that the user attempting to register does in fact own the email address they are registering with. It works by sending the user an email containing a link, that they must then click. On many sites, if the user does not do this, they aren’t allowed to log in, and are left standing out in the cold. Some users can’t find the message in their inbox, and others get side-tracked when they see other unread emails. By encouraging them to leave your site, you open the door for many uncontrollable factors.

Solution: the real question you should consider is whether you really need an email verification step, and if you do, where it needs to live. Although I’ve named myspace as an offender, they do have to deal with epic proportions of spam, so they at least have an excuse. Hi5, though, being the underdog, are working far harder to build their userbase. It is rarely necessary to lock your users out completely. It’s far more effective to let them in, but block them from doing the one or two things that genuinely need email verification. For example, let them log in, but don’t start sending them loads of emails until they’ve verified that they do indeed own that email address (this ensures your email server doesn’t get a punitive spam score). Similarly, if you have any private information about that email address, don’t reveal it to them until you are sure they are who they claim to be.



Lazy Registration
It almost goes without saying, but one approach that often delivers an excellent user experience is to remove the registration barrier entirely and opt for a lazy registration model. You can find out more about this in the lazy registration demo that I posted last month.

Security vs. User Experience
I have to finish this post with a big caveat about security. There’s always going to be a tension between security and usability – in fact, when you notice a UX antipattern somewhere, it’s probably the result of an enthusiastic security policy. If you’re lucky enough to have a very successful site, you may find it becomes the target of specific and sustained attacks. If that happens, you may have to batten down the hatches and ignore some of the recommendations in this post, such as adding CAPTCHAs regardless of the usability implications. However, if you’re really smart, you’ll find a way to deal with bots and provide a great user experience at the same time.



Other resources:

17 comments