Sign on, Login: Better Practices for Logins and Registration

Stephen Turbek

To an expert user, it is easy to forget the obstacle that registration and login pose to many users. Forgotten user IDs and lost passwords are a consistent problem, frustrating users and preventing sales. In my project work, lost password requests remain the number one customer service issue. Making this process simpler and easier for the user to recover will provide one of the greatest return on investment in user experience from reduced customer service costs.

To that end, here are some better practices for improving logins and registrations.

Avoid unnecessary logins and registrations!

To the user, Logging in is seen as a necessary evil, standing in the way of getting what they really want. Require login only for those actions which cost money or put user information at risk

Ask for Log in or registration as late as possible, e.g. right when the user wants to complete an action. When a user has a clearly defined goal in mind, login is perceived as less of an impediment. Forcing a log in too early will make some users leave because they do not see it furthering their goals. They may not be sure they have a goal yet! . In an E-commerce example, enable the user to see their shopping card, but require a password to complete a purchase.

Development teams often prefer to separate the site into public and secure areas for ease of programming, but it is worth fighting for this issue to improve the user experience. Design the site to give a graceful increase in functionality to all levels of logged-in-ness

Unknown users

Display some content or meta data without a log in -e.g. Article abstracts, song clips, document titles, but not the documents.

The goal is to enable the user to confirm they have made the right choice before committing to login

Communicate the benefits of logging in. A good example is "Sign in to get personalized recommendations".

Identified users

The user identity can generally be saved as a cookie to increase convenience to the user (one less thing to fill out) and provide some functionality for example, site personalization. Amazon shows non-critical information such as recommendations and wish lists.

Logged In (user logged in this session)

Require the user to log in only when the user requests to access personal information or to purchase. Amazon shows a "your account" page. Clicking on the customer service links prompts the user to log in.

Use their email addresses as the ID. This reduces users who forget their ID, prevents duplicate ID requests, captures the users email for future communication (including password reminders emails). There needs to be an additional recovery process, such as a customer service line, for users who lose their email account.

Enable them to recover from login errors quickly without leaving the interface.

1. Emailing password reminders is easy and pretty secure, but forces the user to switch applications. They may not return -especially if the email takes (or if they believe it will take) more than a few seconds to arrive.

2. Enable them to get access by answering a security question they selected, [google screenshot] or better, by providing a secret piece of information relevant to the account, such as the registered credit card number or social security number.

3. Requiring users to select another password is a significant hurdle for users to get over. They likely reuse the same passwords on many sites and are hesitant to choose another. Instead, give them the option to send an email with the password.

4. Enable them access without showing them the password (which the user likely uses on multiple sites).

Be clear rather than cutesy. Yahoo clearly explains the duration of login. Microsoft Outlook web mail attempts to explain when to use each option.

As with all invisible features, it must be clearly communicated. I observed a usability test on a site that retained login via cookies. Oddly, it was also a requested feature! It turned out that the logout link erased the cookies. The users, having been trained to log off secure sites, were unintentionally removing the functionality. A help message like "To stay logged in, just close the window" helped.


Registrations reduce usage. Period. Question whether you need one at all, and how small it can be made. Marketing departments may sometimes push for registrations before showing content in an attempt to get to capture information about the customers. For low or unclear value items, such as an e-book, this may greatly reduce the number of users. They simply don't know if it is worth giving personal information yet. Remind them that each additional step reduces the number of people who will complete the task. Its better to have 3 customers that you don't know then 1 customer you do.

For example, the default installation of OScommerce (a popular e-commerce package) requires the user to divulge their Gender, an intrusive and practically useless feature for most e-commerce sites.

Integrate registration into the user goals. Many sites require the user to fill out a registration form before they can act. In most cases, the user will enter the same information in the process of achieving their goals, e.g. buying a product online requires a mailing address, email, etc. As the user understands why the information is needed, it is seen as less of an obstacle. Generally, a registration can be completed at the end of an order, merely by asking the user for a password.

Registration can have a positive user experience benefit.

The opposite, anonymity, can have a negative effect on a user community. A personal blog typically tries to encourage readers to comment, but highly trafficked sites may find that anonymous commenting degrade the user experience with uninteresting and offensive comments.

Additional Security

Some banking sites attempt to prevent "phishing" (where a hacker creates a site imposter to capture usernames and password) by displaying user selected images and phrases after the user enters their username. This adds a step to the login process and was shown to be ineffective. In one study, 92% participants ignored the wrong images and logged in anyway.

For corporate users, Blackberry devices, having their own password, can be considered a secure device. Applications they access can bypass the login process, a simple and effective usability improvement.

It has become popular to validate the username via AJAX as the user types. Confirming the username without the password does make it less secure, by making it easier to find an active username. By having the delay be greater than a second, it becomes unprofitable to do this on a large scale.

Similarly, you can protect your users accounts by doubling the delay after each login attempt, quickly make it infeasible to crack the accounts.

This type of security precautions are important on any site, as users tend to re-use the passwords on their email and banking sites.


My review of major US and UK bank sites showed "Log in" used slightly more commonly than "Sign In", "Sign On", "Log In", or "Log on". There is unlikely to be a usability issue with any of these standard terms.

Use the home page for the login page.

For many sites, logins will be the first step for many users. Make this as easy as possible with a login form on the home page and a log in link in the header of all other pages.

Some developers will resist putting the login form on the home page as it would require the whole page to be encrypted with SSL. Using iframes, this is no longer necessary.

A side benefit of the login form on the home page is that will help the home page (with its marketing) get seen by your customers. An analysis I did of site traffic on one site showed that a high percentage of users had bookmarked the login page and were not seeing the marking messaging on the home page.

I hope these tips have been useful for you!