Should this registration form include field for password now or after user passes review?
The scenario I have may be a type of edge case because of the nature of the site I'm working on. This site (note: the site is not e-commerce, it is not about generating revenue; essentially, non-profit, quasi-government, and needs to make sure users are who they say they are) requires potential users to complete a number of fields in a registration form. After submitting the form, an admin reviews the submission, and performs a background check on the submitter using external resources. The background check can take a few days. If the submitter passes the background check and is accepted, then the admin activates the submitter's account.
My question is this: at what point in this process is the ideal time to ask the user to create a password? Should the user create a password at the time of their filling out the registration form, or should the user create a password after they have been accepted as a user?
registration password
asked 7 hours ago
mg1075mg1075
855718
add a comment |
The scenario I have may be a type of edge case because of the nature of the site I'm working on. This site (note: the site is not e-commerce, it is not about generating revenue; essentially, non-profit, quasi-government, and needs to make sure users are who they say they are) requires potential users to complete a number of fields in a registration form. After submitting the form, an admin reviews the submission, and performs a background check on the submitter using external resources. The background check can take a few days. If the submitter passes the background check and is accepted, then the admin activates the submitter's account.
My question is this: at what point in this process is the ideal time to ask the user to create a password? Should the user create a password at the time of their filling out the registration form, or should the user create a password after they have been accepted as a user?
registration password
asked 7 hours ago
mg1075mg1075
855718
add a comment |
The scenario I have may be a type of edge case because of the nature of the site I'm working on. This site (note: the site is not e-commerce, it is not about generating revenue; essentially, non-profit, quasi-government, and needs to make sure users are who they say they are) requires potential users to complete a number of fields in a registration form. After submitting the form, an admin reviews the submission, and performs a background check on the submitter using external resources. The background check can take a few days. If the submitter passes the background check and is accepted, then the admin activates the submitter's account.
My question is this: at what point in this process is the ideal time to ask the user to create a password? Should the user create a password at the time of their filling out the registration form, or should the user create a password after they have been accepted as a user?
registration password
asked 7 hours ago
mg1075mg1075
855718
The scenario I have may be a type of edge case because of the nature of the site I'm working on. This site (note: the site is not e-commerce, it is not about generating revenue; essentially, non-profit, quasi-government, and needs to make sure users are who they say they are) requires potential users to complete a number of fields in a registration form. After submitting the form, an admin reviews the submission, and performs a background check on the submitter using external resources. The background check can take a few days. If the submitter passes the background check and is accepted, then the admin activates the submitter's account.
My question is this: at what point in this process is the ideal time to ask the user to create a password? Should the user create a password at the time of their filling out the registration form, or should the user create a password after they have been accepted as a user?
registration password
registration password
asked 7 hours ago
mg1075mg1075
855718
asked 7 hours ago
mg1075mg1075
855718
edited 6 hours ago
mg1075
asked 7 hours ago
mg1075mg1075
855718
asked 7 hours ago
mg1075mg1075
855718
asked 7 hours ago
mg1075mg1075
855718
855718
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Make the user do as little work as possible, and align their expectations. It sounds like they are applying for access, not creating an account.
It sounds like an application form, not creating an account. This might lead them to think they have accomplished something on the path to acceptance, only to face possible rejection.
Do you have data that shows your rejection rate? If it's quite low, you can assume the overwhelming majority of users will be accepted.
A case against password creation (more work)
Creating a password requires a tax on the user. They have to:
- Think of a password
- Check to see if it conforms to your password requirements
- Potentially worry if it's powerful enough / not obvious ('password123'?)
- Write down or store the password somewhere once they have made it, or try to remember it (uggh!)
Making mistakes during this process can potentially waste the users time, and prevent your business from receiving the registrations they need.
It's a bottleneck, especially if your password UX is problematic.
After taking the time to do all this, they still may face a rejection.
A case for creating an account (persistent UI for status updates)
If you have specific status updates that users will want / need to view, or you want a place to give them a chance to edit their answers / information, then a private / password protected area can allow them to answer:
- Has my application been received?
- Are there any mistakes I can correct?
- Is there anything holding up my acceptance?
- When can I expect an answer on my status?
Some of these can be answered by email or other validation types (one time tokens from an email link).
answered 6 hours ago
Mike MMike M
9,89111929
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "102"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f124317%2fshould-this-registration-form-include-field-for-password-now-or-after-user-passe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Make the user do as little work as possible, and align their expectations. It sounds like they are applying for access, not creating an account.
It sounds like an application form, not creating an account. This might lead them to think they have accomplished something on the path to acceptance, only to face possible rejection.
Do you have data that shows your rejection rate? If it's quite low, you can assume the overwhelming majority of users will be accepted.
A case against password creation (more work)
Creating a password requires a tax on the user. They have to:
- Think of a password
- Check to see if it conforms to your password requirements
- Potentially worry if it's powerful enough / not obvious ('password123'?)
- Write down or store the password somewhere once they have made it, or try to remember it (uggh!)
Making mistakes during this process can potentially waste the users time, and prevent your business from receiving the registrations they need.
It's a bottleneck, especially if your password UX is problematic.
After taking the time to do all this, they still may face a rejection.
A case for creating an account (persistent UI for status updates)
If you have specific status updates that users will want / need to view, or you want a place to give them a chance to edit their answers / information, then a private / password protected area can allow them to answer:
- Has my application been received?
- Are there any mistakes I can correct?
- Is there anything holding up my acceptance?
- When can I expect an answer on my status?
Some of these can be answered by email or other validation types (one time tokens from an email link).
answered 6 hours ago
Mike MMike M
9,89111929
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
add a comment |
Make the user do as little work as possible, and align their expectations. It sounds like they are applying for access, not creating an account.
It sounds like an application form, not creating an account. This might lead them to think they have accomplished something on the path to acceptance, only to face possible rejection.
Do you have data that shows your rejection rate? If it's quite low, you can assume the overwhelming majority of users will be accepted.
A case against password creation (more work)
Creating a password requires a tax on the user. They have to:
- Think of a password
- Check to see if it conforms to your password requirements
- Potentially worry if it's powerful enough / not obvious ('password123'?)
- Write down or store the password somewhere once they have made it, or try to remember it (uggh!)
Making mistakes during this process can potentially waste the users time, and prevent your business from receiving the registrations they need.
It's a bottleneck, especially if your password UX is problematic.
After taking the time to do all this, they still may face a rejection.
A case for creating an account (persistent UI for status updates)
If you have specific status updates that users will want / need to view, or you want a place to give them a chance to edit their answers / information, then a private / password protected area can allow them to answer:
- Has my application been received?
- Are there any mistakes I can correct?
- Is there anything holding up my acceptance?
- When can I expect an answer on my status?
Some of these can be answered by email or other validation types (one time tokens from an email link).
answered 6 hours ago
Mike MMike M
9,89111929
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
add a comment |
Make the user do as little work as possible, and align their expectations. It sounds like they are applying for access, not creating an account.
It sounds like an application form, not creating an account. This might lead them to think they have accomplished something on the path to acceptance, only to face possible rejection.
Do you have data that shows your rejection rate? If it's quite low, you can assume the overwhelming majority of users will be accepted.
A case against password creation (more work)
Creating a password requires a tax on the user. They have to:
- Think of a password
- Check to see if it conforms to your password requirements
- Potentially worry if it's powerful enough / not obvious ('password123'?)
- Write down or store the password somewhere once they have made it, or try to remember it (uggh!)
Making mistakes during this process can potentially waste the users time, and prevent your business from receiving the registrations they need.
It's a bottleneck, especially if your password UX is problematic.
After taking the time to do all this, they still may face a rejection.
A case for creating an account (persistent UI for status updates)
If you have specific status updates that users will want / need to view, or you want a place to give them a chance to edit their answers / information, then a private / password protected area can allow them to answer:
- Has my application been received?
- Are there any mistakes I can correct?
- Is there anything holding up my acceptance?
- When can I expect an answer on my status?
Some of these can be answered by email or other validation types (one time tokens from an email link).
answered 6 hours ago
Mike MMike M
9,89111929
Make the user do as little work as possible, and align their expectations. It sounds like they are applying for access, not creating an account.
It sounds like an application form, not creating an account. This might lead them to think they have accomplished something on the path to acceptance, only to face possible rejection.
Do you have data that shows your rejection rate? If it's quite low, you can assume the overwhelming majority of users will be accepted.
A case against password creation (more work)
Creating a password requires a tax on the user. They have to:
- Think of a password
- Check to see if it conforms to your password requirements
- Potentially worry if it's powerful enough / not obvious ('password123'?)
- Write down or store the password somewhere once they have made it, or try to remember it (uggh!)
Making mistakes during this process can potentially waste the users time, and prevent your business from receiving the registrations they need.
It's a bottleneck, especially if your password UX is problematic.
After taking the time to do all this, they still may face a rejection.
A case for creating an account (persistent UI for status updates)
If you have specific status updates that users will want / need to view, or you want a place to give them a chance to edit their answers / information, then a private / password protected area can allow them to answer:
- Has my application been received?
- Are there any mistakes I can correct?
- Is there anything holding up my acceptance?
- When can I expect an answer on my status?
Some of these can be answered by email or other validation types (one time tokens from an email link).
answered 6 hours ago
Mike MMike M
9,89111929
edited 6 hours ago
answered 6 hours ago
Mike MMike M
9,89111929
answered 6 hours ago
Mike MMike M
9,89111929
answered 6 hours ago
Mike MMike M
9,89111929
9,89111929
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
add a comment |
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
I completely agree with your point about "Write down or store the password somewhere once they have made it, or try to remember it (uggh!)". My manager seems to be insistent that this is a non-issue, though.
– mg1075
6 hours ago
add a comment |
Thanks for contributing an answer to User Experience Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f124317%2fshould-this-registration-form-include-field-for-password-now-or-after-user-passe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
