UIEtips Article: Account Sign-in: 8 Design Mistakes to Avoid
January 4th, 2008
There’s nothing that’s as ubiquitous on the web as account sign-in. Create a new user account and you turn a visitor into a long-term customer. Few things can be as important as having user accounts.
The ironic thing is, while we add account registration and sign-in features to enhance the user’s experience, in doing so, we create all manner of user experience problems. Despite its prevalence, one of the most difficult things to get right is a good sign-in and registration process.
The challenge is one of creating selective usability. We want the process to be completely usable for our customers and users. We also want it to be unusable for the bad people who want to steal our identities and disrupt our environment. Creating a design that is usable to a subset of users seems to be much harder than creating one that is usable for everyone.
Today, in our UIEtips email newsletter, we published my latest article that describes eight common account sign-in mistakes we see all the time in our usability tests. If you’re designing an account system, or already have one, this should serve as a good start to assess how much you may be frustrating your users.
Account Sign-in is just one topic we’ll discuss at the UIE Web App Summit, March 26-28, 2008, in San Diego, CA. You’ll want to reserve your seat today, as we’re filling up quickly.
Has your design suffered from these mistakes? What have you done to improve it?
Tweet
January 4th, 2008 at 12:28 pm
Great article, thanks Jared. After reading the subject line, I was expecting a broader topic, not just ecommerce account-related. For example, for account sign-in with financial management websites, your #1 and #2 mistakes aren’t always appropriate. There users want to sign-in early, and quite often.
January 4th, 2008 at 1:18 pm
A client of mine once asked that I make the registration process a bit more work to cut down on the number of leads he was receiving. He wanted fewer more motivated leads. Always a few exceptions
January 4th, 2008 at 1:52 pm
Nice list. Here’s a couple more, related to failed sign-in:
Erasing User ID input when sign in fails
Probably like most people, I have a couple of user IDs and a couple of passwords. I can never remember which ones I used for a particular site, so I need to use some trial-and-error. This usually starts by trying different passwords with the same user ID. If the user ID gets erased, I have to retype it every time. Annoying, especially if the ID is longer (e-mail address).
Erasing ‘Remember me’ preference (checkbox) when sign-in fails
Just because I couldn’t provide the correct User ID/Password combination straight away doesn’t mean I’m not interested anymore in having my sign-in info remembered for next time. In fact, my failed attempt suggests it might be really useful to have this info remembered. I regularly end up being signed in without ‘remember me’, because I didn’t recheck the box on each try. Which means that next time I use the service, I’ll be in the same situation.
Remembering a user ID / password combo that doesn’t work
If I check ‘remember me’, the next time I use the service, I don’t want it to suggest input that won’t get me signed in.
January 4th, 2008 at 2:24 pm
“Cisco, during their four-page registration process, asks the users to specify the number of items presented in search results.”
That is the stupidest friggin thing I’ve ever heard of. I mean, really, that’s outrageous.
Damon’s additions in the comment above are great. Handling errors gracefully is absolutely critical in sign-in flows.
January 4th, 2008 at 2:25 pm
I find it interesting and frustrating that an article about usability does not have a place for comments on the page where I am reading the article. I had to go the email, or use the back button to find this page for comments. In forwarding the article to colleagues, most will not have the link to the comments page.. if I forward the link to this page, it is likely most will miss the link to th3 article and not read it.
What is the rationale for not having comments for the article? Feels fragmented and confusing to me.
January 4th, 2008 at 3:00 pm
All good points, Jared. We have implemented most of your suggestions with great suggest.
However, one of the most common complaints we get from our customers is the difficulty remembering their username. We would like to change it to email address (like most ecommerce sites), but not sure how to go about the transition.
We don’t want to make all of our customers re-register, but what is the alternative? Any suggestions on how we could avoid a usability nightmare, when our end goal is to make it easier?
January 4th, 2008 at 3:17 pm
have to add one.
Not Providing a Decent “Session Expired” Page…
You’ve left your browser open for awhile and your login session expires, you click
on one of the links, and wham! You get a weird error message saying “invalid exception”
or something equally unintelligible. So many site miss this “error” condition and don’t design
a page telling the user what just happened and what to do about it (log in again)
January 4th, 2008 at 5:13 pm
In addition to these suggestions it’s good practice to place the user’s visit in context. You shouldn’t ask them to register if they have already registered, you should ask them to sign in. A cookie is an easy way to provide different experiences to user’s based on if they have signed in before or not.
January 4th, 2008 at 6:02 pm
Another error handling improvement I’d like to see is *specific* error messages. If my login attempt fails, there is no value in this error message: “Either your username or your password is incorrect.” That tells me nothing — at least, nothing I couldn’t figure out on my own — and leaves me right back where I started. It’s much more helpful to learn, “That user name does not exist in our system,” or “The password you entered does not match the username.”
January 4th, 2008 at 6:29 pm
[...] this trick before we let you make a purchase – Account Sign-in: 8 Design Mistakes to Avoid In usability test after usability test, we see the registration and sign-in processes to be [...]
January 5th, 2008 at 8:02 am
[...] a lot worse for the user. And in some cases that can mean loosing a potential customer. In the comments on his weblog there are some more good tips. Posted inUability, User Experience | | You can [...]
January 7th, 2008 at 1:23 pm
Marla, I believe there’s a security reason for not being specific on whether it was the user ID or the password that was unrecognized. That said, I have seen some sites that *will* tell you if you used a non-existing user ID, which might be fine for services that don’t require that much security.
January 7th, 2008 at 8:55 pm
I love this list, particularly because it encapsulate several of the more difficult issues to prototype, document or mock up and deliver to an engineering team. Seems like the easy part of desiging a signin form is the form itself. Describing where, how and when it should appear, and the nuances of handling sessions, “remember me”, cookies, etc…well, the devil is in the details. Nice list =]
January 8th, 2008 at 4:30 pm
What about the financial industry use of multi-factor authentication? We implemented this recently and have managed to cheese off a bunch of users. Are there any good guidelines or recommendations for that sort of implementation?
January 18th, 2008 at 5:01 am
[...] as it support the user task. May:Don’t require login if you don’t have to. – again, Jared Spool (I follow his articles and podcasts regularly). June: Who said usability should be boring – all fun [...]
February 7th, 2008 at 5:50 am
[...] Account Sign-in: 8 Design Mistakes von UIE Brain Sparks [...]
February 14th, 2008 at 8:39 pm
There’s an excellent example of ubiquitous registration with the Tripit service. No forms, just send them an email and you’re registered! Beautiful…
April 3rd, 2008 at 4:05 am
Having to create an account to merely browse products on a site is a sure-fire way of deterring users from staying around. It also removes itself further from matching the system with the real word. There aren’t many high street stores that require details of the customer before they can shop there.