Imagine this, you are signing-up for a product and you get asked the same old questions when creating an account(Name, email address etc) with the exception of a password.
After you sign-up, an email containing and auto-generated password will be sent to you. You will be able to change the password inside the account section once logged in.
How would you feel about it? What are the negative aspects of it?
The negative aspect is that you've inadvertently complicated the process.
If I signed up and used my preferred secure password then I'm in and done.
However with the auto gen password approach I have to get the email, click the link, go back to the email, copy the password "G34-zaopwf792hj" (cause I'm not going to attempt to re-type it) paste it in, then hunt down the profile link, then the change password option, then re-paste the old password, then type my actually desired password, save and go back to the actual app.
...and if I'm trying to do this on a phone?... Arghhh!
If you can figure out a way to do this and reduce the number of steps (e.g. Friction) and maintain security I think its worth investigating.
There are multiple reasons why:
It worsens rather than improves users communication. Users confronting a signup form without a password field may wonder if their account is secure, wonder why there is no password, etc. By removing the field you are failing to communicate to the user that the account will be accessed via password....in fact you are implying the opposite (i.e. there's no password)
It creates more UX friction. You may think that removing the password field helps reduce friction for the user to access the site. But think through the scenarios:
It violates convention. Users are accustomed to signing up to sites by entering a password. By not presenting a password field, you are violating common practice.
I think the key question is, do you need to verify the email address or not?
I would only send an email for verification purposes or just a welcome message.
If you really want to eliminate fields to fill in, you could start with name, emailadress and password. Then ask their other details in a later stage.
You could make the process kind of "asynchronous". I mean, let the user sign in and make him/her log in without the need to change the password immediately. In this way you don't "break the cycle".
Regarding security, you could allow only a restricted set of privileges until the user clicks a link sent by email or changes the password.
This question could be reworded: Should users be prevented from choosing their own password on initial sign up? Best case scenario, you end up with a streamlined form with a higher conversion rate (people like simple forms) and users that all have strong passwords. This relies on that the users are going to stick with your generated password, which must be both memorable and secure.
This is not as easy as it sounds. Common word passwords are subject to dictionary/rainbow attacks, and if your password algorithm ever gets out then there isn't a whole lot you can do to protect the majority of your users' data. The only ones who would be safe would be those who changed their password manually after signup -- a process you just made more complicated. And if anyone else forgets their password, which is likely given that they did not create it, they'll have to go through yet another password generation process to access their account.
On the other hand, you could just let them pick their own password. You won't be sending anything in plain text, and any frustration the user has with forgetting will be placed on themselves and not your service. You will still be able to make a clean signup form; as the login form by necessity requires a password it won't look any different. My current project has a login form with email and password fields followed by a login and a register button. One screen for all users. Less fuss, less friction.
I will have to wait for email. It breaks the flow, go to mail box, check for the mail. Sometimes wait for email. Anxiety!
I think this depends on what you're signing up for, and whether the user is likely to return and need a password to log-in.
For example, I once worked on a sign up process which sent the user an automated password in this way because whilst the website needed to collect the user's credentials for later correspondence, the user could, but rarely chose to return to the website.
However, the majority of the time I think asking the user to create a password on the spot would be a better experience - as most users use the same password for everything anyway and are therefore typing this with muscle memory, and very little cognitive effort.
TL;DR: Creating/typing passwords require very little cognitive effort, but any friction should be avoided when possible.
That practice is confusing and frustrating for users not familliar with your system. Additionally i could imagine many people not knowing intuitively that they should change their password to their preferred one after logging in and they might forget about that email you sent them and register again out of confusion once they wanted to use your service again.
Email would require sending the password in the clear, which is a bad practice (especially if your site stores any personal or financial/payment information).
This is why many websites have stopped offering to email you a forgotten password, now offering to email you a link to reset your password instead. (Another reason for this is that they don't even store your password as plain text, so they can't send it to you anyway).
While receiving your password via email may initially feel like a better user experience in some scenarios, poor site security may mean the positive UX is short lived.
