Designing a better password input field
Let’s face it, we all hate forms. That daunting list of inputs that separate you from your much awaited Biffy Clyro concert or your next summer holiday. After all, forms are in a way a battlefield, where Users and Marketers confront each other and where the former usually suffer the most losses. Now don’t get me wrong, I’m not saying that Marketers go against Users, on the contrary: bounce rate is an important metric for them so they actually want to keep the User from exiting the form as much as possibile — but that’s another story!
For this article, let’s keep the focus on Users and their (usually difficult) interaction with forms.
Unfortunately for us, not even the advent of social logins completely sorted out things: yes, they certainly were a big leap forward in reducing the hassle for the User, but:
- even today, not all websites implement them.
- the data that gets pulled down from social platforms isn’t always up to date or even correct
So, like it or not, one way or another you are going to find yourself face to face with a form to fill in. And that is why, as designers, we have the burden to make this experience the less upsetting as possible.
There are many aspects of form design that could be discussed, from error handling, input hints or event label positioning, but, as you might have guessed from the title of this post, I’m going to focus on just one particular field: the password.
🥶
Yep. The password field is probably, of all input fields, the most hated, feared and mistreated. It’s also where you tend to spend most of your time on a form, trying to figure out the correct combination of letters, numbers and (some) special characters. That’s because, although in 2022 the most used password in the world still seems to be 123456 (Source: NordPass), the majority of websites nowadays tend to enforce pretty demanding password creation restrictions (I would say thankfully).
So it shouldn’t come as a surprise if I tell you that
statistically the password field generates the most errors in a form.
Dealing with passwords is becoming a more and more cumbersome task for the User — especially during the creation process, and we as designers and developers should always keep this in mind when working on forms. We need to understand that the password field is a special type of input, in a certain way different from all the others, and it should be treated as such.
Let’s tackle the problem with a practical example, taken from my personal experience, of how a redesign of the input can drastically reduce the number of errors and increase the conversion rate.
The Problem
Unsurprisingly enough, the majority of errors on my company’s website were coming from the password fields of the forms that required the User to register, and therefore create a password. We’re talking about something like 33% of all errors on the website’s forms. That’s a lot for just one input.
With such big numbers, there was likely a problem with the design of the field, probably in terms of clarity in the data to be entered.
Let’s have a look at what the field looked like.
Pretty standard, right? An input field and a brief explanation of the restrictions enforced.
One could argue that actually reading the text gives the User (almost) all the information he needs to complete the task. But here’s the thing:
Users don’t read (everything).
As many researches from the Nielsen Norman Group point out, Users tend to scan the page, picking out individual words and sentences.
So if you look at it more closely, you can see at least 2 pitfalls in this design:
- the text is flat, with no highlighted words or characters that could help readability.
- The special characters list used in the description is not thorough, giving even the most focused User the possibility of error.
Now, if we think of Zig Zaglar’s words (although I’m pretty sure many others said something similar)
The first step in solving a problem is to recognize that it does exist.
we’re definitely off to a great start!
The Solution
Of course the first simple solution one could think of would be to just highlight some keywords in the description hoping the User would focus on these main rules. Let’s try and do that:
Password must be at least 8 characters long and contain at least one or more letters and numbers. Special characters like $, #, @, !, %, ^, &, *, (,)
Does that work?
It might increase the focus on the important parts of the sentence, but what about the special characters list? If we agree on the fact that the User doesn’t read everything, increasing the number of characters in the description certainly won’t help the cause.
So how do we fix this?
The two main problems a user faces when choosing a password are:
- finding a set of characters that he can actually remember (although according to statistics) while…
- …meeting the security restrictions
Now, for the first point there isn’t really much a designer or developer can do, and if we only focus on the creation process of the password it actually doesn’t even have any impact.
The second point, though, is actually much more interesting to investigate.
Is there a better way we can guide the user in the process of choosing the set of characters that will make up his password, without disrupting the current form layout too much?
Guess what? The answer is yes (duh)! And if you read my last article you can probably guess what I added to the design to achieve that.
Feedback.
If the user doesn’t read, then this means we’ll just find a way to guide him “interactively” step by step (uh baby — cit.) through the process, trying to limit his possibility of error to the minimum.
What I came up with was basically a two-step redesign:
- reduce the description part to 4 bullet points. This improves readability, removing unnecessary text while leaving the core information.
- use an “algorithm” that would check, on every key press, if the character(s) met the current password policy, giving continuous feedback to the User and therefore guiding him in the creation process.
This way the User has a clear understanding whether or not what he feeds the input meets the password policy rules and will most likely not submit the form before getting it right, hence reducing the number of errors.
And voilà!
Ok, design is cool, but it’s even cooler when numbers validate it:
Only a week after implementation of the new password field, the errors dropped 70% compared to the week before!
Conclusions
Once again we saw how feedback is a fundamental aspect of design, that we must take into account especially in those situations where we want to reduce friction between the User and the Interface. Of course it’s not the only aspect to consider, but it’s an important one.
Give the User feeback.
Last but not least, as I mentioned at the beginning of this article, my focus here was mainly on the redesign of the User/Input interaction and I did not talk about error handling, which is another fundamental and complex aspect of form design that is often overlooked. I might write something about this topic in the near future.
Now let me go book my winter holidays — using a form, of course!
p.s. A big thanks to Bianca Abbati for the numbers on the before/after performance comparison!
