Authentication UX

That is the collision. Security asks for complexity while the user only wants to get in, and when complexity wins by force people build workarounds. One password everywhere, the pet's name plus a number, a notes app full of secrets in plain text.

That workaround is the point. Security a person can't work with gets worked around, and the workaround is what you end up defending. So most changes that make signing in easier also make it stronger, because they stop pushing people toward the sticky note in the first place.

Authentication sits at the front door, which is what makes the stakes so uneven. It is the first screen a new user meets and the wall a returning one hits. That puts it among the biggest sources of drop-off, support tickets and duplicate accounts in any product.

Anatomy of an Auth Flow

A ticket lands that says "add login". It sounds like one screen with two fields.

Then you start counting. A screen to create the account, one to prove the address is real, one to come back. One for the code from the phone, one to say the password was forgotten, one to set a new one. Four emails go out along the way, and somewhere a decision gets made about how long somebody stays signed in.

Six screens, then, before any of the interesting arguments start. Knowing the shape of the thing is what lets you argue about the parts.

The Screens, in the Order Somebody Meets Them

Sign-up:creates the account. It collects the smallest set of details you can run on and hands back a session.

Verification:proves the address or number belongs to the person. It is usually a link or a short code, and it can happen before access or in the background afterward.

Sign-in:the returning visit. It has to work out which method this account uses, which is harder than it sounds once there are several.

Second factor:proof of a second kind, normally a code or a tap on a trusted device. Most accounts never switch it on.

Recovery:the way back in when a password, a device or an address has been lost. It ends by setting a new credential and landing somebody back where they were going.

The Fields You Will Meet on Them

Six fields cover almost every auth form in existence, and most forms carry more than they need.

Email address:the identifier, and the one field that appears on nearly every screen here.

Password:the credential, on products that still use one.

Name:collected at sign-up by habit more than by need.

Confirm password:a second copy of the credential, meant to catch a typo.

Phone number:an alternative identifier and a delivery channel for codes.

One-time code:four to eight digits, valid for minutes, typed from another device.

Two of those six are usually deletable.The name can be asked for later inside the product, and the confirm field can be replaced by letting somebody see what they typed.

Pro tip: Draw your own product's auth flow as boxes on one page, screens and emails together, before you touch any of it. Most teams find two screens nobody designed and one email nobody has read since it was written.