Registration forms: Breaking down the barriers between your Web visitor and your product
May 6th 2009 | Jonathan Cogley
Registration forms: Breaking down the barriers between your Web visitor and your product
You’ve just found a really neat utility you’d like to download. So…you click ‘download’, and bam! You find yourself gazing at a mile-long ‘registration’ form coupled with email verification:
On one hand, you really want to try out this neat new utility.
On the other hand, you really don’t want to have to part with a load of personal information; fill in a dozen ‘required’ fields; dream up a user name, a display name, and a unique password; and type your email address twice.
What is the value of this additional information anyway? Is this company going to display your real name to anyone? Why do they need your address if you’re not mailing anything to you? Why do they need your phone number if they have no reason to call you? What are they going to use your ‘prefix’ for? This information is of no real use to them and it represents a series of barriers between you and the product you desire.
What information should be required in order to complete a simple download?
Every ‘required’ field on your form is one more barrier between your Web visitor and your product. Request only the information you need in order to perform the action for the user. While it’s tempting to use the opportunity to capture other useful information about your target market, online audiences have become more protective of their personal data and may decide that their privacy is worth more than your download.
Also reconsider the email validation – does it really matter to force a valid email address by sending an email to it and delaying the process? A customer who is genuinely interested is likely to give their real email address anyway.
Thycotic’s Web site registration form requires only an email address, full name, and password. We don’t verify your email address since that isn’t foolproof (most people have a free webmail junk account for such things). In the past we rejected email from free Web mail providers (Gmail, Yahoo, Hotmail, etc) but now we ask for a phone number instead. If a customer is genuinely interested in our product, then they actually appreciate a call to discuss their problem and receive an appropriate solution.
So take the time to consider your audience, then reduce barriers by requesting only information you genuinely need to successfully process the transaction.
Comments
5 Responses to “Registration forms: Breaking down the barriers between your Web visitor and your product”
Leave a Reply
The ironic part: I need an email address to make a comment on this blog.
Hi Jonathan, great post.
It is also a good idea to use checkboxes wherever possible, because it is easy to fill ot. Drawback is that many people click them randomly.
Another useful way to get more information is to get them progressively. First, you only ask for an e-mail address. You don’t have to validate it, if people don’t want to give you a mail address but they have to, they give you a fake, there ar many solutions online for anonimous temp mailboxes. If they are seriour about registration, they will give a valid address, especially if you promise not to send spam. Than, after a while, you can ask them in e-mail, if they liked the thing they registered for, and if the answer is yes, you can ask them to fill out a more detailed profile.
Make sure to not to bug the registrant frequently, maybe one in two weeks.
Interesting fact: on our website, we have a registration which is NOT compulsory, so you can just jump over it. Still, many people register with fake addresses…
I tend to just ask blog commenters for their SSN, credit card number, and the CVV2 for that card. I’m not going to pay for a Microsoft Surface myself, but i need it.
“Request only the information you need in order to perform the action for the user.”
– in this case, attaching your identity to comments.
Thanks everyone for pointing out the email address requirement on this blog.
I guess it was a default WordPress setting but a fair point so it has been removed – just shows that you need to think about this stuff *all* the time.