Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

Adding customer logos in a very correct way means contacting a company’s legal department, asking them for approval, and spend spending a good amount of time and effort before getting answers.

...

...

Data from Okta highlights the two that matter for us: Google and Microsoft.

...

  • 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:

...

Image Added

Building it up (mentally splitting it):

...

  • 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

...