Sins of Webdev #1: Authentication

The idea to write this post came to me after having watched Tiffany Conroy’s talk “Beautiful authentication: Tear down the barbed wire” from Refresh 2017 conference. She works for SoundCloud and tells a few stories about mistakes they made with design of authentication-related components. And the truth is, they are not simply bugs. I felt that they just followed the paved road of status quo and we all do the same in our apps. We just don’t pay enough attention to things like users signing in, rather eagerly concentrating on “the meat” of our apps.

I repeat some points after Tiffany and I add some from my experience. Note that I’m no UX expert, although I am interested in UX-related topics since some time already. On the other hand I try not to stray from developer’s perspective – keeping development viability, security etc. in mind (which, in my opinion, many UX preachers just omit). So, here my list of things we don’t to well enough when it comes to authentication-related stuff.

“Sign in or sign up”

This is a small thing, but can help a lot. Frequently you can see two buttons, typically in upper-right corner of a web page. One of them is “Sign in”, the other is “Sign up”. Now the thing is: people confuse them. It’s not that natural for non-natives to distinguish between those two. As a result, people are clicking the wrong one and get frustrated. When they are frustrated, they leave.

Instead, you can replace “Sign in” with “Log in” and/or “Sign up” with “Register”. Aparently this makes a difference (at least it did for SoundCloud).

Even more radical solution: present a single email input field to fill in. After that, if email exists in database, ask for a password. Otherwise show a registration form.

Wrong password is an error

I would never think of that myself, but I’m convinced it is true. People do not like to be patronized by tools they use, by them saying they made a mistake. People also keep forgetting password they set, especially for less frequently used services. The combination of those two is often frustrating. “Wrong password” information is formatted as an error, making user feel like they did something wrong or even malicious.

Rephrase and put less red colour in the message – and apparently people will feel more welcome to your app.

Not understanding OAuth

It is really common to see “Sign in with [XYZ]” buttons next to traditional email + password prompts. Some people like it, some people don’t. But it is nothing unusual these days.

Yet still, some developers seem not to understand how it works.

I’m guilty too. I remember that I created an app where after signing in with Github the user was registered in my database and… email with verification link was sent to his email. In my defense, it was at hackathon and was enforced by a poorly designed library, but I’ve seen it in production systems too.

To keep it simple: in OAuth scheme you trust the external provider (Facebook, Twitter, Github etc.) that it already verified the user. You get data from them and don’t ask further questions. Otherwise it is double-frustrating, because people (at least I) choose to use OAuth mainly because it’s faster than filling in registrations form and waiting for confirmation email to come. But with this wrong scheme I double-lose: I traded part of my privacy (probably) and got nothing in return (in terms of speed).

This, of course, does not apply to situation when you don’t obtain email address from OAuth provider. But that’s whole different story.

Not signing in after registration

This one might be a bit shady because it may be difficult to fix in some frameworks. But in general, when I completed the usual ordeal of going through registration, I’d like to be signed in right away. Schemes when I need to verify my email before even being let in the system are simply cutting corners. You should allow users to see at least a tip of the iceberg of what they can do with their brand new account, this way keeping them interested while confirmation email goes to their inbox.

What else?

Of course, this is not a complete list, by any means. Its purpose is just to show how a simple task like authentication can be re-thought to serve your purpose better and keep the users. If you can think of some more authentication-related sins we commit, let me know in the comments!