Why 1 in 3 Users Never Type a Single Character in Your Form

Roughly one in three people who see a form never type a single character into it. Not abandon halfway. Never start. They look at it, and they leave.

Two screens can do the same job — same app, same booking, same information — and one converts while the other is where your users go to die. The difference has almost nothing to do with design taste. It's about what each screen asks a human brain to do.

An empty field isn't a question. It's an invoice.

A blank input doesn't ask for information. It asks for work — an unknown amount of it, because the user can't see the bottom of the form and doesn't know how long any answer will take. So the brain estimates.

In 1949, the linguist George Zipf published the Principle of Least Effort, which gets quoted badly as "people are lazy." That is not what it says. Zipf described people minimizing the total work they expect to do — not just the immediate problem, but every probable future one. They're not lazy — they're budgeting. And your empty form just showed up asking for an unspecified withdrawal. Steve Krug drew the consequence in Don't Make Me Think: we scan rather than read, satisfice rather than optimize, and muddle through rather than figure things out.

Now measure the damage. Zuko Analytics publishes telemetry from 93,022,997 form views across 739 forms. Roughly 60 million produced a start — about a third of people who see a form never touch a field. The highest-abandonment field in the dataset is the password field, at 10.5%. Hold that one. (That one-in-three figure is view-to-start drop-off, which also bundles in irrelevance and slow loads; the funnel number is measured, the causal reading is mine.)

Why it happens is best framed by cognitive load theory. Every task carries intrinsic load — difficulty inside the job, like the fact that booking a table requires a date — and extraneous load, created purely by how you presented it. The second is entirely yours to fix. Almost every conversion problem in a form is extraneous load wearing a costume.

The jam study, told correctly

Almost everyone who cites the famous jam study gets the numbers wrong.

In 2000, Sheena Iyengar and Mark Lepper set up a tasting booth at Draeger's Supermarket in Menlo Park. Some hours they displayed 24 jams; other hours, 6. (It was 24, not 30 — the "30" belongs to the other two experiments in the same paper.) The big display was better at pulling people in: 59.9% of shoppers stopped for 24 jams versus 40.0% for 6. Then they bought. About 30% of the 6-jam stoppers purchased a jar (31 of 104), against about 3% of the 24-jam stoppers (4 of 145). Fifty percent more traffic, roughly a ten-to-one gap in purchase rate.

But the detail nobody quotes is the one that matters for your app. The researchers tracked how many jams each person actually tasted: 1.50 in the 24-jam condition, 1.38 in the 6-jam condition. Effectively identical.

Nobody explored the big assortment. Nobody sampled twelve jams and got tired. They looked at 24 options, made almost no comparisons, and left. The overload was anticipatory — people priced the job by looking at it and decided it was expensive. Which is exactly what happens on a screen with a dropdown and four blank fields.

Where the science breaks down — and where it holds

If the argument were just "more choice equals less conversion, science says so," it would be false.

A 2010 meta-analysis of 50 experiments and 5,036 participants put the mean choice-overload effect at D = 0.02, with a confidence interval spanning zero. Barry Schwartz, who wrote The Paradox of Choice, conceded the point in 2014: "Does choice overload always occur? Of course not." Decision fatigue as a mechanism is in worse shape — ego depletion has failed two multi-lab replications, 23 labs, N = 2,141, d = 0.04 and 36 labs, N = 3,531, d = 0.06, the second co-led by one of the theory's own proponents.

So why does any of it hold? Because in 2015 a different team asked a better question: not does choice overload happen, but when. Across 99 observations, 53 studies, and 7,202 participants, the effect is non-significant without moderators and significant with them (b = .17, p < .001). Four conditions predict it: the user is minimizing effort rather than shopping around (.56), the options are hard to compare (.55), the task is difficult or time-pressured (.37), and they don't yet know what they want (.32).

That is a perfect description of a signup form. Nobody downloads your app to configure it; they're doing this in a spare ninety seconds, can't tell what your options mean, and have never used the product. All four stack at once, which makes onboarding the highest-risk surface you own. The same research found the antidote: when one option is clearly dominant, the effect disappears.

Defaults are the fix

A dominant option is exactly what a default is. It's the same move recommendation surfaces make — Netflix's own VP of Product and CPO reported that about 80% of hours streamed come from recommendations, 20% from search — and it works because a tile converts an open-ended decision into a yes-or-no, which is cheap.

The best evidence for what that does to behavior comes from retirement plans. In 2001, Madrian and Shea studied a company that switched its 401(k) from opt-in to automatic enrollment. Participation went from 37% to 86% — that's the famous part. Here's the part that isn't: the plan carried a default contribution rate and a default fund, and 61% of auto-enrolled employees stayed on both, while among employees who had joined the old way and chosen for themselves, only about 1% had ever picked that combination.

Sixty-one percent landed on a setting that one percent of people would choose freely. The default didn't influence the decision. It was the decision.

The reason is that users don't read a default as a placeholder. They read it as advice. When Jared Spool asked Word users why they'd never changed a setting, the answer was "Microsoft must know what they are doing"; 401(k) employees described taking the default as investment guidance. So when you preselect "two guests" and "7 PM," you're not saving a tap — you're saying this is normal, don't think about this one.

Which is why the ethical line is sharp. A default is smart when it's the option the user would most likely have picked anyway. It's a dark pattern when it's the option you would have picked for them. Preselect the most common value, not the most profitable one — in the EU that's law, since the CJEU's 2019 Planet49 ruling made pre-ticked consent checkboxes invalid.

And one caution from that same study: its 3% default rate was too low for most people to retire on, and the auto-enrolled cohort ended up contributing less on average than the opt-in cohort. A default that's great for your metric can still be bad for your user. Choose them like you're giving advice, because you are.

What 64 form screens from top iOS apps actually do — our sample, Aug 2026

In August 2026 we audited 64 unique iOS form screens across 60 apps — signup, booking, checkout, profile setup — sampled via Mobbin and tallied by hand.

Sit with the first two rows. The industry knows defaults work — it deploys them wherever a reservation or a sale is on the line, then exempts its own registration walls, the screens where churn actually gets measured. The buttons are no better: 37% were greyed-out walls, dead until you'd done every piece of the work, and only 7% showed a live payoff. And placeholder-as-label — a failure mode Nielsen Norman Group has documented since 2014 — still ships on a fifth to a quarter of these screens, household names among them.

So nothing in the teardown below is exotic. It's the industry's own playbook, already running wherever your money is on the table, applied to the one screen it keeps skipping. (Caveat: this is a curated, relevance-ranked sample, and the unit is the screen, not the app. The percentages describe this sample.)

Teardown: rebuilding "Book a Table"

Same app, same job. Here's what changes, field by field, in the Verre restaurant booking form. Explore the interactive before/after: demo.html.

Date. Before: an empty box reading "Select date." After: "Tomorrow, Friday the 25th." The most common booking window, prefilled and still tappable. If you're the majority, you're already done.

Time. Before: "Select time," a blank field that opens a scroller with 48 options. After: four popular times as chips, one already selected, plus "View All Times." Broniarczyk, Hoyer and McAlister found in 1998 that people judge variety by heuristic cues, not by counting: cutting up to 54% of low-preference items goes unnoticed, provided the category space stays constant and you don't delete somebody's favorite. So we surfaced the popular options instead of removing any. "View All Times" is the preserved space.

Guests. Before: a blank number field, which summons the keyboard, which on mobile covers the form. After: a stepper starting at two, the most common table. We didn't just prefill a value — we deleted an entire input mode.

Seating. Before: a dropdown reading "Choose preference," which hides its own options, so you tap it just to find out what the question is. After: three visible tiles, one selected. Never make someone open a thing to find out what's inside it when there are only three things inside.

Occasion. Before: "Select occasion." After: gone. If picking "anniversary" doesn't change anything about what happens next, it isn't a form field — it's a survey you're charging your users to fill out. If you can't name what changes based on the answer, cut it.

The button. Before: "Search Available Tables," greyed out and dead until you've done all the work. After: "Search 12 Available Tables" — live, showing the payoff before you commit. And that grey button isn't a straw man; per the table above, it's the norm, while the live-payoff version is nearly extinct.

Count it up. Five decisions on the left, zero answered. Four on the right, all answered, every one changeable in a single tap, and one field gone entirely. That's the shift: from fill-and-hope to scan-and-go.

The identity layer

Now the password field, which I told you to hold. It's the highest-abandonment field in that 93-million-view dataset, and Baymard finds up to 19% of checkout abandonment among existing account holders traces to password-reset issues — customers who want to pay you and cannot get in. OAuth deletes that whole class of decision. If you add one provider, add Google, which is over 73% of social logins — and note that using any third-party login for the primary account triggers Apple's guideline 4.8, which requires an equivalent option that keeps the user's email private.

The counterweight, because you should have both: Auth0's server logs show social login is only 14% of actual logins, and a 2025 paper in Economics Letters found social-login registrants exhibit shorter tenures and lower activity. It's a trade — lower friction at the door, slightly less committed users walking through it. Worth making for most consumer apps, but make it knowingly.

The one rule

One in three people who see your form never type a character into it. They're not lazy — they're budgeting effort across everything else in their day, and every blank field is a withdrawal you're asking for before you've shown them anything worth paying for.

So here's the rule worth taking from all of it:

Never show a user an empty field you could have filled in for them.

Fill it with the most common answer. Make it obviously changeable. And if you can't name what a field changes, delete it.

Then go screenshot your own signup screen and count how many decisions you're asking for before someone has experienced a single thing your product does. Whatever that number is, it's too high.

Sources

Choice, cognition, and the replication picture - Iyengar & Lepper (2000), JPSP 79(6) — https://faculty.washington.edu/jdb/345/345%20Articles/Iyengar%20&%20Lepper%20(2000).pdf - Scheibehenne, Greifeneder & Todd (2010), JCR 37(3) — https://scheibehenne.com/ScheibehenneGreifenederTodd2010.pdf - Chernev, Böckenholt & Goodman (2015), JCP 25(2) — https://chernev.com/wp-content/uploads/2017/02/ChoiceOverload_JCP_2015.pdf - Schwartz, PBS NewsHour (2014) — https://www.pbs.org/newshour/economy/is-the-famous-paradox-of-choic - Sweller, van Merriënboer & Paas (2019) — https://leadinglearner.me/wp-content/uploads/2019/02/sweller2019_article_cognitivearchitectureandinstru.pdf - Hagger et al. (2016), 23-lab ego-depletion replication — https://journals.sagepub.com/doi/10.1177/1745691616652873 - Vohs et al. (2021), 36-lab ego-depletion replication — https://www.asc.upenn.edu/sites/default/files/2022-06/Vohs%20et%20al%202021.pdf

Defaults - Madrian & Shea (2001), QJE 116(4) — https://www.nber.org/papers/w7682 - Spool, "Do Users Change Their Settings?" (UIE, 2011) — https://archive.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/ - CJEU, Planet49, Case C-673/17 (1 Oct 2019)

Assortment and recommendation surfaces - Broniarczyk, Hoyer & McAlister (1998), JMR 35(2) — https://www.semanticscholar.org/paper/472e568670075463ba10c92bcb29818ea9dd86d5 - Gomez-Uribe & Hunt (2015), ACM TMIS 6(4) — https://dl.acm.org/doi/10.1145/2843948

Forms, checkout, and authentication - Zuko Analytics benchmarking data — https://www.zuko.io/benchmarking/about-the-data - Baymard Institute, password requirements and reset — https://baymard.com/blog/password-requirements-and-password-reset - Nielsen Norman Group, "Placeholders in Form Fields Are Harmful" — https://www.nngroup.com/articles/form-design-placeholders/ - Auth0/Okta Social Login Report — https://assets.ctfassets.net/2ntc334xpx65/77U9sLFO7rD7t9zdI6Q1SV/a8e2054b5affc0280769516eee70b0ea/Social-Login-Report.pdf - Newberry, Kim & Wagman (2025), Economics Letters — https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5100863 - Apple App Store Review Guidelines — https://developer.apple.com/app-store/review/guidelines/

Our own data - Mobbin form audit, n = 64 unique iOS screens across 60 apps, collected 2026-08-10

A note on evidence types: the academic citations above are peer-reviewed research; Zuko, Baymard, Auth0, and Nielsen figures are vendor or industry telemetry with disclosed samples but no independent replication; and the 64-screen audit is our own curated, non-random sample, descriptive of itself rather than of all apps.