Registration Form | Password now vs password later

Option 1: Password Now

Description

• Store owners need to choose a password at the end of their registration process.
• There will be a text explaining to them, that they cannot use the password yet, that we are currently working on setting up a login functionality.
• There will be no way of using or resetting the password until then.
• Once we have implemented the log-in functionality, we will send them an email to inform them that they can now log-in to change their data.

Pros

• New users won't have to get an automated password (?) to, later on, have to change it for a new password. They will be notified at the end of the registration form that we are currently working on giving them access to their data. Once there is a login access implemented, they will be notified via e-mail that they can now log in. Old users will have to be notified in order to register their account - and this will have to be connected to their existing data in the background.

(?) Comment by Claudia: Maybe this was a misunderstanding. In Option 2, they will not get an automated password, especially not right after signing up. Please see the description below. We will have to notify old users anyway, whatever we do.

Cons

• It will block us.
  • It requires planning and discussions about how we do this exactly (including coordination between frontend and backend). All this will take time, especially with a reduced number of developers and the remote situation.
  • We will have to decide how complex the passwords should be.
  • We will need to involve UX/UI again to include feedback to the user, why they are not allowed to use 'Hasi123' as a password.
  • Saving passwords also requires higher quality assurance than the simple fire-and-forget registration form would need, meaning that we would have to test it extensively, which takes even more time.
• It will confuse users, even if we try to explain. Why do they have to think of a new password now (it's effort, they might need to write it down somewhere or store it in a password safe), if they cannot even use it or reset it. It will be very different from any other webpage where they create an account and can login right away.
• Users might have forgotten their password by the time we are ready with the sign-in functionality.
• It will make it very obvious to the users that they cannot easily change the data they just entered, which might be frustrating.
• Users don't always read all the text when going through the signup process. They will remember inputting login credentials, but not understand why they can't use them.
• We will have to email customers, either way, to let them know that the store editor is ready. We will have to send a separate email to customers who created stores before the login form was created to let them know how to log in.
• All around, not a great user experience if the user is less tech-savvy and doesn't understand why they created a login but cannot use it.

Option 2: Password Later

Description

• When filling in their registration form, store owners will only give us their email address, along with all other contact and profile data. They will not be asked to provide a password.
• Once we are ready with the sign-in functionality, they will receive an email with a link: They will be directed to a page where they can choose their password for the first time. This is the same page we would use for password resets (so no additional effort).

Pros

• The new design will go live earlier, no dependencies, no blockers. We can get feedback on the design right away, we can start to improve on it while backend is still working on the login functionality.
• No additional effort for UX/UI. We just leave the page out where we ask for the password (we can still explain, that we are planning so set up a login functionality later).
• No additional effort for frontend. We need that whole registration form anyway, we will keep it.
• No additional effort to send out emails with a request to choose a password, once we are ready with the login functionality. We anyway have have to notify about the new functionality. Also, we have a bunch of stores already which will need to choose a new password and we will have to implement a reset functionality anyway.
• No additional effort for users. They only choose their password once.
• No confusion for users. Now it's just a registration form. Later, once we are ready, they pick a password and can use it right away to make changes.
• This makes more sense from a shop owner's perspective. The shop owner has thousands of things to do and remember right now, chances are, we will have to provide support to help them remember their password/credentials in the future after we email them to tell them the editor is ready to use.

Cons

• Users cannot choose a password immediately, they will choose one later once they can actually use it. Not sure if that's a Con, I as a user would prefer it this way.