3

We are going to give our users the ability to set a password on their apps to protect their personal data such as their transactions, wallet balance and etc. We decided to ask them to set a password, after their initial sign-up process that includes giving OTP (one-time password) after they entered their mobile number.

The problem is we are afraid of reducing conversion rate out of pushing users to set a password in their sign-up process. Is this the right time to ask the user to set up this password?

4
  • Please describe what have you done? and What's your ideas at first. so that we can give your some advices.
    – Frank AK
    Apr 29, 2019 at 11:08
  • @FrankAK thanks for your consideration, we are going to give our users the ability to set a password on their apps so that they could protect their personal data such as their transactions, wallet balance and etc. We decided to ask them to set a password, after their initial sign-up process that includes giving OTP after they entered their mobile number. The problem is we are afraid of reducing conversion rate out of pushing users to set a password in their sign-up process.
    – Farsaei
    Apr 29, 2019 at 11:31
  • Since you guys try to build a wallet, and it's important to set the password, because it's only way to recover the account if user lost their phone or device. But you probably don't need to require user set their password at very beginning, Once the user try to withdraw or transfer their money and you can require they do that.
    – Frank AK
    Apr 29, 2019 at 12:00
  • @MasoodFarsaei you need to edit that info into your question to provide a better context and background. Otherwise you won't get any decent feedback or more likely your question will be closed for low quality. Apr 30, 2019 at 13:33

4 Answers 4

1

This answer depends on multiple things.

  • Your user expectation
  • Your user disponibility
  • What information you really need to ask for user
  • Where, when and for what reason your user is using your app
  • How much they trust in your app
  • How willing your user is to complete the form

Indifferent of how many fields do you have, you should make life easier for your user. See some actions:

  • Use the right type of field. For example: type=number, type=passwors...
  • Autofill fields with most common data
  • Ensure that tab or next on the keyboard will work and put the focus on the correct next field
  • Autofill fields based on previous information. For example, use the postcode to autofill address.

You can see some UX best practice for forms on this video: https://www.youtube.com/watch?v=WdGaxESSmeM

And you can see 5 case studies of forms on this article: https://www.ventureharbour.com/how-form-length-impacts-conversion-rates/

And you can see a trusted website talking about it: https://neilpatel.com/blog/the-definitive-guide-to-lead-generation-form-optimization/

Maybe I can help more if you tell me more about your user, the journey, why they need to fill the form and about your app.

1

You cant really know answer for this types of questions without doing testing, as it is heavily dependent on your context.
Some sort of general conclusion we could make (that must not be 100% true) is: If you don't have password field, it will be quicker to finish, and therefore more successful.

Also, creating password during registration seems like a standard thing in design, so if you make good validation and fluent form, there is no big mistake in having it there.

1

You don't need to get them to set a password at all. The OTL is the password.

As Jared Spool writes here, passwords are not usable and not secure

https://www.uie.com/jared-live/#fix-ux-of-security

Use OTL as default login path

https://twitter.com/jmspool/status/857954119067336704

and

https://articles.uie.com/account_design_mistakes/

these resources should really help you

0

If you allow easy password reset through the email account or phone number, you might as well use the email account or phone as a login method.

So you just send the user a login link, and this can be reused (a device identifier or such can increase security and require resending a new token when changing to a new device or such). Every once in a while, the user gets a new token and the old one becomes invalid after a grace period (to allow for holidays w/ no phone access and such).

What you can also do is create an easy to remember but hard to crack password for the user. If birthday is needed, use that in a scrambled way with an extra word. 1987-05-12 turns into 87MasoodAppMayflower or such. The user basically only needs to remember the word flower, while if you create a million options to write each date, an attacker needs to know the birthday and still try up to a million times - which, with a time delay between unsuccessful logins and some other measures, can be made to take a few thousand years. If an attacker doesn't know which variations are possible, they may even need a few billion guesses. I added the app (or company) name so that the user knows where the password belongs. You can do the same with the phone number or use parts of both, though that's less secure.

I suggest allowing the user to change that password any time, and just have the option easy to find and often to see in the navigation of the app.

If it's typical for your kind of wallet to have very little in it at the beginning, you can leave a password checkmark unticked, so the user won't be bothered with logins at the beginning. Same with making the password hidden behind the usual dots only after the user decides to do that. With reminders popping up more often when the user starts to have more than a little in the wallet.

Picture login and such could also be done - though I'd suggest to use this more for verification.

2
  • passwords are so 2010. Jared Spool advocates your advice. Use the device as security, not the notion of a password.
    – colmcq
    May 1, 2019 at 9:34
  • I see it as a safe way to get the data to a new device, mostly. May 1, 2019 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.