You and your team have worked hard on this one, it’s a showcase site. The users (via testing) are all happy too, they just love all the community building features.
And yet six months later the site just isn’t getting traction with the community, people just drift away. Everything seems perfect so what can be wrong.
Well have you considered looking at the basics? Even a small component of the site can have a dramatic effect on the user experience. For instance if the login process itself is producing a poor experience then people will be reluctant to use it. In the worst case it will be stopping people logging back into the site, hence no community, no repeat sales, no success.
Most of the time the problems are simple ones, still even small problems can give a negative experience. And you really don’t want any negative experience if you can help it; as you know every instance builds up with a user and this can lead them to walking away from the site altogether, as soon as they get a better offer.
True people will nut in out and try and work around any usability issues, we all love problem solving, it’s in our nature. But you have to consider that as the web becomes easier to use people are becoming less tolerant of bad interaction design and will seek out alternatives, dependent on their investment in your site.
Login interaction design appears to be simple, and it is, as expected there are numerous elements that contribute to the final design considerations such as:
Still with all these elements taken into about there are still simple things that can detract from the experience being a good one.
-
Usernames
It’s becoming a tradition to have the username as an email address nominated by the user.
Studies have shown that people have enough trouble remembering their passwords without having to recall a username as well. Making the user name something people can remember helps in the process.
However making people use a membership number or an allocated username does not help at all.
So if you must use alternative to a email username at least let people personalise the account for the web application with their own login username.
Sure there can be issues with the approach of using a username email adddess in terms of:
- Recycled email addresses with some service providers
- Change of name
- Varying email formats
But seriously a good developer can get around these issues, just be sure to document them.
-
Password Length
In this new age, we are constantly being reminded of the security strength of our passwords. You know the drill, the longer the better; the more special characters the better.
Well with the advent of password memorising applications and autofill browsers you would be expecting the passwords fields on web applications to be getting longer, being able to take passwords from 64 to 256 characters and beyond. With the days of the old 8 character password disappearing rapidly.
Yes this is occurring. However we seem to be at the transition period at present.
There can be problem when registration password fields and login or the database fields do not have the same length. The result in the best case is the truncation of the password the user selected. In the worse case the entire record is not accessible at all.
Interesting side note, banks in general refrain from passwords with special characters or that are over 12 characters. This is really due to their legacy systems in use, not their web services. Most web services do not have this restraint; so don’t follow the old model.
The solution is simple. By get it right in the design documentation, ensuring you define how long the passwords are going to be, and testing for this upper limit; some of this issue should be removed.
Also telling the user, at least during the registration process, how long the password length range should be with textual message next to the field. Remember people will not know the details like this about you web application unless you tell them.
-
Form Validation
We are not all prefect, sometimes we miss type usernames and passwords.
Now we know that with passwords they really need to match exactly for security reasons.
However let’s ease up a bit on the usernames. For instance, if the username is an email address then it would be nice to know that I have typed “.con” instead of “.com” before a submit the login form.
In this cases a little AJAX style validation on the username to determine if it is the right format would help make things a little easier.
Also consider what happens when there are extra spaces before or after the username. You see they are not going to appear on the screen to user, but in reality it is an invalid username as it has an extra space at the end.
It’s simple to overcome, just trim the username field. Either client side or server side (both is better) , but the important thing is remember allow for a little interactive validation smarts and attempt to determine what the user had intended the username to be.
-
Persistent Login
There used to be a time when you could login to a web application and remain logged in until you logged out. Isn’t that what the “remember me” or “keep me signed in” checkbox is for. Granted these are not life critical services like online banking or finances.
However recently it all seems to have changed, now “remember me” means “remember me for a short period of time”. There is a distinct trend growing for web application requiring you to login again after a week, two weeks, or thirty days and so on.
Yes this is a security measure. But the persistent login only operates on the computer being used. If this computer is in a secure environment, then this just becomes a waste of time. It becomes annoying having to login again and again to a web application that you just want to use seamlessly.
The approach of telling users how long they will be logged in for does help, but only so mush as to say “sure you can use this service, but after two weeks we need you to confirm who you are again”.
A better approach would be at allowing the user to set the period of time for the persistent login. That way everyone will be happy. A user could have it set to two weeks, six months or forever, or something in-between. After all is the user’s login and their data, surely users are adult enough to deal with this.
-
Field Placement
The placement of the username and password fields on their separate login page is usually a simple affair. Usually it falls into two camps of what the user is expecting as locations, side by side or one on top of each other.
As expected they should be within a close proximity to each other as they are related in their information and functionality. Hence this should be reflected in their spatial location as well.
This can go wrong when the username and password are separated, sometimes by up to a third of the page.
It’s a minor problem in a way, but hunting for the fields on the screen and then wondering if you have the right one, especially if they are several tab stops away, doesn’t really fill a user with much confidence about the web application.
-
Login Link Placement
Just as users have come to expect that the logo will lead them back to home page of the site, people are now expect the link to the login page will be on the top (often right) of the web application.
Placing it elsewhere so that people have to play “hunt the login” is not going to help. Sure users of your application will get used to where it is. Remember however when a user is new to the site is the time when they are most vulnerable to frustrations and will often make a lasting opinion of the site based on the first few sessions, before they learn the application. So you want these experiences to be a good one.
-
Login Link Label
Traditions are the theme with logins, and the login label is no exception. The label people are looking for in the majority of cases is usually “login” or “sign-in”.
Still there are occasions when the label seems to have been lost, in the worst cases the link suddenly becomes words like “opportunity” or “recommendations” or “new features”, nothing to do with login. When users see links in the location where they expect the login to be they do start to question if the link is an advert and what is going to be sold to them.
I know it’s a hard call, marketing want to have the link. It’s better to put in an extra link than mess with the standard one people are expecting to find.
-
Forgotten Username / Password
It has also become a standard to provide a link for the resetting or recovering a forgotten password on the same page as the login dialog. However it is a little distracting having this appear on the page before a user has made any error at all. It’s like it is teasing the user – “come on I know you are going to make an error”
It’s easy to fix. When a user makes the error and gets the login pair wrong, then display the link to the solution so they can recover the password. A little javascript altering a display rule on the relevant CSS is all that is needed.
Another consideration is when a user can’t even recall which email address they used as the username. What do you do here?
Well you have that information available already, via the forgotten password function.
A user can usually determine if they have the right username. If when asked for the username to retrieve the password it comes up with an error message, then they know it wasn’t the right email.
This type of secondary interactive error messaging is something to consider.
-
Error Messages
Error messages for invalid username / password pairs are always an issue with the login interactions. Yes you need to inform the user that there has been an error, because you really don’t know if it is a testing hack or a real user, so the error can’t really say too much.
But we can all over do it sometimes. Say you just want to login to list collect web app it’s not Fort Knox, people are not going to live and die over it so don’t treat it like it is.
The usual rules with error messages apply - make them clear. Depending on the content delivery style one should try and engage with the user on a person level.
“Invalid authorisation” - is just plain bad.
“You seem to have typed in the wrong password” – is much more friendly.
For the non-mission critical, low volume applications it would also go a long way to improving the user experience if the user was at least told which part of the username / password pair was wrong.
Finally this really is usability 101, don’t insult people, as has been pointed out with Reddits error messages. Remember users aren’t stupid, they are just human, just like you, they make mistakes, and they are often in a hurry, allow for that.
-
Extra Questions
Having an extra question to validate the authentication of the user has become a popular method with higher security and traffic logins.
While this is a good idea for these situations, studies have shown that it is usually received better when it is on a secondary page in the login process. This allows the user to feel that they are progressing and have been rewarded, somewhat as they have passed the first stage of the process.
Still you should also strongly consider do you really need this extra authentication to start with, can you do it another smarter way, and often this involves more backend coding.
Some alternatives are SMS code conformation, smart tokens, smart card confirmation, enforcement of a stricter password policy, activation of extra questions only when accessed from an away from base computer.
If you have to implement this, please consider a question interface that is accessibility via a keyboard and one that doesn’t require a mouse.
This brings me to CAPTCHAs. I think everyone has a personal hatred for them. If you must use them, please make them accessible at all costs. CAPTCHAs are also the exception to the rule, these are better off on the same page as the username password pair.
-
Page Weight
Does your web application login page really have to have all those button, and graphics that are on the rest of the site? Think about it the core function of the login page is really a transitional one. The user wants to get onto the page and off again as fast as possible. Adding anything but the basics in navigation and branding is going to slow the page down in its loading.
Remember not every one is using a T1 connection to the web. If the page just takes to long to load, the user will start to consider, maybe I can do this later. Have that happen a number of times and they will start looking for an alternative application.
It’s a simple problem to overcome, just don’t tell the marketing guys, look at the page, identify what is core to the use of the page on the site and still makes the page looks like it belongs. Remove the rest; sometimes this can even be part of the extended navigation system.
Of course this is all a little moot if you are using a popup div with the login dialog in.
-
A Word on OpenID
Hang on what’s with number 12. It’s a bonus for the holidays. Seriously, the topic wouldn’t be complete without a little discussion on OpenID.
Yes, I can hear you talking about OpenID and saying that a good deal of these issues can be dealt with via OpenID.
Now I’m not getting into an OpenID debate, but it is just too hard for the non-tech community to use. There I said it.
The paradigm of using a URL as a login is just too far out of the expected and previously experienced behaviours for the general majority of people that they just will fall back on the traditional method of the username password pair, given a choice, even if it does meaning that they will have more logins.
This will change, OpenID will mainstream or it will remain just a techie tool. But until it gets some of the bigger players allow cross OpenID use I would not make it the only way to access a web application.
Reality is it comes down to making the process simple for the user; sure this is going to be more work on the design specification, implementation and development end. But what is in really all about, the sweat and tears of the design / development team or the satisfaction of the customer experience who at the end of the day is the one paying the bills.
Contents
ReBlogger Contents
Email TopXML