How do I improve my website's registration and log-in process?
January 13, 2015 10:38 AM   Subscribe

I administer the publication sales website for the non-profit I work for, and probably one of the biggest customer service issues we encounter is users being confused by the registration and log-in process. I want to propose a better process, but am hampered by my personal unfamiliarity with web design, and the complication of having a different process for signing on for multiple user types.

Here's the background and how the process works:

-We are a membership organization, and the website was created primarily with the members in mind, but non-members can use the site as well (and we want them to). Members receive discounts and access to member-only products when they log in and their membership status is recognized.

-Members already have an account on our main website, which is tied into our membership database. The sales website is set up to recognize the username and password from the main website/database, so members don't need to set up a new account.

-Non members can register and log into the sales site for free, and again, their user status dictates the pricing they receive for products.

And here is what's making things confusing for users:

-The user must specify their membership status before signing in. We have two tabs set up for the different user types to sign in with, but it requires a) the user noticing the different tabs and making sure they click the correct one, and b) the user knowing what their membership status is. This often isn't a problem for our regular members, but less regular members may not remember if they have an active membership, and non-members frequently think they're members if they've signed up for a mailing list, for example.

-Since the website was set up more with members in mind, and members don't need to register a new user account, the link to register as a new non-member user was considered less important and is therefore relatively hard to find.

-Users can encounter 3 types of errors when attempting to log into the site. They've specified the wrong user type, they've entered the wrong username, or they're entered the wrong password. But the error message they receive does not specify which type of error they are making. So, for example, if a member tries to log in with the incorrect password, the error message they receive reads "Invalid credentials. Non Members, please select Non Member Tab to login." The idea is that it would remind the users to check that they're using the correct user tab in case that is the problem, but it just confuses the users into thinking there is something wrong with their account.

Basically, there are a LOT of barriers to logging on the site successfully, and I wind up doing a lot of education for users just to get them logged in. Our organization and products are in a specialized niche so I'm not as concerned about driving away traffic - if they want our specific book they pretty much have to go through us - but I would like to make the process as painless as possible anyway.

So my specific questions are:

-Do you have any recommendations on how to streamline the process in general? Again, I have no technical background at all, so I'm not sure what fixes are easy to make and which ones would require a huge overhaul of the site.

-What are the best resources for best practices in usability for e-commerce websites that would address having more than one user type? I've been able to find plenty of resources regarding registration and sign-in procedures, but they're all meant for one type of user - I haven't been able to find anything to address my specific situation, and the multiple user types is what is making this so complicated.

(I'm happy to share the URL by MeMail if it would help to view the site itself - I just don't want to make it public.)
posted by Neely O'Hara to Computers & Internet (10 answers total) 4 users marked this as a favorite
The user must specify their membership status before signing in

I am confused about who your users are. People visiting the website.

Do you have all of these? Or just some?
A) Unregistered Users
B) Registered Users with basic account
C) Registered Users w/ membership to the organization
posted by royalsong at 10:47 AM on January 13, 2015

I would switch to one login form, and if the user wasn't a member, I would return the registration form with the email/username filled in and flash a message explaining that they don't have an active membership so must create an account on the sales site. If they had a valid email address, I would kick them back to the login form saying their account information was invalid.

You can't avoid trusting your users to get something right, unfortunately. Right now, you trust them to choose the right form. With the method I described, you would trust them to enter the correct email address (or be kicked to the sign-up process.) I think that's an improvement in your case.

Usability advice for multiple logins is generally going to hide the more sophisticated user (admin, affiliate, seller) login and make the login for the broader, less sophisticated audience (shoppers) more obvious. Maybe non-members should get priority, but it sounds like both types of users are getting about equally confused and neither is more important than the other.
posted by michaelh at 10:53 AM on January 13, 2015

Response by poster: royalsong, visitors to the website who aren't registered can view our products and pubs, but can't access any content (paid or free) unless they've logged in, so we don't really encounter unregistered users from a customer service perspective.

michaelh, that is exactly the kind of advice I'm looking for, thank you!
posted by Neely O'Hara at 11:01 AM on January 13, 2015

When member sign-in processes require the _user_ to specify what type of user they are (as yours does), which is clearly clumsy from a user's point of view, there's usually a reason. That reason usually has something to do with the way the user databases are set up, often because one database was created many years before another user database. Making them work together, so that the sign-in process is more streamlined, isn't going to be trivial.

You probably have one, older, system for keeping track of paid users/subscribers, and an entirely separate and possibly incompatible system for the non-paid-subscriber users.

You're going to have to figure out how to unite those two databases (possibly by hiring someone). And you know nothing about databases, and you may even hear is how impossible that is. Don't believe that -- it's possible, just a little complicated.


What you want is for users to come to the main site, enter user ID and password information, and be automatically logged in with whatever their status is.

Very simple, and what everybody wants. User doesn't have to find a tab, user doesn't have to worry about whether they're paid or not.

After the user logs in, there can be a status message saying whether they're paid or not.

Obvious question: why doesn't it work this way already?

Answer: because it's hard.


Your first step is preparing yourself, and your supervisors, for the probability that this isn't just a simple user-interface issue. It will require someone mucking around with the databases, or at least writing a little server-side code to coordinate between the databases of the different kinds of users.

In the process, you may well discover that there are other things people have been wanting to do with the user databases for *years* -- you'll have to decide if you will allow some of these changes to be rolled into your project or not.


It might not actually be that complicated, of course. I haven't seen how your system is set up. I'm just trying to prepare you in case it is, and letting you know that my own experience suggests that it likely is so, based on the description you've given of the way the system currently works.

If the current site was set up by someone who didn't know much about setting up _or using_ the web, then there's a possibility they did it this way just because it seemed like a good idea, and the back-end programming might be less complicated than I've supposed.
posted by amtho at 11:09 AM on January 13, 2015

If you have your sites set up as (| you should consider moving everything to the same domain (IMO).

If you have your sites set up as (| or (|, you should probably discuss a single-sign-on solution with someone, where signing into one site automatically signs you into the other. Can't offer more details, because something like that gets technical fast.

After that, move to a single login/registration page.

Your instinct to remove barriers is absolutely correct.
posted by Leon at 11:20 AM on January 13, 2015

Preface: We have a client that insists on externalizing an internal difference before login (e.g. "what type of user are you?"), and in our requirements gathering it turned out that their back end didn't actually do anything different based on the login type (and, in fact, the form field where the user selected it was completely ignored when the form was submitted). So then, backed by their internal tech people (who also had to support that form), we tried to make the case that it was ridiculous to continue to ask this question, and you know what? The client's marketing people insisted we replicate the same behavior, with the same form field that doesn't actually do anything. So, have fun trying to streamline anything if your stakeholders are anything like our client's stakeholders.

On topic: The current state of the art is to get rid of passwords and go with emailed tokens for access, as very well written by Ben Brown. I lost that particular battle with some of our clients based on the notion that some people don't actually have full-time access to their email (What? Who has access to your web site but not their email? Why are you spending time and money to support and enable those users, whoever they are?) but it at least informs what your approach could look like:
  1. When the user hits your web site, look for a cookie from a previous session. If they still have the cookie and the session is still active, welcome them back and refresh the session. Done.
  2. Replace your initial form with a single field for the user's email address. Don't ask them what kind of user or anything, just ask for the email address.
  3. When the user submits the form with their email address, you can look them up in your system(s) and figure out if you already know who they are, then send them to the password form (or, even better, email them a token so they can log right in without a password, as above).
  4. If the user's email address is known to your membership database but not your site, register the user seamlessly on the back end and be done with it (unless you need to gather information the membership DB doesn't have – bonus points if you submit those updates back to the membership DB).
  5. If the user's email address is unknown to you, then say something like "we don't have the address on file. Would you like to register or try again with another address?" Then you put those actions in place (a "try again" button and a form) and if the user registers, use the email address they've just given you.
If you want to get super-fancy, you can streamline the process and register the user based on their email address alone, send them a confirmation email right away, and entice them to complete their profile for more complete access. The biggest problem with that is you're potentially registering email addresses with typos, or addresses that don't actually belong to the user visiting the site, but you could have a process that sweeps the DB for never-verified registrations and purges them periodically. You can also include a "not you?" link in the confirmation email and allow users to expunge their own addresses if they have been registered by mistake. You'd be surprised how many people don't know their own email addresses.

Something like this is very streamlined, but it is likely to worry stakeholders who think "passwords" mean "security." That notion isn't really true, but it is very difficult to dispel. Also you shouldn't ever send any mail to an unconfirmed user except a confirmation email, so if you market to the whole DB you have to make sure you're excluding all the non-confirmed email addresses when you do that marketing.
posted by fedward at 1:25 PM on January 13, 2015

I lost that particular battle with some of our clients based on the notion that some people don't actually have full-time access to their email (What? Who has access to your web site but not their email?

A combination of poor cell coverage at a client's site and Google's two-factor auth. Or a no personal machines on site policy and KeePassX. Or Exchange deciding to take a break for the afternoon. Or forwarded emails. Basically, tokens-over-email works great until it doesn't.

Point 5 is information leakage, BTW, which may be fine, but is a bad thing in some circumstances.
posted by Leon at 2:15 PM on January 13, 2015

A combination of poor cell coverage at a client's site and Google's two-factor auth. Or a no personal machines on site policy and KeePassX. Or Exchange deciding to take a break for the afternoon. Or forwarded emails. Basically, tokens-over-email works great until it doesn't.

Excellent points. With our clients we know a lot about the targeted user base, and we could assume with a very high certainty that their users were coming from desktop browsers on work computers (and were thus in places where connectivity could be assumed not to be a problem at all) but I lost my argument anyway. But yes, if the targeted user base is mobile or otherwise limited and you can't expect tokens-over-email to work, then you'll need a secondary solution for the percentage of users who won't be well served by tokens-over-email.
posted by fedward at 3:12 PM on January 13, 2015

I'm hijacking someone else's ask here, but how did you plan to solve the fwd: problem?
posted by Leon at 5:14 PM on January 13, 2015

The token is single-use and time limited. It's not bulletproof but our system doesn't need stronger protection than that (no PII to speak of, no payment system, and a user base whose passwords don't tend to be strong OR unique, to the extent I feel safer not collecting those passwords from them, so our system can't be an attack vector for something of more value elsewhere). We can't prevent somebody from forwarding the token, but any given token is going to expire or be used and invalidated soon enough.

Which isn't to say we don't have shenanigans to protect against, but they almost always come down to legitimate users who spot a hole (real or perceived) and try to game the system. There are benefits the users can earn, but any actual reward gets scrutinized and fraud tends to get caught that way.
posted by fedward at 5:34 PM on January 13, 2015

« Older Easy open-source database building software?   |   Want to camp in Bryce/Zion area this summer. Need... Newer »
This thread is closed to new comments.