Should this registration form include field for password now or after user passes review?












2















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?










share|improve this question





























    2















    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?










    share|improve this question



























      2












      2








      2








      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?










      share|improve this question
















      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 accounts






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 5 hours ago









      Mike M

      9,90111929




      9,90111929










      asked 13 hours ago









      mg1075mg1075

      855718




      855718






















          1 Answer
          1






          active

          oldest

          votes


















          4














          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).






          share|improve this answer


























          • 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
            12 hours ago











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          4














          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).






          share|improve this answer


























          • 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
            12 hours ago
















          4














          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).






          share|improve this answer


























          • 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
            12 hours ago














          4












          4








          4







          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).






          share|improve this answer















          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).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 12 hours ago

























          answered 12 hours ago









          Mike MMike M

          9,90111929




          9,90111929













          • 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
            12 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
            12 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
          12 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
          12 hours ago


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

          Alcedinidae

          RAC Tourist Trophy