Is it a good practice to prompt user to fill field 'Confirm password' on registration screen in mobile application?
Could you tell pros/cons?
Thanks!
-
Original Poster is talking about Confirm Password. – divy3993 Aug 2 '16 at 10:06
Add a comment
|
There are many arguments against using confirm password, well summarised here: http://uxmovement.com/forms/why-the-confirm-password-field-must-die/
Pros:
- It's familiar, which can give the illusion of security.
- It's good at preventing input errors.
Cons:
- It's slower.
- Lowers conversion rate.
The general consensus these days is that a single field works best, with a toggle to unmask the password. Since you're designing specifically for mobile you could leave the password unmasked by default, but some users will find this disconcerting.
As long as your reset password process is painless, one field is the way to go.
-
I have read that study and take issue with some of it. They used Google Analytics and deduced that it was the confirm password which was causing abandonment. The problem with Google Analytics is it won't tell you why someone did something - it can only tell you that someone did something. There could be all sorts of reasons why some one left but they would never know why. – SteveD Aug 2 '16 at 10:20
I assuming you are masking whatever the user types in the password fields?
If a human being cannot see what they type, because the field is masked, there is actually a high risk they will make a typo, especially on a mobile device where the virtual keyboard is tiny and is not physically tactile like a mechanical computer keyboard.
So the only reason why you will use a second password field is because the chance of someone making the same identical typo twice is actual quite low.
As you asked for pros and cons:
Single password field
- Pros - only one password field in the form
- Cons - high risk user will make a typo, which will prevent them from ever logging in when they enter what they think is the correct password (which it wont be because it was unknowingly typed incorrectly). In this situation the user would be forced to go through the Forgot Password flow, which will annoy and frustrate them.
Two password fields
- Pros - Dramatically reduces chances of identical typos being typed, and thus user is always able to successfully login in the future (with no annoyance or frustration)
- Cons - none (1 extra field is not going to hurt any one, especially if it helps you avoid being forced though the Reset password flow)
I have seen the arguments stating a confirm password field is slower, but this is far too simplistic conclusion - its only one extra field.
However, the actual solution to this problem is to fix the root problem - you are masking the password! You now see many solutions allowing you to display what you type.
-
Am I right that if user can check password by button ( see unmasked password ), two password fields case will have no pros? – gaussblurinc Aug 2 '16 at 10:20
-
Its not a black and white situation. In both cases there are challenges, e.g., if only one password field with show/mask toggle - you risk other people seeing your password, and if you are creating the password for the very first time you are taking a risk to do this in a very public place. So I typically force users to enter password twice in the initial set-up because I don't want to force them through the reset flows, given the frustration this occurs. However for logging in once its setup - I offer a show password feature so that they can choose to use if they want to. – SteveD Aug 2 '16 at 10:30
I have worked with a few Apps and websites, and tested a couple of things, including the registration flow.
Requiring users to confirm their passwords (or not), hasn't typically been dramatically affecting the registration event. Or too much drop off.
BUT, people are getting lazier and lazier and so, need simple ways to do things... so, I foresee this affecting the registration user experience more and more. This is why more and more websites are now incorporating the Show/Hide password toggle.
