Disclosing Password Constraints in the UI

On the Web, there are few things more annoying than having to guess password requirements, the interaction usually goes like this. You get to a site or you install an app, it asks you to create an account to access content you need. You are annoyed. That’s the subject of a different video. But at this point, you’re too committed and you decide to create an account. You are prompted with an email and a password field and there is no information about a password format.

You happily enter a normal word thinking that this time you got away without having to switch phone keyboards and type weird characters and boom, there’s an error. The password must contain between six and eight characters, two capital letters, three digits and one special character. Really, why couldn’t inside or out disclose those constraints from the beginning? It’s unlikely that by themselves users will come up with a password that matches exactly those requirements. Progressive disclosure has its place in a variety of interface design context, but this is not one of them. Some might think that disclosing password requirements is unnecessary and puts an extra burden on the users since they have to read them. That last bit is certainly true, but unfortunately revealing them is a necessary evil.

Password requirements are not standard enough. Some sites are happy with four characters, while others require at least six. Some insist on capital letters, others don’t. And so so forth. So users don’t know what any particular app or website will require. And reading those requirements will definitely take less time and effort than thinking about a password, only to find out it’s wrong and you have to come up with a different one. So next time when you’re designing a registration form, do me and your users a favor. Tell us what our password should look like before we create one.

Leave a comment

Your email address will not be published. Required fields are marked *