Long Sign-Up Forms Considered Harmful

Considered useless, maybe, would be a better title.

Of all the various trends that have accompanied the wide range of the “web 2.0″ school of applications, the one feature that sticks out, that I really like, is the minimalist sign-up form. Whether they call it signing up, registering, creating an account, the trend has been:

  • To ask you for less
  • To make it quicker
  • To give you options (login with OpenID, Twitter, Gmail, Yahoo ID, etc.)
  • To make any further information optional

It used to be that any time you “signed up” on a new website, it seemed that you had to go through a long form, including your address (what?), telephone number (you’re calling me?), username, first name, last name, email address, password (twice), favorite color, inseam measurements, and so forth. And for awhile, because that was the norm, I think people online simply accepted that.

No more, thank God. New web applications, if they don’t accept OpenID or an existing ID from a different service, generally just ask for an email address and a password. There’s no particular reason you can’t use an email address as a User ID for many applications, so why make it another field? If you want to have the option (for privacy reasons… not a bad idea), you can always allow people to set a username after signing up. Make it simple.

I can’t speak for anyone else, but as a result, my tolerance for old school, long, multiple page, sign up forms has dipped below zero. If I visit a new service and click “sign up”, chances are I’m just considering checking it out. If click “next”, and see Yet More Fields to fill out before I’m able to get into the application/web site… I’m liable to just close that tab and forget it.

2 Responses to “Long Sign-Up Forms Considered Harmful”


  1. 1 mrben

    Bear in mind that your username is often displayed publically, and you probably don't want your email displayed that way….

  2. 2 philcrissman

    Right; I agree. In cases where a username is automatically public, then using the email address would be a faux pas.

    One simple option would be to simply truncate the email before the '@' and use that as the user id. While it might be relatively easy to guess the address using the major domains used these days (it's still relatively few people who use their own personal domain as their main email channel), it would at least be mildly obfuscated.

    But even if one includes a username field, that would (hopefully) be only 3 fields: username, email, password. If you send an email to the new user right away (before you encrypt is and save it to the db) advising them of what password they signed up with, then you don't need a second field for the password; if they really did fat-finger it or forget what they entered, they could just check their email.

    There are always exceptions… sometimes you need a little more information from a new user. But in most cases, I think you can leave that until _after_ he/she has signed up; just direct them to their profile page to fill in additional information, if they want to. If it so happens that some information is critical to the app (maybe it simply _must_ know my zip/postal code, for some reason), then you can advise the user that feature X won't work until they've added this information. Etc.

    I think it's pragmatic for the web application, as well; I'd venture to guess that the simpler the sign up, the less attrition you'll see at that point of the process. To me, that makes sense; make it so insanely simple to sign up that I just can't resist.

Comments are currently closed.



Fork me on GitHub