IV · Character

The Login Is a Gate

One component, three characters

I was reviewing a login screen that wasn't working, and for a while I couldn't say why.

Nothing was broken. The form was there: email, password, a button, a link to sign up. Around it, some context: YOUR NAME, you@somewhere.com, a tag that said PENDING. All reasonable. All, individually, fine.

But look at it the way the person arriving would: the decorative elements were shaped like fields. Type-in-shaped things you couldn't type into. A tag shaped like a button you couldn't press. And they sat at the same visual weight as the real form, same column, same scale, nothing saying I'm context, not action. Two failures stacked: things promising to be operable that weren't, and context competing with action for the same eye. Either alone is a problem. Together they're a small trust collapse, because the person's pattern-matching fires on the wrong things, fails, and now the rest of the screen feels unreliable too.

That was the symptom. The cause was more interesting, and it's why this chapter is in the part about character.

Who is standing at the door?

Stop and think about what a login screen is. It's a gate. Someone was on their way somewhere and this got in the way: hey, stop. Who are you? Or, if the place is open to everyone, a different gate entirely: hey, you've got an account already? No? Come in, make one.

The component I was looking at had three modes. Open, anyone can join. Request, you ask and someone lets you in. Invite, you have a code because somebody wanted you here. Same component. Three different gates. And three different characters standing at them.

The open gate is a casual host. Yo. Got an account? No? Cool, make one. The request gate is a gatekeeper. Who are you, and why should we let you in? The invite gate is a bouncer. Got a code? Prove you were invited.

The design was failing because it was trying to be neutral across all three. One posture for three situations. But neutrality is the enemy here. Each gate has its own tone, its own set of things that matter and things that don't, its own idea of what the person arriving already knows. You can't design the component once and parameterise it. You design it three times, and then find what the three share.

That's the argument of this part made concrete: a component doesn't only have behavior. It has a posture. And posture is character, at the scale of a single screen.

Density matches commitment

Once the three characters were named, the second thing fell out, and it's the one I've reused most since.

The person at the invite gate came here on purpose. They have a code. They want in, now. So the bouncer can show everything at once: sign in or sign up, Google or email, all on one screen, one click to any path. The density is a courtesy; they're committed, and making them walk through steps would be the gate pretending they're strangers.

The person at the open gate is a stranger. They might leave at any step, and every step is a chance to lose them. So the host unfolds the form one small decision at a time. Just the email field. Then, when that's done, the next thing. Each step small enough to be abandonable without feeling like a failure. The low density is also a courtesy; it's the gate matching how little this person has decided so far.

Same fields. Opposite layouts. The character of the gate determines how much it asks of you at once. Density matches commitment.

Three smaller things come with it. One decision at a time, with a visible way to choose something else, so the path is focused but never forced. The system absorbing complexity the person shouldn't feel: Continue with Google handles both sign-up and sign-in, because the system doesn't care which it is and the person shouldn't have to pick a verb; they pick a method and the system works out the rest. And the matrix as the artifact.

The matrix is the artifact

Three modes, two actions, two methods. Open, request, invite; sign up, sign in; email-and-password, Google. Twelve paths.

The temptation is to design the screen and let the twelve paths be variations on it. What I've come to do instead is design the twelve cells and let the screen be whatever the cells need. Each cell has a person in it with a specific amount of commitment and a specific amount of context, and each cell earns its own posture. Most of them will turn out to share a lot. The ones that don't are the ones the single-screen design would have got wrong.

Where this bends

There are gates where neutrality is right, because the product has no self yet and shouldn't pretend to. A new internal tool for eight colleagues doesn't need a bouncer; it needs a door that opens. Character at the gate is earned by the product having a character behind it. Put a personality on the login of a thing that has none and you've written a cheque the next screen bounces.

Questions to carry

• Who is standing at this door, and how much have they already decided?
• Is this screen one posture pretending to serve three situations?
• What's the matrix here, and which cells did the single design quietly get wrong?

(The 12-cell matrix is in the Field Kit, Decisions.)