Should editing a password be 2 step process or all in one form?

Question

We have a web application whereby a user's profile screen uses a card-based layout. One of the cards allows users to update their password.

Our team is split on how the password card should be laid out. Here are the 2 concepts we came up with.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Version 1 - This is more of a 2 step process built into the card. The current password is verified to ensure you're you before you go on changing things. If the current password doesn't validate, you don't have to re-enter the new + confirm password fields.

Version 2 - Puts the 3 fields all into 1 step for the convenience factor. Could possibly produce cognitive load because you are putting old and new stuff in the same place. It is also 3 password fields in one card which could be confusing to some and makes this card visually taller than other cards near it.

Thoughts?

Is there a better way to do this? Is there 1 way that is better than the other, and why?

Answer 1

So your assumptions are that:

• The user needs to enter their current password again (even though the user is already logged in
• You need to confirm the password

As a rule I'd go with fewer steps: the user has already expressed a desire to change their password; making it a 2-step process is putting a barrier in their way. In the same vein, confirming the password is only done because you've hidden the entry values: if they have caps lock on accidentally, they won't see it, and for long passwords or on mobile devices, entering it accurately will be a source of frustration which you want to avoid.

I would suggest one page where you have ideally a single field for the new password. Have a link to hide the password, but by default, show what the user is typing. This will make it easier by avoiding the need for double entry, and making it clear what they are typing. Change the button to 'Change password' so it's clear what will happen.

Answer 2

The main benefit to the two-step process is user clarity about their data and its status. Think of it almost as a virtual barrier between the new and old passwords.

1. I entered my old password, which after this step I am done with.
2. Now I am entering my new password, which I will use from now on.

Versus

1. I entered my old password, but now I am entering my new password.

Does the two-step method hinder UX, or does the one-step method improve it? Only testing will tell. But for data as short as a password, one step is most likely ideal.

Answer 3

Most of the cases I have used have the old and new password fields together, like Version 2 above.

It is certainly what I would prefer, although of course your best course of action would be to ask your users, ideally by doing experiments to see which version yields the best results.

Answer 4

1. I would say if Instant verification of password is possible then go for 2nd option otherwise you have to go for 1st option in order to prevent user from typing the password again and again in case the current password is typed wrong.

2. An icon for unmasking password could be useful in both the cases.

3. This is more like a question to you and others who read this- how does 'Forgot password' works on this screen? Sometimes you may want to reset password when you don't remember the password and browser has already logged you in.

Answer 5

OK, I think you have 2 basic approaches, which are both correct, but could be enhanced with some slight changes. Particularly, I'd go with Option 2, because you have 1 action (password reset) and a subset of child actions for that main action. See, the common password actions are create / modify / delete. So, it would be different if (for example) you had to delete and then create a new one, these would be 2 different actions, hence 2 different steps. However, when you perform a modify action, you have this:

• sub-action 1: field to modify
• sub-action 2: modified field
• sub-action 3: modified field confirmation

which is something that you can logically group instead of adding friction with different dialogs.

Now, this being said, I'd suggest yet a 3rd option: as I can see from your wireframes, you're masking passwords, which is something I'd avoid. There's a lot of literature and discussion about why to unmask passwords, starting with Jakob Nielsen's article Stop Password Masking

Summary: Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures.

So, in these wireframes, I've added the password masking to your example, and show the 3rd option:

^{download bmml source – Wireframes created with Balsamiq Mockups}

The changes on these 3rd options are: unmasked password, 1 step only action, and changed copy on button. Please note that you could still mask passwords if you want, but you should add a "show password" checkbox to prevent issues.

Well, hope that helps!

More references:

Innovative Techniques To Simplify Sign-Ups and Log-Ins

Why Password Masking Can Hurt Your Sign Up Form

Mobile Design Details: Hide/Show Passwords