23 Rules for Designing Sign-Up & Sign-In Journeys

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.

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.

Today, we’ll 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’ll start with the simple sign-up and complicate affairs when we reach the sign-in in the middle of another action.

Rules for Sign-Up (or Registration)

1. Ask for only the basic information you need to create the account

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 — but don’t force it. You can get it later.

If your sign up form goes into more than 2 pages — you’re gonna have a huge drop off.

2. Mark what is required and group it together

Every required field should be cleared marked. It doesn’t 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.

Proper field grouping and field identification

From an HTML standpoint, clearly indicate the field in the input (through the autocomplete standard — see here), to help the browsers autofill the information.

3. Indicate password policy, but only stop the common ones

The rule should be to indicate the strength of the password, but if the password doesn’t fall into the common category, don’t stop the user from signing up. The rationale is simple — if they have to come up with a new password, they’ll most likely forget it and the next time they want to login, they’ll drop off.

4. Implement inline field validation & indicate errors onFocusOut

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 (“security”).

Using errors which are human-friendly is a good way to ensure that people don’t drop off.

Most inline form validation make the error of checking as I type. Here is the logic you should use:

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

This should stave off any ugliness with the validation.

5. Don’t block access to the account for unverified email

Unless it is a business requirement, do not stop users from accessing their account just because they haven’t clicked on the link you’ve sent. This is especially true for eCommerce — 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.

I’ve found that services that offer 3–5 days to verify the email, tend to get a lot more drop offs. It is better to ask for verification after the user has entered the portal and wants to take some action.

6. Don’t just indicate that an account exists with the email — give options

If a user enters an email that already exists in your database, don’t just tell the user that the email exists. That’s a dead-end. Provide the reason and actions, the user can take:

Give users an out for every error they get!

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’re faced with another form. Terrible experience!

If possible, try to do an inline verification of the email. It saves the user the trouble of entering the rest of the fields.

Security note: 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 — 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.

7. Social logins should be the norm!

I don’t know why there aren’t 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:

1. Coverage
   Don’t 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.
2. Prioritize
   If possible, prioritize the most popular sign-up method. Or push your most prefered method.
3. Merge
   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).
4. Remind
   If a user sign up using a SSO, and is trying to sign up again through email, indicate the SSO used. In rule 6, we saw the option of reset password or login — additionally, a message that says, “You logged in using Facebook” is a good way to remind the user.
5. Privacy
   It is best to indicate that you’ll use the SSO to only authorize the account and take only the required fields. And not post anything.

8. A tab key press should to go to the next field

As simple as it sounds, a tab sometimes doesn’t lead the user to the next field. That’s the expected behaviour. Test your form and see if some link or input assistance tag gets highlighted. Use tab-index attribute to help you out.

Here are some additional suggestions depending on your systems and requirements:

• Users email should be the user's identity to log in
  I’m looking at you, sites with usernames. Sure, I like the username “ThorButOaks69” today, but would I remember it, with its myriad combination of uppercase, lowercase and numbers? I remember my email, but not the username. Allow me to choose the username after I log in!
• After a successful sign up, send a welcome mail
  Here is what your welcome mail should contain — information about the site they’ve signed up to, what they can do with the account and what awaits them in the future. If possible, add an email verification link just to keep your CRM team happy.

. . .

Rules for Sign-In

9. Apply inline validation for the email field

So many sites do not apply email field validation (the standard regex one). Your system has the information that the email format is incorrect — indicate!

For a database lookup, it’s a security gamble — the same security note from Rule 6 of Sign up applies.

10. Reset password should carry the email into the new form

If your user has entered the email and you’ve told him that the combination is incorrect, she should not have to type the email again in the password reset field. If possible, make the transition quick and simple — hide the password field and change the button to say, “Reset your password” after the user has clicked on that option.

Smooth transition with email persisting

11. Offer password reset on the third try

If a user tries to enter the password more than once, offer to reset the password with a single click. Don’t make them click on another button.

12. Send a password reset link and not a system generated password

A system generated password adds a separate step in the reset password journey. The journey of reset password should be simple:

1. User opts for reset password
2. User gets a mail with the password reset link
3. User clicks on link
4. User enters their password, twice
5. User has access to the account

See how we jumped the login again with the password option? What are we trying to do with the login again step? Building muscle memory? Giving the autocomplete the opportunity to update the records? You have already verified the ownership of the account. You need not re-type the entire combination again!

This brings us to rule 13.

13. Allow the password managers to capture the users login credentials, if the user wants

Majority of the users are now on some password manager or the other. Only a few choose to still remember their email/password combination for the hundred-odd sites they use. The password managers have evolved to even sense a reset password to update their vaults.

14. On mobile apps, allow users to use their on-device authentication to login

If you have a mobile app, it would be ridiculous to force to use the complicated email/password or SSO logins. Most devices have exposed their authentication options (like fingerprint ID or faceID) to let apps use that as the authentication logic. Here is how the flow should go:

1. After a successful login, prompt the user to use their ondevice authentication for subsequent logins. Also provide the user the option to not show the message again.
2. If the user chooses to use the auth, go ahead and complete the flow on getting the auth.
3. At the next login form, provide the option of device auth as a SSO, or pop up a modal in their face with the authentication request.

15. SSO as a sign-in option

Again, should be a norm. Standard rules in Rule 7 should apply, with the following extensions:

1. If a user is trying to SSO with an email that doesn’t exist in the system, indicate the same and ask if the user wants to create an account with that email.
2. If a user is trying to SSO with an email that exists, authenticate and add the SSO to the account. On successful sign-in, inform the user of the same.
3. Try not to go more than 3 SSO options — any more will confuse the user. I do not remember if I used Facebook or Google or Twitter or whatever.
4. Mobile App SSOs — DO NOT open an in-app browser with the facebook/google page with sign-in option to authenticate. Most users have the app — use the Facebook/Google app to authenticate. I don’t want to enter a username/password combination just to save me from another email/password combination entry.

16. Two-step authentication should be a norm for sites that contain sensitive and payment information

This isn’t for sites that store tokens of credit cards, though it would be good if you enable it. This is for those sites that store money through credit/wallet balance. Again, not all your users have credit/wallet. Enforce the two-step authentication for those with something to lose. E.g. if I have just signed up and have no credit/wallet balance, there is no need for me to have a two-step right away. Contextualize your enforcement policy.

On two-step, best combinations are:

1. Email + Phone
2. Email + Email
3. Email + Push Notification

The fastest in my experience is the email + push. It always works. And keep it simple. Microsoft authenticator adds a really silly layer of choosing a particular number in a list of numbers. If I have access to both devices (the login device & the verification device), I just need to tap on the approve message. Don’t make me solve a sudoku puzzle!

17. Understand the user's cognitive load for deeper journeys and design ‘outs’ for errors

As the authentication journeys become complicated, fewer users will go down certain paths. Provide a way out if the user ends up in a loop. Give them the option to fall back to the old-faithful method of email/password.

18. Persistent logins should be the norm for non-sensitive sites

Unless your site holds sensitive information, allow persistent logins. This is especially true for eCommerce sites. Persistent logins allow the user to experience the site and the actions they’ve taken. You are a UX criminal if you auto-logout users after a certain time. Sessions may expire, but let the users actions (like items added to cart) remain. You can restrict access to personal information with a password prompt, outside of session expiry. Amazon does this beautifully by keeping you partially logged in and asking for authentication only when you need to access personal information.

If you have a mobile app and you log me out after a day, shame on you. Mobile apps need to have permanent logins (standard exceptions apply). You can be assured that no public devices are used to login to the app.

. . .

Rules for In-Journey Sign-Ins

Sometimes, you need to get the user to login to simplify the subsequent steps of the journey. We’ll focus on eCommerce journeys of checkout, check order status and abandoned cart. But, before that, if you have a mobile app, make sure that all links from emails/SMS are deep-linked. I don’t want to experience a silly browser journey on a mobile device that has an app with me logged-in.

19. Don’t force the user to log in when, without login, the user can complete the journey

During the checkout journey, the first step is usually the part where the user logs-in or provides an email. Visually prioritize the guest checkout option. The flow can be (for a non-logged in user with account):

1. Ask user for their email
2. Check if the email exists in the system, while taking the user to the next step. If the user has an account, prompt them to login, with the message saying that it would be simpler if they do so (check if the account has a shipping address and payment card associated).
   Note — we’re not showing the message on the same step. The user expectation is to move forward — meet it.
3. If the user chooses to login, open a modal with the form and SSO options. Since you already know if the user used SSO the last time, position the SSO option and the form. The order should be:

Order of options in an in-journey sign in modal

Note: There is no forgot password. User basically goes through with it or continues.

4. If the login attempts are unsuccessful, politely inform the user to not worry and that you’ll tie the transaction to their account (and do it!). They have to be brought back smoothly — make sure the user closes the modal on their own. If you close the modal, on behalf of the user, that’ll piss them off.

20.Upon login, if the user has items from a previous session, OVERWRITE IT!

Imagine if you were at the grocers, at the checkout line and when you provided your loyalty card, the cashier added 4 more items to your bill that you added to your basket the last time you were there? Wouldn’t you hate it?

Merging session is fine when the user logs in before jumping into the checkout journey. Then again, you shouldn’t just merge — identify them separately in the cart and ask if the user wants to add them to the new cart they have & give an option to ‘Save for later’. Your objective is to reduce the number of decisions the customer has to make before going into the checkout journey.

If you find that there are items in the users previous cart during the checkout flow, display them on the thank you page, with a simple message — “you had these items in your previous cart, do you want to buy them now?”. At that point, add those items to the new cart and take them straight to the review page — where their previous choices (like shipping address, payment type has been selected) and the basket total is shown. They should be able to select the items they want to buy and save for later. Simplify the journey.

21. Prompt account creation after the primary journey has been completed

If a user doesn’t have an account, it’s best to ask them to create a password for their account on the Order Confirmation/Thank you page. Don’t ask for repeated information. You already have all the information you need to create the account. Just the password is missing.

22. Order status links should not ask for logins

There should be two ways a user can check their order status:

1. Link in the email — Order status link should be sent with every order confirmation email and order update mail
2. Form on site that allows for email + order number combination

Additional information about the order can be kept behind a login prompt. Make sure that after login, the user goes the page that they were intending to go to…

23. Abandoned Carts links should not prompt for login

Abandoned cart flows are complicated — user accessing the link from a browser that they’re already logged-in, or session recreation using SSID in the URL — things get really complicated from a technical standpoint.

Simplify the Abandoned Cart journey by focusing on one product and get the user to transact that item. If they have items in the cart, show those as additional products they can add. Remember to contextualize your user journeys.

. . .

Most users have come to expect the above as a given. As product managers, we have constraints on the technological wiggle room we get to implement these, but I can assure you, implementing these changes will give your site/app a UX boost and increase your conversion. Try A/B on most of these rules and see how your users react.

Thank you for reading!

Originally posted on Rameez's Medium page.

Further reading:

• Easy API Hacks for Managing Large Design Teams in Marvel
• Wireframing your web application
• UX Design Best Practices for Improving SEO Rankings
• A Guide to Finding Free and Paid Participants for Usability Testing
• Support Sessions: This Month's Most Wanted