“We used to suck at it” is a series of posts explaining the UX design decisions behind the BIME redesign.
For the first post in the series, I wanted to begin with something simple, nearly universal and I guess (a bit) controversial: a password input. Let’s first list the hard facts.
A password has to be as secure as possible and include uppercase, lowercase and numeric characters to strengthen the password against brute force attack. It is common to enforce this by validating the password only if it follow those rules.
Problem 1) you often do not know those rules before validation so you have to guess them on the first try.
Problem 2) you don’t see what you type because it is a “*************” hidden field. So you might either mistype the intended password, or not understand why it is not validating against the rule.
Everybody associates password definition with pain. Here is our take to try to improve the situation:
First, we display the password rule loud and clear below the password input. No guessing.
Second, as the user types the password they get immediate feedback by highlighting the rules to try to bring the user’s attention to them.
Third, we allow the user to display the password in full text if they want. This prevents typos. It prevents frustration. The decision to display the password is entirely their decision (this is key) and asks for an extra action. It is a typical balance between security and UX. This pattern is now present in OSX and windows8 so multi-billion dollar companies' security experts have put their “GO” on this.
And that is about it. Passwords, like all security concerns, are critical - but also a very common UX pain point. One of the key goals of the recent BIME redesign was to maximize user joy. It is also worth mentioning that we go a bit further than that in terms of password management by pushing password-less options such as Google, Salesforce, LinkedIn and SAML authentication.