Password Inputs: The Little Eye That Causes Big UX Problem
Tags: webdev, ui, ux
Published: 2022-12-12 12:33:59

If you were like me, you'd have experienced the frustration when using password inputs with an eye indicating whether your password would be displayed or hidden. I find such inputs annoying because the messages the variations of the eye attempt to convey are confusing.

## Table of Contents

- [The UX Problem of Password Inputs](#the-ux-problem-of-password-inputs)
- [A Better Design](#a-better-design)
- [(Perhaps) The Best Design](#-perhaps--the-best-design)
- [Is No Option a Better Option?](#is-no-option-a-better-option-)
- [Takeaways](#takeaways)

## The UX Problem of Password Inputs

To illustrate the problem, imagine you're about to input your passwords to the following two sign-in forms with another person standing beside watching (_so you don't want your passwords displayed_).


![Twitter password input](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ru2iem9qin3sx6dw0nip.png)

<figcaption>Twitter password input</figcaption>

![Adobe password input](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a04yzkmkb286ciu2a4uq.png)

<figcaption>Adobe password input</figcaption>
<br>
The **eye** is open in Twitter input while it is closed in Adobe input, but it turns out that both of them indicate your passwords would be _hidden_!<br>

![Twitter password hidden vs. displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qgobsda9iz9znjhhcgkr.png)

<figcaption>Twitter password hidden vs. displayed</figcaption>

![Adobe password hidden vs. displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0oe172jwmqxezrak6rmh.png)

<figcaption>Adobe password hidden vs. displayed</figcaption>
<br>
We can find the inconsistency in many other web services too.<br>

![Wordpress password hidden vs. displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kvv8fwz7mfveo7t2pgno.png)

<figcaption>Wordpress password hidden vs. displayed</figcaption>

![Xserver password hidden vs. displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ccezulubf8f72kmtkte4.png)

<figcaption>Xserver password hidden vs. displayed</figcaption>
<br>
Are you not confused? At least I am and I think the designers who made those UIs were too. The problem is **the MEANING of the variations of the element is not agreed nor established**. An opened eye, for example, can mean _the password is visible_ or _the password can be displayed_, depending on how you interpret it.

But how do users know which message the UI is trying to deliver? The answer is we don't. So we have to stop for a second, try to figure out ourselves and probably just take a guess that is wrong 50% of the time.

## A Better Design

The sign-in form of Netflix delivers better user experience by replacing the confusing eye with explicit text which is more straightforward.


![Netflix password hidden vs. displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ty5b3snpjzb5lrqawzgy.png)

<figcaption>Netflix password hidden vs. displayed</figcaption>
<br>
For non-native English speaker users, however, there still can be a caveat: _SHOW_ might be mistakingly interpreted as _being displayed_ while _HIDE_ as _being hidden_.

## (Perhaps) The Best Design

Google made the user flow of its sign-in experience a smooth one by using something too mundane for some designers to give a sh*t: a checkbox. 

![Google password hidden vs. displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/77x8lvlg5hpdlrmep94h.png)

<figcaption>Google password hidden vs. displayed</figcaption><br>
There are at least 4 advantages of this design over the others introduced above:  

1. Users are more familiar with checkboxes than the eye element and thus are likely to feel more comfortable using a checkbox.
2. The message the element convey is so self-explanatory and unambiguous that it's almost impossible to interpret otherwise.
3. The checked/unchecked status and the checking/unchecking action of the checkbox convey both **what status (hidden or displayed) the password is in AND what action (hide or display the password) users can perform in one message**. This reduces the mental efforts required on users even further.
4. Developers would be happier as handling a checkbox with two states is easier than keeping two eye svgs and conditionally rendering one based on the displayed/hidden state.

## Is No Option a Better Option?

You may have noticed that many services, like Github and AWS shown below, opted out of the option to show the password. 


![Github and AWS have no option to show password](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5xfus4rgz77o7hkjfzqw.png)

It's hard to say if no option is a better option but personally, I think allowing users reasonable options generally contributes to better user experience.

## Takeaways

The sign-in form design by Google is a good example of **simple and basic design delivering excellent user experience**. Am I suggesting we give up all the fancy design? Certainly not. **The key to creating good UIs is to empathize with your users**. And it usually only takes a casual user test to see what contributes to good user experience. If you happen to find out a fancy-looking design makes your users the happiest, then let it be.

But the little eye beside your password is obviously a big no-no. Get rid of it and find an alternative.