Redesigning Registration

The first thing a prospective user approaches on your shiny new web app, the registration form.

The importance of this process is often overlooked or not sufficiently analyzed for shortcomings or elements which can be improved. If conversion is everything with your app, this is the first and (hopefully) only barrier separating them from the experience and utility you have to offer. Time to get it right.

I’ve always been particularly drawn to the UX involved with forms on the web. They are by far generally the most tedious and taxing commonalities for the typical user (and the rest of us too), and request the most of the poor user who probably doesn’t want to type anything more than URLs.

Fields. What’s required?

The registration process – it’s like the bow on an icebreaker, if it fails the rest is completely screwed.

Take a moment to think about what data your application actually requires from each user. More often than not, that’s email, username, and password. That gives you enough information to authenticate and identify a user within your application, as well as of course communicate with them via email. Every field beyond that is one additional hurdle for the user, or perhaps more accurately, your application’s ability to get a user on board.

Let’s take for example a ‘name’ field. Not username, name. That’s right, this is the internet, you have to ask if you want a real name. First of all, is a real name necessary; could you request it post-registration (more on that in a bit)? Is that field one or two (first and last names)? Will you need to use only the first name at any point in time, or only the last name? It’s not safe to split at the first space to display first/last names if they entered it in one field, so the need for two fields is created. This initial consideration for what information you need to collect decides the format and structure of your entire registration flow, arguably the most important part to any web application’s initial success.

The minimalist approach

Occasionally, I come across websites that only ask for your email address and handle the rest for you. That is, they send you your password via the provided email address. What does this constitute as effective for? It’s the sites like Instapaper (which actually doesn’t require a password at all if you don’t feel the need to protect your account or specifically want to make it public) that don’t have a basis in community. Personal applications that are meant for pure utility and often don’t have high security requirements.

Is this approach effective? Yes, as long as it’s suited to the application. More importantly, is it possible to bring some of the ideas behind this approach to other, more in-depth registration processes? It’s the non-personal information in a registration form’s requirements that can sometimes be considered troublesome to fill out, like the password field (more on that later). Another example would be selecting a vanity URL. While this could potentially be presented post-registration, could it not be included in your registration form and filled in automatically based on your username or first/last name fields? When you ‘tab out’ of the last name field, could an element appear with the proposed, already confirmed as available via AJAX, vanity URL that consists of the first name field and last name field, no spaces? Rdio does this successfully on their registration form.

Bending standards

Beyond the fields included in a form for (or in the subsequent stages of) registration are more set-in standards. I’ve been noticing more and more questioning of ‘password masking’, the default behaviour of password fields in-browser. That is, the way password inputs replace each character you type with a bullet point or asterisk. This has been the accepted and standard behaviour for as long as I can remember, and the only variance I can recall is the slightly changed behaviour on many touchscreen devices, namely the iPhone/iPad.

With a slightly less accurate/predictable keyboard, typing blind is a bit too much to throw at users – so on these devices, the last character you type remains visible for about a second, or until you type the next character. This behaviour is fantastic. It could be argued that it degrades the security that the masking is designed to provide in the first place, but if you have someone looking that closely at what you’re doing to follow the ‘visible’ tail-character, they might as well be watching the keys you press. The obvious ‘next step’, passible or not, is un-masking completely. This is where I would draw the line on mobile devices, as there are far too many situations where an onlooker with nothing better to look at could very easily read your password. On desktop platforms, however, I think it’s a different story.

What I’m getting at here is that silly confirm password field that accompanies quite literally every single password input I’ve ever seen. I understand why this exists. It is impossible to know 100% what you’ve typed in as your password. One typo and you’ve got to go through a reset password process before you’re even fully registered. However, the problem is created in the first place by the masked password standard. In this respect, an unmasked password fields solves the problem – double-check once you’ve typed it, even if you were watching your fingers on the keyboard or your cat playing with the printer (aww), and you’re set.

What about those curious onlookers, though, near your desktop computer? Let’s be honest, how often do you sign up for a new service with somebody looking at your monitor? Admittedly, however, it is a potential problem, so here comes one more question. Where do we give the user a choice? Is it a browser setting? and OS setting? Functionality you build into your applications’ registration form? Well, I was unsure about this myself, but then I remembered what I’m writing about here - registration forms. None of this subject is applicable to login forms, as there is no ‘bloat’ input to fix with log in forms – get it wrong, simply try one more time and get in. That answers the question – this is very much a per-web app feature. It can be safely assumed, optional or not, by neither the OS nor the browser that password inputs should not be masked.

I’m thinking about building up some alternative password field behaviours in the near future, watch this space.

Post-registration information

oh hai, reminder

In the case of an application that requires a fair amount of information upfront, in order to enable all of the application’s most important functionality, some choose to first get you registered – that is, username/email/password – and then prompt you to complete your profile before you can begon using it. Sometimes it’s optional but continues to bug you about it (“Your profile is 15% complete, only 4 steps remaining!“), and other times it’s a forced second registration step. In the case of Rdio, the first step is essentially just an email confirmation step on its own – and serves to get your email address in the system just in case you flake when the next registration step arrives (in which case you’ll get email reminders to finish up).

This approach has pros and cons. Again, the necessity of the second-stage information collection must be questioned. While it may seem more likely that a user will just go ahead and finish up the registration when they’ve already created an account and just need to provide a bit more information, it’s also borderline sneaky and some users won’t appreciate that. If it’s not *totally* mandatory, that usually means you’ll have a ‘progress’ meter until the end of time letting you know what you haven’t yet done to let the service know who you are or let the world know about your presence on it. Typically, there’s no out-out for any given step that you decidedly do not want to complete (see left, on Klout), although in my opinion that would solve the problem. You’re encouraging the completion/actions, but not forever criticizing your users for failing to comply. If the missing information makes missing functionality evident, the requirement will appear necessary, instead of demanded.

Security

The security of a user’s account is governed almost entirely by the password they choose. Sure, there are best practices to evade hacks and account cracking centered around the UI (such as displaying only ‘login incorrect’ instead of ‘wrong password’, which gives away an existing username), but really on an individual account level, it’s about the password. Developers know this, and password requirements have become commonplace. In theory, password requirements/restrictions make perfect sense – if the user wants to use abc123 as their password, simply don’t let it happen. However, it’s also a deterrent unless it’s done very gracefully.

I’ve come across password fields that take password security into account, but absolutely ignore UX. Being informed after submitting the form that my password doesn’t contain the necessary characters? Having a maximum character limit (baffles me each and every time, seems somewhat totally counterproductive)? If requirements are going to be imposed on one of the most basic fields in registration, one of two things need to happen.

1. Make the password for them. This could be done by leaning-up the registration form and sending the password to the user via email along with a confirmation link (two birds with one stone). Alternatively, you could get crafty with the single password field in registration (read upwards for a discussion on password masking) and essentially provide a password generator rather than input. Something I’d particularly like to see in something of a hybrid is a password generator with an optional checkbox that reads ‘create my own password’ and otherwise implies that a less complex password will put their account at higher risk.
2. Make it as painless as possible. Be upfront with password requirements. Make the lower character limit six, not eight – unless perhaps you store credit card information within user accounts. Provide examples. Take from the above point and provide a randomly generated one and give them a ‘fill’ or ‘use’ button to use it.  Finally, let them know as soon as they focus out of the field either way whether it’s good. These parameters should negate the need for a ‘password strength meter,’ I have doubts about how useful they are to anyone in the first place.

The registration process, the most forward-facing and fragile part of your application’s user experience, deserves more attention. It’s like the bow on an icebreaker, if it fails the rest is completely screwed.