From when the transactional eCommerce begins, sign-in/up journeys have been formed. Therefore, The sign-in/sign-up step by accident becomes a big hurdle for the user to cross to enjoy the services you are offering. If Your SI/SU journey is bad this leads to large drop-offs and poor experience.
Hence, today, we’ll offer a set of simple rules that should be applied for your sign-up/sign-in journeys on all your products. Following us to make your sign-in/up more convenient.
Many websites do not use email field validation (the standard regex one). Your system has detected that the email format is incorrect — please indicate!
If your user has already provided the email and you have informed him that the combination is incorrect, she should not have to input it again in the password reset area. If at all feasible, make the changeover quick and easy by hiding the password field and changing the button to say “Reset your password” when the user clicks on that option. Smooth transition with email persisting.
If a user enters the password incorrectly more than once, offer to reset the password with a single click. Don't force them to click another button.
A system-generated password adds a new stage to the password reset process. The process of resetting a password should be straightforward:
• User chooses to reset their password;
• The user receives an email containing a password reset link.
• User clicks on the link;
• User inputs their password twice; and
• User gains access to their account.
See how we hopped back into the login with the password option? What are we attempting to accomplish with the login again step? Developing muscle memory? Giving the autocomplete feature the ability to update the records? You have already proven that you are the owner of the account. You do not need to type the complete combination again!
This brings us to rule 5:
if the user desires The vast majority of people are currently using one type of password manager or another. Only a few people opt to remember their email/password combination for the dozens of websites they visit. Password managers have progressed to the point where they can detect a reset password and update their vaults.
It would be absurd to force users to utilize cumbersome email/password or SSO logins if you have a mobile app. Most devices have made their authentication alternatives (such as fingerprint ID or faced) available to apps so that they can use them as the authentication logic. The following is how the flow should be:
Following a successful login, prompt the user to use their on-device authentication for further logins. Allow the user to opt-out of seeing the message again.
If the user chooses to utilize the authorized proceed with the flow on obtaining the auth.
Provide the option of device authorized as an SSO on the next login form, or pop up a popup in their face with the authentication request.
I'm not sure why there aren't more sites that allow a single identity sign-on. For simple signups such as eCommerce or product trials, Facebook/Twitter/google sign up are the most convenient. There are, however, some sub-rules you should follow within these:
Do not include a LinkedIn sign-up form on a transactional website. If your region has a popular SSO authority, like WeChat, make it available as an option.
Prioritize the most popular sign-up method if at all possible. Alternatively, use your preferred technique.
Accept it and allow the user to log in if a user signed up using email or another SSO and is attempting to SSO with another (as long as the emails match).
If a person signed up via SSO and is attempting to sign up again by email, identify the SSO utilized. We saw the choice to reset the password or login in rule 6; additionally, a message that reads, “You logged in using Facebook” is a fantastic approach to remind the user.
It is best to specify that you will only utilize the SSO to authorize the account and collect only the required fields. Also, don't publish anything.
Whether a user attempts to SSO using an email address that does not exist in the system, inform this and ask the user if they want to create an account with that email address. OR If a user attempts to SSO with an existing email address, authenticate and add the SSO to the account. Inform the user of the successful sign-in.
Avoid having more than three SSO alternatives - any more will confuse the user. I'm not sure if I used Facebook, Google, Twitter, or something else.
SSOs for mobile apps — TO AUTHENTIFY, DO NOT OPEN AN IN-APP BROWSER WITH THE FACEBOOK/GOOGLE PAGE WITH SIGN-IN OPTION. The app is available to the majority of users; use the Facebook/Google app to authenticate. I don't want to input a username/password combination merely to avoid having to enter another email/password combination.
This is not for sites that keep credit card tokens, though it would be beneficial if you enabled it. This is for websites that store money in the form of a credit/wallet balance. Again, not all of your users have a credit card or a wallet. For those who have something to lose, enforce two-factor authentication. For example, if I have just joined up and have no credit/wallet balance, there is no need for me to undergo a two-step verification process right away. Contextualize your enforcement policy.
On two-step, the best combinations are:
In my experience, the email + push is the quickest. It is always effective. And keep it as simple as possible. Microsoft authenticator adds a ridiculous tier of selecting a specific number from a selection of numbers. If I have access to both devices (the login and verification devices), all I have to do is touch on the approve message. Please don't make me do a sudoku puzzle!
See Also: Ways to Sign Out of Zoom & Sign Back In