Hi all I am developing a login form with multiple login options. The main two options people have is to login with either their email address, or by using their Member ID. I wish it was just an email only, but after discussing with the marketing and membership people for the organization, it seems we just don’t have much choice right now.
So I’m wondering how this will be best handled as far as ease of use, without overwhelming people with a ton of options and choices? Our current login form is completely overwhelming, with two separate forms, and a forgot password link and a new user button. I would like it to work so that when you first get to the main form, you aren’t confronted with so many choices. Ideally, just one set of fields would be great - email, password, and a forgot password or help link.
Problem is, I need to provide two choices - login with email, or login with member ID. I could do a tabbed thing where you first see the email input and a submit button, and if you want to change it to member ID, there’s a tab for that which clicking the tab shows you the login with MemberID field. Another option is to say “Login with either Email address or Member ID” which the user can then enter either one, click Submit, then my programming does what it needs to in the background. Although this seems like the best choice, I’m not happy with that because I would like to signal to users that logging in with email is preferred. So if someone needs to login with their Member ID, I would like there to be another step in the process, whether it’s clicking on a tab or something to show the other form.
Any suggestions as far as best practices for what I’m trying to accomplish? Any example website with multiple options but handles it gracefully with superb ease of use for customers? TYIA!
Why would you prefer it if users log in with their e-mail address? Unless you are dealing with some compelling technical advantage, one input that accepts either datum would seem to be the simple and user-friendly answer.
Probably lack of adequate planning and foresight is mostly to blame…
The technical reason is, our AMS database stores two sets of records for customers. A “Person” record and a “WebUser” record. The WebUser record, which is where the actual authorization takes place, needs an email address (as the UserID) to login.
So the next question you might ask - why use MemberID at all then? We actually have two websites, one of which has been a strictly MemberID-only login for organization members, and the second website (ecommerce) uses Email address login. The ecommerce one is the one that is actually hooked in to the organization’s AMS (and this is the site I am working on). The other site runs on a separate database outside the AMS, although the two sites are now starting to merge. It’s all very messy right now…
Just to add, there is additional complexity for users logging in because they might know their MemberID but they have never set up a WebUser record, meaning those people can’t login at all yet. They have to create a WebUser account first, and we need to know their MemberID when they create it, in order to tie the WebUser record to the proper Person record. (Make sense?) (MemberID is on the Person record, but Email on the WebUser record, which is where the login authorization actually occurs)
The way it is currently set up, people are just going in and creating new WebUser records without knowing they already have a MemberID, or just assuming it will magically find them behind the scenes. We are ending up with tons of duplicate records right now.
The way I figure to control these issues somewhat is to take either their email address or MemberID for the login. That way, whether or not either might be found in the system, I can at least direct the user to take the appropriate action. Example, we can say hey we found your email here, so try using Forgot Password to reset it. Or as another example, we might grab the MemberID, then tell the customer they need to create their WebUser account to continue. There are several situations any one customer might find themselves in, and right now we are giving them the worst possible user experience in dealing with it. (like I said above, we currently have two login forms on the same page, plus a forgot password link, plus a new user button, plus a link to a “Login FAQ”…)
What I want to do is remove everything except: Email/Password field, plus provide a MemberID option.
If registered users don’t, or may not, know that they have an ID, could you do a mail shot to tell them about it? It seems like you need to resolve how you want users to log in and then tell them about it, which would then ease your form problem.
That is a thought we have mulled over, but didn’t come to a resolution on…
My preference for a resolution would be to have only an email address and password for logging in. For customers who only know their member ID, I would like to then direct them accordingly (to a new user creation form, where we can then look up the member ID to pull information from). This customer might then actually have an email/password account but forgot or weren’t aware for some reason. We can still at that point tell them about it, and then give them instructions for resetting the password, and redirect them back to the main email/pass login. This makes most sense to me, but only one problem exists with going this route. One of the managers insists we provide Member ID up front for logging in…
Hence, my need to create a form where we have the option of either entering your email or entering your Member ID…
Your dissenting manager might have a point. At least member IDs are more secure than e-mail addresses.
If you can persuade the relevant people to improve the way in which the records are organised so that only a simple form is needed, it really would be better for everyone. Them, you, and your users. But I can appreciate that it may not be possible. I disagree with your suggestion of directing certain already-registered users to a type of registration form: look at that from their point of view and that wouldn’t go down well. It would certainly annoy me anyway! Surely, working to avoid anything that would reduce business would not be such a hard sell.
Thanks for the feedback, I really appreciate it. Regarding which to use, I guess it comes down to the fact that one site has always used MemberID while the other has always used Email address. Now that the two are starting to merge… a decision needs to be made once and for all.
And perhaps MemberID as the main login field is the better way to go. Unfortunately the database structure might be a limiting factor there. We need to investigate that and discuss the possibility.
