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.
January 15th 2008 | Josh Frankel
I did it again last week. I slept through my alarm after accidentally setting the tiny “am” to “pm” on my phone alarm. This will come as no surprise to anyone who has used their phone as an alarm clock.
But why is this situation so familiar?
A user always has goals in mind when they use software. A designer on the other hand, wants to display features. So when I set my alarm, tired and bleary eyed, I’m faced with a lot of display information at every option. My ability to set the alarm for the next morning is complicated by having to deal with every one of these options. I imagine that when this feature was at concept stage the idea was to make it easy to set up multiple, reoccurring alarms.
Software anticipates what a user wants to do, but it is not easily usable unless the ‘hows’ and ‘whys’ of its use are answered as well. What I really want to do is simply set my alarm to the time of my choice and ignore other alarm options. I could also use some better visual cues to help me distinguish between, AM and PM.
I’ve mocked up a more effective UI, taking into account the compass point navigation used on the phone’s directional pad. Does anyone else have a better idea for a UI redesign? Or, maybe you have a different everyday electronic device with poor usability experience. I am really interested to hear about it.
I’m trying this Twitter thing, so follow me and leave your comment, on Twitter: http://twitter.com/JoshuaFrankel