How do I improve my website's registration and log-in process?

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.

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!

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.

If you have your sites set up as (www.domain.com|www.domainshop.com) you should consider moving everything to the same domain (IMO). If you have your sites set up as (www.domain.com|shop.domain.com) or (www.domain.com|www.domain.com/shop), 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.

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 http://notes.xoxco.com/post/27999787765/is-it-time-for-password-less-login. 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: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.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.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).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).If the user's email address is unknown to you, then say something like "we don't have the address [email protected] 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.

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.

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.

I'm hijacking someone else's ask here, but how did you plan to solve the fwd: problem?

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.