Has anybody split tested one password field versus password & confirm on registrations?

Question

I'm just curious to see if this is something really worth testing, as it will require some coding to achieve.

Tested to achieve what? Whether people give up because they have to type their password twice? Whether they often mistype it twice? Whether they mistype it if they only get one chance and then have trouble getting in? All the above?!
Possible duplicate of "Is a 'repeat password' field necessary in a signup page" over at UX.
Do you mean to test that a single password field does not lead to more "forgotten passwords" (the inference being that the increase in forgetfulness is actually indicative of passwords that were typed incorrectly and not caught by the second password field)?

Matty · Answer 1 · 2011-06-16 10:59:15Z

I would be reluctant to do it. I assume you're trying to optimize your conversions.

Here's why:

You're breaking a well known UI pattern. It will cause confusion and unease to see something "new" like this.
If the field is a password field (i.e. masked characters) there will be a decent number of people that will type their password wrong, or will freak out as to whether they're typed their password correctly, and will spend more time carefully re-typing their password.
If the password field is a regular text box, you'll unnerve just about everyone. Pros will think your site is badly coded, and everyone else will worry that somehow someone will steal their password. The reason password fields are masked is to protect against others seeing a password on screen as it's being typed.

There are many other things you can do to optimize conversions, but in my opinion, this isn't a pattern to break.

I really like this answer; considering the investment in time it takes to code this, I would be fairly happy to follow your reasoning here- that its best not to change an established process for users.

greg · Answer 2 · 2012-04-24 08:55:06Z

What you ask is a cost problem in your UX evaluation.

As you know, cost = frequency (how many times a problem occurs) x gravity (the cost of the problem for you and the user).

You can have a first evaluation of the cost for the repeated field :

it always append
you can measure the evident cost of this field, ie the cost you can mesure without a test (abandon rate on this field, time spend on this field, etc.)

You can also evaluate cost for problems generated by its suppression :

you can measure how many people actually type a wrong password in the first field
you can measure the cost of the "lost password" process (how many people abandon there task when they ask for a new password, etc.)

If the costs seem very different, it is worth testing !

Coding the test is not really hard (with a simple js you can hide the confirmation field and copy first field value to this field).

Note : from my experience with this problem, I recommend to first optimize the "lost password" process.

2 Answers