This is the current process we will look at and try to improve upon:
...
The series of screenshots is here:
...
This screen offers users a choice to Sign or Register.
Plan:
Remove We should remove this screen, it has too limited (or negative) value.
...
Screen 2: User identification
...
Visual / identity / background
Squint your eyes, you will see two things popping out on this screen:
...
Toned down colors = appropriate for UI.
“Footer”
The “footer” is not needed here. The less CTAs we have on this focused page, the better. It is like a landing page in this aspect.
At this registration stage, it is not the time to send users off to look at e.g. documentation. They have clicked on a ‘register’ button, let’s keep them in that state of mind.
...
Social proof
…or in other words - showing logos of customers.
A well-known and valid tactic.
“Adding logos on a landing page can increase conversions by 400%.”
It says “can” and in my experience adding logos almost always does give a considerable lift.
Adding customer logos in a very correct way means contacting a company’s legal department, asking them for approval, and spending a good amount of time and effort before getting answers.
Most SaaS companies go for a pragmatic approach = put the logos on the page, and if the customer asks to do so, immediately remove the concerned logo.
The “Update” request
We should find a way to not have to show this message all together, throughout the system.
But, for registration it makes not much sense. By far and large, these are new users and first thing we ask them is to manually update …
...
“Social” login
Well-researched. A summary maybe from the CXL, a leading CRO agency:
86% of users report being bothered by having to create new accounts on websites
77% of users believe social login is a good registration solution
92% of users will leave a site instead of resetting or recovering login info
88% of users admit to entering incomplete or incorrect data on registration forms
...
Data from Okta highlights the two that matter for us: Google and Microsoft.
...
Email sign-up: The fields and the # of fields
A lot of research has been done on this aspect re conversion rates, and the research can be confusing/contradictory. Bottom line is that we should run our own experiments later on when we have bandwidth. There is the eternal trade-off between lead quality and quantity.
“The takeaway here is you should use as few form fields as you can on your landing pages and be especially cautious with more sophisticated text areas and select boxes.”
“for each additional field you add, your conversion rate may drop anywhere from eight to 50 percent.”
Proposal:
Keep the amount of fields as-is but build up the form. It is a common and somewhat modern approach.
Test later more with other scenarios eg where we start with the full form.
The full form:
Building it up (mentally splitting it):
The form expands after information has been entered.
The benefit of this approach is a step-by-step validation of the entered information.
Eg valid email address:
domain validity
work-related email
…
...
Passwords
No password confirmation field
Password confirmation is an extra field. And it is one that usually does not pre-fill.
But if it is not there - the user could type the password wrong and would need to use the Forgot Password routine (if they come back).
But with the wide-spread use of pre-filled passwords and password tools the risk for misspelling is greatly reduced. Also, 40-60% of registered users will never come back anyways…
Meta has been using single fields for years and years already. It is safe to assume that they tested it:
...
From Zuko, a form optimization tool:
We achieved a 56.3% increase in form conversions by removing “Confirm Password” while not negatively affecting the password reset rate.
Some UX folks are rather adamant about it: https://uxmovement.com/forms/why-the-confirm-password-field-must-die/
Show the rules
These are our rules which we show:
Minimum 8 characters
Contains 1 lowercase,
Contains 1 uppercase,
Contains 1 numeric
Contains 1 special character
As the user progresses on the password, we show progress on the rules as well:
...
Leveraging
https://codepen.io/rauldronca/pen/OwKMGX
https://stackblitz.com/edit/maz-calculator-nza3p9?embed=1&file=src/components/PasswordScore.vue
Unmasking
It was already there - and we keep it, it is good practice.
Terms and privacy policy
Adding this terminology to the sign-in form is widely accepted - and removes a solid amount of friction.
...
Who needs the terms and conditions, as well as the privacy policy?
The legal teams of our customers. And they are usually not the users, so they would not go through the registration process. Making their life easy → we add these to our footer, which is where they expect it to be.
This is solid friction we are adding here:
...
Enterprise accounts
We should foresee the addition of some features that would help us to create an “Enterprise” pricing tier:
SSO/SAML
MFA
Documented Security Policy highlighting protection against
Bots
IP throttling
Brute force
Redesign:
Redesign:
There are still improvements that could be made, but this should give us a good lift already:
Try it out (3 variations of the flow in there) https://www.figma.com/proto/gp02jWyuxr0HdOm9ECFbwm/UC-212-%7C-Sign-up-and--in-%7C-Onboarding?page-id=2%3A14371&type=design&node-id=6-27945&viewport=298%2C65%2C0.29&scaling=min-zoom&starting-point-node-id=15%3A28689
...