{"id":19291,"date":"2020-02-24T16:00:15","date_gmt":"2020-02-24T16:00:15","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=19291"},"modified":"2020-12-21T06:25:16","modified_gmt":"2020-12-21T06:25:16","slug":"rules-for-designing-sign-up-sign-in-journeys","status":"publish","type":"post","link":"https:\/\/shopjessicabuckley.com\/blog\/rules-for-designing-sign-up-sign-in-journeys\/","title":{"rendered":"23 Rules for Designing Sign-Up & Sign-In Journeys"},"content":{"rendered":"

Sign-up and sign in journeys have been there ever since the transactional eCommerce begin. But, after 20 years, we still tend to get that wrong. Most of the time, these are dictated by the platform of choice or the UX preference. Debates rage on, in the interweb, on whether a decision by an organization is correct, user friendly and complies with security practices.<\/p>\n

The sign-in\/sign up step is a big hurdle the user has to cross to enjoy the services you are offering. A bad SI\/SU journey leads to large drop-offs and poor experience.<\/p>\n

Today, we\u2019ll try to put all those to rest and create a set of simple rules that should be used in your sign up\/sign in journeys on all your products. We\u2019ll start with the simple sign-up and complicate affairs when we reach the sign-in in the middle of another action.<\/p>\n

Rules for Sign-Up (or Registration)<\/h2>\n

1. Ask for only the basic information you need to create the account<\/h3>\n

You only need a name, email and password to create an account. If you have a strong SMS marketing presence, a phone number would help \u2014 but don\u2019t force it. You can get it later.<\/p>\n

If your sign up form goes into more than 2 pages \u2014 you\u2019re gonna have a huge drop off.<\/p>\n

2. Mark what is required and group it together<\/h3>\n

Every required field should be cleared marked. It doesn\u2019t really help to use * to indicate required, but marking things as (optional) is better than to keep it unmarked. The order should be required items first, followed by optional items.<\/p>\n

\"\"\"Proper<\/a>Proper field grouping and field identification<\/p>\n

From an HTML standpoint, clearly indicate the field in the input (through the autocomplete standard \u2014 see here<\/a>), to help the browsers autofill the information.<\/p>\n

3. Indicate password policy, but only stop the common ones<\/h3>\n

The rule should be to indicate the strength of the password, but if the password doesn\u2019t fall into the common category, don\u2019t stop the user from signing up. The rationale is simple \u2014 if they have to come up with a new password, they\u2019ll most likely forget it and the next time they want to login, they\u2019ll drop off.<\/p>\n

4. Implement inline field validation & indicate errors onFocusOut<\/h3>\n

The most hated of input forms are those that wait for you to fill up all your details and then show the errors in a list at the top of the form, during which time, the password you entered is gone (\u201csecurity\u201d).<\/p>\n

\"\"\"\"<\/a><\/p>\n

Using errors which are human-friendly is a good way to ensure that people don\u2019t drop off.<\/p>\n

Most inline form validation make the error of checking as I type. Here is the logic you should use:<\/p>\n

    \n
  1. Wait for an onFocusOut on the field<\/li>\n
  2. Validate the field<\/li>\n
  3. If error, indicate error, but do not focus back on the field. (don\u2019t break the users flow, in filling up the form)<\/li>\n
  4. When the user focuses on the error field (and the field isn\u2019t empty), check at every onKeyUp. If the field is correct \u2014 turn the field green (but don\u2019t move the input box around with a message that shifts the input box).<\/li>\n<\/ol>\n

    This should stave off any ugliness with the validation.<\/p>\n

    5. Don\u2019t block access to the account for unverified email<\/h3>\n

    Unless it is a business requirement, do not stop users from accessing their account just because they haven\u2019t clicked on the link you\u2019ve sent. This is especially true for eCommerce \u2014 there is no need for an eCommerce site to verify the email address. For online products, you can always restrict user-facing actions till an email is verified.<\/p>\n

    I\u2019ve found that services that offer 3\u20135 days to verify the email, tend to get a lot more drop offs. It is better to ask for verification after<\/em> the user has entered the portal and wants to take some action.<\/p>\n

    6. Don\u2019t just indicate that an account exists with the email \u2014 give options<\/h3>\n

    If a user enters an email that already exists in your database, don\u2019t just tell the user that the email exists. That\u2019s a dead-end. Provide the reason and actions, the user can take:<\/p>\n

    \"\"\"Give<\/a>Give users an out for every error they get!<\/p>\n

    The sites that directly take the user to the login page are horrible! The user was expecting something like a thank you for signing up and they\u2019re faced with another form. Terrible experience!<\/p>\n

    If possible, try to do an inline verification of the email. It saves the user the trouble of entering the rest of the fields.<\/p>\n

    Security note<\/em>: I know that it is foolish to provide an API to the blackhatter to check which emails exist in your database, but if you are smart about it \u2014 using throttling or adding a device fingerprint layer to restrict the number of calls made, you are saving so many users the trouble of getting lost in the journey.<\/p>\n

    7. Social logins should be the norm!<\/h3>\n

    I don\u2019t know why there aren\u2019t more sites offering a single identity sign-on? For simple signups like eCommerce or product trials, the facebook\/twitter\/google sign ups are the easiest to do. Within these, however, there are sub-rules you should follow:<\/p>\n

      \n
    1. Coverage
      \n<\/strong>Don\u2019t put a sign up with Linkedin on a transactional site. If your region has a popular SSO authority, like WeChat, provide that as an option.<\/li>\n
    2. Prioritize
      \n<\/strong>If possible, prioritize the most popular sign-up method. Or push your most prefered method.<\/li>\n
    3. Merge
      \n<\/strong>If a user signed up using email or some other SSO and is trying to SSO with another, accept it and allow the user to login (as long as the emails match).<\/li>\n
    4. Remind
      \n<\/strong>If a user sign up using a SSO, and<\/strong> is trying to sign up again through email, indicate the SSO used. In rule 6, we saw the option of reset password or login \u2014 additionally, a message that says, \u201cYou logged in using Facebook\u201d is a good way to remind the user.<\/li>\n
    5. Privacy
      \n<\/strong>It is best to indicate that you\u2019ll use the SSO to only authorize the account and take only the required fields. And not post anything.<\/li>\n<\/ol>\n

      8. A tab key press should to go to the next field<\/h3>\n

      As simple as it sounds, a tab sometimes doesn\u2019t lead the user to the next field. That\u2019s the expected behaviour. Test your form and see if some link or input assistance tag gets highlighted. Use <\/a>tab-index<\/a> attribute to help you out.<\/p>\n

      Here are some additional suggestions depending on your systems and requirements:<\/p>\n