The user wants to immediately use you and try your website without conducting a formal registration beforehand
The light version of this pattern is the shopping cart of an e-commerce site, where the user can accumulate relevant products in a cart and then in turn register an account if he or she chooses to make a purchase.
In the heavier version of this pattern, an anonymous user account is immediately created for the user – full with an auto-generated database ID and a complimenting cookie with the account’s ID that will ensure that the user’s details and the information he or she has entered will be remembered upon the next visit. With appropriate intervals, inactive anonymous accounts are cleared from the database in order to not clutter it up.
As the user interacts with the system, data is accumulated to the account. While some data might not be shown to the user other kinds of data will. It is the latter kind of data that in turn will make the user register – the visible evidence that the user has invested energy into using the system. A smart way to gather such data is to expose holes of data that the user can populate.
Two such holes are the username and password: the two bits of information that will allow the user to log into his account from more than one computer.
For this pattern to work, you need to provide the users with an incentive to give you the registration data you are looking for. You need to provide a worthwhile service to your users for them to give you their data back in return. You want to use classic Carrot and stick motivation – and just as important: communicate the benefit you are providing. If the registration data you are looking for with the user is sensitive, you must be able to assure your users that their data will be safe and secure.
Voted negative, for the simple reason that I believe (so no prove what so ever here) users are more likely to just toy around without really getting involved if you don’t demand them to really decide to take part in what ever you have for them. I think having to registrate to be able to do something can be annoying, but at te same time makes you feel more involved, what makes you remember, what makes you come back. I guess…
I completely agree with Jasper. I wouldnt implement a ‘try-before-you-buy’ type of account in any of my web sites. Most of my sites do not require an extensive registration process anyway, so it would be only a minute or so of the users time and that 1 minute may turn away a few potential members, but at the same time it presents those who go through with the process a bit more involvement and that makes them likely to return.
There is a good and a bad from this type of registration.
Some people will feel cheated if they spent their time on something then prompted with a registration form to save their work. You may get a few more people to register because they have something to loose if they don’t.
On the other hand you will get more people to try out your web site because they can use it without having to create yet another account on another web site.
A positive vote from me! Some services are perfect for this, like the calendar in the example, or any of the to do apps. Allowing the user to begin playing with a new application is an excellent way to pull him/her into the service. Also, what better way to explain the positive points of a service than by letting the user see the features?
To some degree i understand the arguments against a Lazy Registration because you generate more “quality” users… One invested efford in registration = more interested and committed to service.
The PROBLEM with this thought is: your assuming a visitor fully understands the goal and benefits of your service instantly… – but does he really?
A user decides within 8 seconds if he is on the right page or not. (speaking he has found a site which solves his problem)
I would assume there are very few web-services which could claim a 8 “second-understanding”
Therefore i would always chose a free-trial or lazy-registration approach! Even give the users the main benefit without registration, then afterwards trading additional services for a registration.
I think the barrier to registration is very low if a user already had a benefit from my service or is committed through data he put in.
I agree this is a solid pattern and should be used if the information the user is being asked to interact with is not too involved. It depends on what this registration applies to. Tax forms? Obviously a full registration makes sense. A calendar application that simply lets me view friends’ birthdays? A light-weight solution makes sense.
A good rule of thumb is the registration should never take longer to fill out and authenticate than the actual function the user is trying to complete.
To me it seems clear that the user views the form fill on signup as a cost rather than a benefit. However, once they have used the application/site to produce something of value they go into “loss avoidance” mode. There is plenty of research out there showing that loss avoidance is a more powerful motivator than gain seeking. For sites that can use it, lazy registration would seem to be a very good business decision.
That said, even were it not, this is still a useful pattern for certain sites.
Like all design patterns, this works really well in the right context. How you implement will depend on the specifics of the problem that you are trying to solve, but this is a mature and proven solution.
Japser, getting users to “toy around” is the whole point. That’s what creates the interest and engagement required for commitment in the first place.