It's not just about how long the signup form is, I believe it's simply the language "account" or anything that connotes joining something. The form can be three fields, and people still hate it.
The language "save my info for later", and versions of that, are much better. It flips it around in the user's mind: "oh, now they're not asking me to give something up, they're helping me out"
> The language "save my info for later", and versions of that, are much better.
While I understand what you're saying, I believe that would trip me up. I'm very much used to scanning for "Register", "Sign up", "Join" or "Create account".
I'm also unsure how much people really hate giving up their information. If anything, people are looking for places to hand over their information: Facebook, MySpace, LinkedIn, etc.
I think the problem is really that the more steps needed to convert your users, the more likely it is a part will give up before the end.
At Soup.io (tumblelogging/lifestreaming) we initially had content creation buttons right on the front page. We figured that the best first action for new users would be to actually post something, not filling out a sign-up form.
But we had exactly the problem you're describing: People are so used to scanning for "register"/"sign up" that some even assumed we were in invite-only beta.
We eventually changed that to a "Try it now -- no sign up required" button, which works better. The wording and UI is still tricky though: "Try it now", "trial account" etc. carry the connotation that it'll cost something later.
We've been meaning to A/B test a straightforward sign-up form for a while and measure effects on both conversion & retention, but unfortunately haven't gotten around to it yet.
I believe language and effort are the two main factors for a good signup form. Language means clarity, which makes doing the work easier. Minimizing the amount of effort that actually goes into filling out the form is really important too though.
I think if the user thinks they are suddenly being tied to a service may push them away.
The services that use the 'save my info for later' technique are most likely seen as easier because it is similar to how you use your local computer. You don't have an 'account' on your laptop. (Well, technically you do, but most people just believe that is just a password) You simply save something in your documents for later. By making the user believe that they aren't tied to anything, but just saving data for later, you can make them more likely to store their data on your servers.
The signup form could have only 2 fields, too: Username and Password. You don't need to demand an email address if your site can give some functionality that doesn't require interacting with others. You could make it so that a username is only "called out" once the email address is confirmed. So nobody can register all desirable names just to prevent others from having it (and of course have some throttling of registrations).
Stack Overflow's registration is awful because it only supports OpenID, a service that is spotty at best. I tried to ask a math question there and just couldnt get it to log me in.
That's your Open IDs provider's fault, not Stack Overflow's. Yeah, they may suffer a little but not enough to be responsible for a shoddy provider. But with how many providers are out there, it should be easy enough for you to use another one.
No, it's Stack Overflow's fault for using such a terrible authentication system. OpenID has pretty much proven itself to be a failure in user experience.
Facebook Connect has accomplished most of the goals of OpenID, anyway. They should use that instead.
This makes absolutely no sense to me. OpenID does not dictate anything about the user experience. The site that is using OpenID places a log in textbox, decorate as you wish, which takes you to your OpenId provider...which is the experience you chose, given by the provider that you liked....
Facebook connect took off because of the site itself, how many people use it, and people like those who constantly tell me that I should have Facebook logins for my sites and apps (and no, I shouldn't).
so...
- stop insulting openid unless you got a better idea that isn't proprietary
- or if you cant think of a better solution than openid, help us get it out there because it beats the old solutions, and we can at least start improving until we can think of something better (i can't think of anything better...i gave it a shot for an afternoon, its theory is sound, and its very flexible and solves the problem just great)
OpenID is a horrible user experience because it forces the user to set up an account externally to the site they want to visit. This is unintuitive, potentially insecure, and annoying.
OpenID is worse in every way to an internal authentication system. The only advantage is the mere dream of single sign-on, which has yet to come to fruition.
Do you have a google account? All you do is click on the google icon on the stackoverflow login page and put in your info. It's not that difficult. It's certainly easier than creating a new account.
Also the point of the article you are commenting on points out that stackoverflow doesn't even need registration to fully use the site. Your cookie will identify you forever (or until you erase your cookies).
"Really clever sites have even found a way to bypass the signup form altogether. They slowly ask for data along the visitor’s path of discovery, and pretty soon she’s a member of the site, without having to fill out a form!"
Be careful with this, it can backfire. Sometimes you come across a cool site that apparently doesn't require signup, then you spend some time creating something, and then at the last minute you get a message: "Ok, now to actually save your thing you just spent 10 minutes creating you JUST have to signup"...
It's so frustrating I usually just walk away in disgust. Don't pretend no signup is needed to use a feature if it's not true.
Luke Wroblewski's "Web Form Design" http://www.rosenfeldmedia.com/books/webforms/ makes this case well. He calls it "gradual engagement." It's also one of the best books on a web design topic I've ever read.
I'd love to see some numbers on "Lazy Registration". How many users does it save? How much effort goes into implementing it?
I've seen the idea before and I'm not really convinced. Sure, it sounds like a great idea, but let me offer some thoughts.
1. I have never been to 11 of the 12 sites mentioned in the article. Before I read this article, I knew exactly one site where lazy registration is actually practised: Stack Overflow. The idea has been floating around for some one or two years now. It hasn't really catched on. To me this suggests that many authors find it difficult to implement.
While difficulty in itself is not a problem, the time and effort invested in something needs to pay off, and it needs to pay off more than investing it into another feature. Opportunity costs apply here too.
2. How many potential users really care about registration? Does a "registration reddit-style" really put off that many people? In my experience, people will just pick their normal username and mash a laughably simple password into the appropriate box. There isn't much cognitive overhead there. This will, in my opinion, really only be a problem to people who have never registered an account before, anywhere.
Sure, you need to convince them that your product is useful. They won't explore further if they aren't convinced that it may provide some value to them. But it's probably a lot easier to put a tour on your website than to implement lazy registration.
3. If it does indeed give more users, do the extra users remain users for the same amount of time, or do they switch more easily to competitors? What happens to the users that you would've gotten with registration as well? Do they switch more easily? It seems to me that that's a very real possibility.
Currently, my intuition tells me to just use a registration form if you need it. In places where you don't need your users to be logged in, don't require them to be. Just let them do as much as possible without an account, but I wouldn't go for "unregistered accounts". That's too much effort for something of which you don't know how it will turn out.
Sometimes it's not the fact that you have to sign up but the way registration is done.
"people will just pick their normal username and mash a laughably simple password into the appropriate box"
It's not as easy as it sounds.
1) My username might be taken
2) Often, I have to go to my email and activate the account.
3) Entering and remembering a password is not as simple as it sounds. New York Times is a good example on how not to do it: http://twitter.com/vpdn/status/1620213111
4) Most of the time I don't see why I have to sign up.
The NYT is a site where registration is unnecessary[1]. Registration was harder to do for them than it is to not have registration at all.
I was talking about situations where you store data on a user and link more data to a user. Sure, you can do that using some kind of token in a cookie, but if you want to give your users a name at least some of the time, registration is easier. At that point "unregistered users" add more work.
Your other examples are more a problem with the way registration is implemented, than with registration per se.
[1] From a technical point of view. It probably makes business sense to them, although I'm unsure how.
It lets them publish a rate card which includes something to the effect of "46% of our pageviews come from US zip codes with median household incomes in excess of $80,000"
This is a helpful article, but I think there's a difference between easing someone towards a registration and not requiring a registration at all. Some of the companies listed seem to be the latter.
With 280slides.com you can create an entire presentation and export it to PowerPoint and a number of other formats without ever registering. Only if you want to save a document will it prompt you to login or register.
I really agree that this approach of gradually engaging the customer is the best way to go. The last thing a startup needs is to lose customers just because they can't use the product without going through a ridiculously long signup form.
It just makes sense: don't take the information until you need it. I found another article on A List Apart that may of interest to people who liked this article. http://www.alistapart.com/articles/signupforms
Very good approach and something that I'd like to work toward in my projects ...
From a technical standpoint, what's the best way to tackle this? Let's say you're using Rails or Django, you let a visitor create [some-widget] and then ask if they'd like to register ... do you store a reference to the new [some-widget] in a cookie until they do?
I would treat users that have not yet registered as closely as possible to normal users. So create a user object in the database for them and keep track of the last access date. You can either mark the account as temporary, or just store an empty password and rely on that to identify accounts that are not fully registered. You can purge inactive accounts after a certain number of days. If it's only keyed by session ID then there's no point to keep this data around past the session expiration date.
Then in a few places in your app you can check if you have the necessary information on file for the current user acocunt, and prompt the user to enter it if not (things like email address, a picture, real name, whatever it is you need). When they finally select a password they become a normal user of the site.
The language "save my info for later", and versions of that, are much better. It flips it around in the user's mind: "oh, now they're not asking me to give something up, they're helping me out"