Post image for Why require registration? Part 3

Why require registration? Part 3

by Mike B. Fisher on August 24, 2009

Quick summary: In parts 1 and 2 of this article we examined the ways in which registration affects usability and conversion. In this final part I’ll suggest some things to consider as you define your registration strategy.

Naturally there’s no single approach to registration that works best for every situation. However, there is one overriding concept that should guide your decisions.

The best approach is the one that enables the most direct path between the user’s arrival at your website and completion of their conversion/purchase. This is the essence of a positive user experience, and it’s what makes users happy, keeps them coming back and causes them to recommend your website or application to others.

In deciding how to accomplish this, it’s often helpful to:

Acknowledge competing goals; strive for consensus. Many companies struggle with competing goals from technical, marketing and product management interests.

•    Marketing teams often want to collect as much user information as possible.
•    Technical teams often want to make passwords and user IDs strong (not necessarily a bad thing but there are limits).
•    Product management is often more user-centric and concerned with the user experience – though not always.

For these groups to reach consensus it’s important they all understand the tradeoffs between registration and conversion.

As I mentioned in part 1 and part 2 of this article, less or no registration often facilitates more conversion and increased sales. That doesn’t mean you should simply forego a registered user database. But it does mean that a smart approach is to enable at least some functionality for unregistered users. Then encourage them to register. In the case of an e-commerce website this means offering a guest checkout path or minimal upfront registration.

Define boundaries between required and desired user information. Part of choosing the right strategy is to consider carefully what information you really must collect, understanding that the amount of personal information required is usually inversely proportional to users’ tendency to give it. If you require some type of upfront registration it’s usually most effective to require only information that’s technically necessary to process a transaction.  Then ask for other details later – or not at all. For example, requesting users’ birthdates is often justified as a way to create a “personal touch” by automating emailed birthday greetings. But this marketing device is common and fairly tired in 2009. There’s a good chance that customers already receive and ignore many similar communications. So it’s better to skip this request.

Determine when to ask for information. Once you’ve decided what to collect, give careful thought to the best time to collect it. In most cases this should be after the user has been exposed to information or products on your website and has some stake in wishing to complete a transaction.

This is a key point: value first, registration later is often the best model. Partial value (e.g. – The forum example from part 2) is often a good strategy for giving users an incentive to register.

Part 2 of this article also includes an example of integrating a registration option into a form that users must complete anyway to make a purchase. This type of “inline” approach works well for e-commerce websites.

Keep registration simple; use appropriate security. As I mentioned before technical teams sometimes get carried away with requirements for user IDs and passwords. A very common theme I’ve noticed in user testing is the desire to avoid creating “yet another complicated ID and password”. For applications like online banking this may be unavoidable for security reasons. But if your website doesn’t truly need strong authentication, it’s best to keep it simple.  For example, email address for a user name and a relatively simple password.

Define the value proposition; ensure it’s stated clearly. I covered this in part 1 and part 2 of the article, but to reiterate: requiring registration without stating the value proposition is counterproductive and can lead to abandonment. When asking users to create an account state exactly what they stand to gain, and be sure it’s a compelling proposition.

Define privacy and security terms; state them clearly. It’s also important to clearly state how personal details will be used – and not used. Few things kill users’ interest in a website or product faster than the expectation that their personal data may be unsafe or might be sold to unrelated third parties. “I don’t want this to add to my junk mail” is a statement I’ve heard more times in user testing than I care to count.

Consider incentives.  An effective strategy for building a database of registered users is to require minimal information upfront, then create incentives for users to provide more details later. For web services or information-based websites this could mean offering greater access to information, or discounts of some type. For e-commerce sites it could be discounts offered only to fully registered users or other such promotions.

Building a well-crafted and realistic registration process can have a big impact on the quality of your user database and your user experience. It can also improve your bottom line and conversion rates. It’s worth the trouble and the time to get this right.


Image based on a photo by scragz. Creative Commons licensed.

Share this article:
  • Facebook
  • del.icio.us
  • Digg
  • Google Bookmarks
  • MySpace
  • StumbleUpon
  • Slashdot
  • Technorati
  • email

Related posts:

  1. Why require registration? Part 1
  2. Why require registration? Part 2
  3. 5 shopping cart showstoppers

Leave a Comment

Previous post:

Next post: