Case study: Zillow registration page
Have a look at the Zillow registration page below. It may look a bit verbose and busy. It may seem like we can take away the password requirements. Should it be there even before the user types it?
Many sites won’t show the password requirements until the user finishes typing it. If we have a strict password policy that fails on the first attempt, the user would most probably say out loud,
Why didn’t you inform that before I think and type? I would have thought of some other password!
So, I don’t really see a problem in the way it is. And the way they have grayed out the password requirements helps the layout to look less cluttered.
But the problem arose when I entered the first letter in the password field.
It immediately screamed at me with four errors with red bold icons which indicated I’m wrong.
Woah. Wait. I understand your requirements. I’m getting there! — I thought.
It also said, Poor 😑 at me. But at least it was a smooth gray.
I wanted to refactor the above form to be polite. Below are the changes I did.
1. Password requirements appear after onFocus().
As discussed, this is not a critical issue to fix. But I decided to hide them until the user focusses the password field. That makes the form less cluttered at first glance.
A less cluttered form tells the user that it only has less work to be done.
2. Be careful about red.
The password requirements being fulfilled are not errors when the user is typing. So, I kept the requirements as faint gray and slowly marked them with green ticks as they get satisfied.
Instead of going Wrong → Correct, here we choose to make the requirements go from To_Be_Satisfied → Satisfied. And we also enable the Create Account button when everything is okay to be sent to the API.
We also have the eye button in case if the user wants to verify.
3. Icon Inconsistency
The icons for correct and wrong are not consistent in Zillow. One is bold and solid while the other one is thin and regular.
This form works like a strict teacher who won’t appreciate easily but strongly criticizes when you get things wrong.
4. Border Radius Inconsistency
Refer to the first picture. The border-radius for the input field, submit button, and OAuth providers are all different from each other.
5. Redundancy In Communication
How does the user read this?
‘Or connect with, Continue with Apple’
It is not a correct sentence to have.
This problem can be tricky to solve. But as the above design tells us that not much thought is put into it. So, let's put some thoughts.
Variant #1: Simple. But…
This is the design we have in the refactored screenshots above. I feel this lacks clarity. What if the users do not recognize the icons?
Variant #2: Simple With Enhanced Law Of Locality
Bringing the ‘Continue with’ inside the button makes it a bit more clear about what the button will do. Also, we have introduced ‘Apple’. Now users may guess the other icons are sign-in providers too.
Variant #3: Clear but may be hard to get the layout to look good.
Form follows function. But sometimes a clean form takes away distractions and facilitates the users to access the functions in zen mode.
Variant 4: What do you think?
Notes:
- The password strength indicator is good to have. I ignored it to reduce the complexity of this project.
- Sign-in providers: I’ve no reason to get them above the email and password fields. It should be based on what flow will the majority of users take or it could be just a business decision.
- I’m doing a youtube series that refactors sites using React, Storybook, tailwind/CSS frameworks. I will link here once the videos get published.
Edits:
Eye Button: The squint test tells that the eye button in the password field gets too much attention. I have grayed it out a bit.
I believe the above changes will make the user registration experience much smoother.
Thank you for reading. Criticisms and comments are much appreciated.
