# The field where signups go to die

Canonical: https://flusterduck.com/blog/the-field-where-signups-go-to-die
Published: 2026-08-20 · The Flusterduck team

Form abandonment is almost never about the form. It is about one field, and the form has usually been telling you which one all along.

Teams talk about form abandonment like forms wear out evenly, the way a rope frays. "Our signup form converts at 61%." Watch enough real sessions and you learn that is rarely how it goes. Forms don't fray. They snap, at one specific field, and the aggregate number smears the snap into a gentle slope that looks like nobody's fault.

Which field it is differs by product. How people die on it barely differs at all.

## Three ways out

The most common exit: a field gets focused, gets a good-faith answer, and the form rejects it. The person fixes it. The form rejects it again, for a different reason it hadn't mentioned yet. Password rules disclosed one failure at a time are the classic version. Eight characters, then also a number, then also a symbol, each requirement revealed only by violating it. There's a rhythm to these sessions once you've seen enough of them: people forgive a form twice. The third rejection is where the session ends.

Second exit: the question that's expensive to answer. A VAT number, a company size, a phone number someone doesn't want to hand over. In the events it looks like brisk progress through the easy fields, a long stall on one field, a tab away to another window, then either a made-up answer or nothing ever again. Every one of those stalls is a user-research finding you didn't have to commission. Somebody sat there deciding whether you're worth a phone number. A lot of them decide no.

The third exit produces actual rage: the submit that eats the work. Something fails server-side, the page reloads, nine completed fields come back blank. Rapid clicks on submit, a pause, one scroll down the emptied form, gone. I don't blame them. That person didn't abandon your form. Your form mugged them.

## Cheap fixes, expensive diagnosis

The maddening thing about this category is the ratio between finding the problem and fixing it. The fixes are nothing. State every password rule up front. Validate on blur, not on submit. Push the expensive question to after the account exists. Treat typed-in state like money, because to the person typing it, it is, and never lose it no matter what the server does.

Finding the right field is the entire job, and the standard funnel view can't do it because it stops at the page. "Signup page, 39% drop" gives an engineer nothing to act on. "People who focus the phone field abandon at three times the rate of people who don't" is a ticket that gets closed by lunch. Same data underneath. The difference is whether your unit of analysis is the page or the field.

## Do it once by hand

If you instrument nothing, run the manual version. Fill out your own form wrong in every way you can invent, on a phone, and count the round trips each mistake costs. Anything past one round trip is a tax your users have been paying without your knowledge, because you type the happy path from muscle memory and they don't have one yet.

We keep finding these on our own forms, [which I've made peace with admitting](/blog/your-error-tracker-thinks-your-site-is-fine). A form is the densest reporting surface you own. Every field is a sensor. Every retry is a complaint, filed by the most motivated visitor you will ever have, at the exact moment they were trying to hand you money or an email address. The complaints are already being written.

Read them.