In my last post we looked at what a Blockers is and how they reduce the simplicity of a site. Now we’ll look at one of the most common in more detail, user registration.
When creating a site that will save user data it is often necessary to move the user through a registration process. This way you can setup authentication credentials and allow the user to save and secure information. Unfortunately either through marketing or development the registration process can sometime become bloated and inundated with unnecessary questions and information. The problem with this (as discussed in my previous post) is that each additional question becomes a blocker in itself that requires another investment of energy. The chances of losing a user increases with each question, so to combat this it’s important to put each field under screwtiny. Ask yourself the following when putting together a registration flow:
1. Is registration necessary to get started making use of the site?
As I discussed in my last post, do not force new users into registering to get a good feel for what your site has to offer. Allow a new user to search, browse, take a tour, etc. Offer them a taste of what being a registered user is like, and it will insure that their invested energy will be rewarded. I see large companies often requiring registration to access demos or videos of products on their sites, and obviously this is so that someone in sales can then hound the person later, but it’s generally a bad way to get someone interested in your product. The more freely available information the better.
2. Is this field necessary?
Once you’ve decided to go through with creating a registration flow how much do you really need to know up front? To get a user sufficiently authenticated in a system the littlest you should need is E-Mail and password. Anything other than that should have an immediate and perceivable value to the user. Fields that can fall under that category all depend on the purpose and focus of the site. For example, if your site has a strong user interaction component you’ll probably want to add a Username and a custom user icon. By contrast you should hardly ever have to capture a users phone number, mailing address, credit card, gender, birthdate, or other contacts to complete registration unless that data will be immediately used after the registration is complete.
3. How does filling this field help the user?
What will the field do in your system later, and how it will affect the users interaction with your site? For example uploading a custom user icon will help the user differentiate themselves from each other and creates a greater sense of community and interaction. Where as being required to enter your zip code may not immediately translate to a better user experience. Your registration flow should contain only those fields that will be of immediate usefulness.
4. How often will you use the data in this field?
Consider that if you will only use the information once or twice in that users history then perhaps it is superfluous. For example if you ask for birthdate merely to send the user a special offer once a year perhaps you could retune that to send the user a special offer after a period of inactivity to bring them back, or after certain purchasing activity. Sometimes marketing will demand that things like gender be a part of the registration so that profiling data can be extracted and trends determined.
5. Can you intuit this information another way?
When requiring a user to enter things like address what are the necessary fields for your needs or the users? Is it important to have their exact street address, or will a zip code suffice? Once you have the street address and zip code do you really need a user to enter a City and State, or even a phone number area code? Can you infer anything from the information your requiring be entered, or from any other future activity?
6. Is there a drawback to postponing the entry of this information?
Registration should be a quick in and quick out procedure. If your site is an online store for example and the registration is not being done as part of the ordering process then postpone the entry of things like delivery address and credit card information. Once registered your user will go straight to shopping, and once the checkout process has begun then ask for that information.
7. Does the format of this information have to be strict?
Once you’ve added a field into the registration flow you want to look into how you’re asking for this information. Phone numbers and addresses are notorious for this. For example a phone number doesn’t require anything apart from numbers. So forcing a format such as xxx-xxx-xxxx or (xxx) xxx-xxxx or separating each section into a separate field is just more infuriating to a user. Many browsers now do form autofilling, and Safari for instance uses the format that I specify in my International settings and my address book so numbers get filled in like xxx.xxx.xxxx and often registration process will balk at that. Addresses as well should be as freeform as possible, allowing users to enter addresses in whatever way they see fit and the code should be able to parse that at any time to determine things like City, State, Zip, etc. You’ll find that 10 extra minutes spent on the back end will save your users time and frustration.
Final things to consider
Confirming the user as human.
A little girl holds a stuffed bear.
Many sites use a scrambled text algorithm to ensure that whatever is going through the registration flow is in fact human. This is sadly just another blocker, and a tough one at that. At times the scrambled text is mistaken for something else, forcing a retry and increasing frustration levels. And determined parties will always be working on a better detection algorithm, and thus the cycle never ends. What’s gone untapped here are the myriad of other ways to test for humanity. Seeing as computers at the moment cannot understand concepts, it should be those that we can test against. For example, you see a photo of a little girl hugging a bear, and the challenge question is “This girl loves her ______”. Not only can the computer not recognize the girl, bear, or the concept of love as depicted there is no way for it to be able to fill in that field and continue.
Frogs of every color
Another example, you see a photo of differently colored frogs, some red, yellow and green, here the challenge question is “How many yellow ducks are pictured here?”. Obviously the answer would be zero. But a computer cannot tell a frog from a duck and even if it were looking for only yellow items it would see that there are some yellow entities in the photo and match those.
Untimely fate for this balloon?
Another example, you see a photo of a balloon and a hand with a pin about to pop the balloon, here the question is “How many balloons are about to be popped?”. Just as before the computer cannot recognize the shape as a balloon and even if it could, would not understand the concept that a hand and pin might end with that balloon popping. Now you’ll never keep spammers or hackers from registering accounts manually and then latching their software onto the profiles, but at least in this method the challenge response is less frustrating and complex to a user because it exercises a core part of our brain and requires little energy to solve.
Conclusion
User registration is an unfortunate necessity, but there is no reason it cannot be simple and rewarding to complete. Keep your required questions short and concise and let the user enter data in a quick and freeform a way as can be afforded. Leave the inquisition out of it and intuit information where possible.
