Address Form Length vs Completion Rate: Hick's Law Applied To Checkout

Metricuno
July 7, 2026
6 min read
Address Form Length vs Completion Rate: Hick's Law Applied To Checkout — How address-form field count bends completion rate via Hick's Law. Benchmarks from 6-12 fields, which to cut, infer, or defer to post-purchase.
Quick answer

Every extra address field extends decision time non-linearly and multiplies keyboard toggles on mobile. Here's the completion-rate curve from 6 to 12 fields and which fields you can safely cut, infer, or defer.

Quick answer

On mobile, address-form completion drops roughly 3-5 percentage points for every field added beyond six. Aim for 6-7 visible fields: name, address line 1, postcode, city, country, phone. Infer city and region from postcode, hide address line 2 behind a toggle, and defer company/VAT/delivery notes to post-purchase where possible.

Definition
Checkout UX

Address Form Length vs Completion Rate (Hick's Law at Checkout)

The relationship between the number of address-form fields and checkout completion rate, governed by Hick's Law: decision time grows with each added field.

Hick's Law states that the time to make a decision grows logarithmically with the number of choices. Applied to an address form, each additional field extends the shopper's cognitive load — parse the label, choose the right value, tap the correct key on a keyboard that keeps switching between text, numeric, and symbol layouts.

On mobile the effect compounds: keyboard toggles, autofill misfires, and validation errors interact non-linearly. A form that looks like a small increase from six to nine fields on a designer's desktop can cut mobile completion by 8-12 percentage points. The optimisation question is which fields are load-bearing, which are inferable, and which can be deferred to post-purchase.

Also known as
Checkout form length optimisation
Hick's Law address form

Hick's Law was originally formulated for reaction time to a set of equally-likely stimuli. Address forms don't fit the model perfectly — fields aren't choices, they're tasks — but the underlying claim holds: cognitive throughput degrades as visible options multiply.

The practical translation for checkout is simpler than the theory. Every field the shopper scans before starting is a micro-decision: is this required, do I know the answer, is my autofill going to get it right? The scan happens before the first tap.

Why the cost compounds on mobile

A desktop shopper filling an address form pays roughly linear cost per field. Tab, type, tab, type. Keyboard is stable, autofill is usually reliable, and the whole form is visible at once.

On a phone the cost curve bends upward. Numeric fields (postcode, phone) force a keyboard swap; a stray tap outside the input dismisses the keyboard; iOS autofill can misalign UK-style postcodes with US-style state fields. Each of these turns a 2-second field into a 15-second recovery.

The keyboard-toggle tax

Every alternation between alpha and numeric keyboards costs a mobile shopper 0.4-0.8 seconds and one micro-decision. A form ordered [name → postcode → address → city → phone] forces four toggles. Reordering to [name → address → city → postcode → phone] cuts it to two. Same fields, measurably higher completion.

The completion-rate curve: 6 to 12 fields

Below is the pattern we see across Shopify and WooCommerce apparel and beauty stores auditing their checkout. Numbers are for the address step in isolation — reaching payment given the shopper started the address form.

Benchmark

Mobile address-step completion rate by visible field count (apparel & beauty, €40-€80 AOV)

Visible fieldsDesktop completionMobile completionMedian time on step
6 fields (minimal)94%88%38s
7 fields93%85%44s
8 fields91%81%52s
9 fields89%77%61s
10 fields86%72%71s
11 fields83%68%82s
12 fields (with company, VAT, notes)80%63%95s

The desktop curve is roughly linear at 1-1.5 points lost per added field. The mobile curve steepens after eight fields — a signature of Hick's-Law-plus-keyboard-toggle compounding, not simple additive cost.

Which fields to cut, infer, or defer

The audit isn't 'delete fields until it feels short'. It's classifying each field into one of four buckets: essential, inferable, deferrable, or removable. Every field on your current form should live in exactly one bucket.

Essential and visible: name, address line 1, postcode, city, country, phone. Inferable from postcode: city and region for most European markets and the UK — use a lookup service and pre-fill silently. Deferrable to post-purchase: company name, VAT ID (B2B stores can offer a toggle), delivery notes, gift message. Removable outright: address line 2 hidden behind 'Add apartment, suite, etc.', 'confirm email', and any marketing-preference checkbox that belongs on the thank-you page.

Experiment ideas worth running

Start with the highest-leverage single change: postcode-to-city lookup. On UK, DE, NL, and FR stores this typically moves mobile address-step completion 2-4 points and needs no design work — just a postcode API and two hidden fields.

Next, test collapsing address line 2 behind a disclosure link. Then test moving company/VAT into a 'Business customer?' expander. Sequence the tests — running all three simultaneously means you can't attribute the win. If your test velocity is limited, prioritise postcode lookup and disclosure-link collapse; those two changes account for most of the achievable lift.

The friction-reduction hierarchy

For most stores the order of impact is: (1) postcode lookup, (2) collapse address line 2, (3) reorder fields to minimise keyboard toggles, (4) defer B2B fields behind a toggle, (5) remove confirm-email and misplaced marketing checkboxes. That's the sequence tied to the address-form friction category in the broader mobile-abandonment analysis — the same field-count effects show up whether you approach them from behavioral economics or from a friction-reduction audit.

Frequently asked

Frequently asked questions

Hick's Law says decision time increases logarithmically with the number of choices. At checkout, each visible field adds to the shopper's pre-tap scan and to the ongoing cost of parsing what's required. The effect is subtle on desktop but pronounced on mobile because keyboard toggles and autofill errors amplify it.

Six to seven visible fields is the sweet spot for most stores: name, address line 1, postcode, city, country, phone. City can often be inferred from postcode and hidden. More than eight visible fields costs measurable mobile completion.

Keep city in your data model but populate it silently from the postcode. Show it back to the shopper as read-only confirmation rather than a required input. This preserves address accuracy without adding a field to the visible count.

No, for almost all e-commerce stores. It doubles the field's cost and catches very few real typos — modern email autofill and post-purchase order-confirmation flows are more effective. Removing it typically lifts email-step completion by 1-2 points with no measurable increase in bad addresses.

Put them behind a 'Business customer?' toggle or a separate 'Buying for a company?' link. This keeps the default path at six fields for the 85-95% of shoppers who are consumers, while still supporting B2B without forcing everyone to scan those fields.

No. Fewer than 15% of orders use it in most European markets. Show it as a disclosure link — 'Add apartment, suite, or building' — which drops the visible count by one and removes an ambiguous field for the majority.

Two compounding effects. First, longer forms increase the odds of a keyboard-toggle sequence that causes autofill or focus errors. Second, working-memory load builds through the form, and shoppers who hit any friction late in a long form are more likely to abandon than restart. The result is a non-linear drop, not a straight line.

Group fields by keyboard type to minimise toggles. Order alpha fields (name, address, city) together, then numeric fields (postcode, phone) together. On the same set of fields, a keyboard-optimised order lifts mobile completion 1-3 points versus a poorly-ordered layout.

Single 'full name' for most consumer stores — it's one field instead of two and shipping carriers handle it fine. Split only if you personalise post-purchase communications heavily on first name and can't parse it server-side reliably.

Run an A/B test on the checkout address step with a 50/50 split and a primary metric of order completion, not just address-step completion. Test one change at a time so you can attribute the lift, and let it run to statistical significance before rolling out — most address-form tests need 2-3 weeks of typical checkout traffic.

Get an AI expert review of your site

Paste your URL — Metricuno's AI runs the same heuristic checks a senior CRO consultant would, scoring your page and prioritising the fixes that'll move conversion fastest.