The common killers: the friction patterns that abandon your signup

Required email verification before first use

WHAT IT LOOKS LIKE

The product is fully locked until the user confirms their email. The verification email may be delayed, land in spam, or require the user to switch apps mid-signup.

WHY IT HURTS

Most users verify when they have a reason to - usually when they want to do something the product prevents without a verified email. Blocking all access before the user has seen any value is a promise that the product is worth the friction. That promise is almost always unjustified.

THE FIX

Implement verify-later. Let users into the product. Prompt for verification before high-stakes actions: sending a payment, inviting a team member, accessing the API. For typical SaaS, this recovers 8-20pp with minimal increase in spam or abuse accounts.

Captcha friction

WHAT IT LOOKS LIKE

reCAPTCHA v2 checkbox (I am not a robot) is the highest-friction variant. Puzzle captchas are worse. Even the best-case captcha adds a perceptible delay and task to every signup.

WHY IT HURTS

reCAPTCHA v2 checkbox costs approximately 2-5% of legitimate signups per HubSpot and Baymard research. Mobile is higher. Users with cognitive or motor disabilities have a harder time. The GDPR implications of Google-loaded captchas are also relevant for European users.

THE FIX

Switch to Cloudflare Turnstile or reCAPTCHA v3 (invisible, score-based). Both reduce legitimate-user friction to near-zero. For B2B SaaS with vetted leads, consider skipping captcha entirely and using rate-limiting plus email-domain filtering as the primary abuse controls.

Required phone number at signup

WHAT IT LOOKS LIKE

Asking for a phone number before the user has derived any value from the product signals that you plan to call them. Even if your intent is SMS 2FA, users perceive it as a marketing list opt-in.

WHY IT HURTS

Formisimo/Zuko field-level analytics show phone number costs 3-12pp depending on context. The wide range reflects product type: a delivery service asking for phone at signup is expected and low-drop. A productivity SaaS asking for phone at signup is unexpected and high-drop.

THE FIX

Ask for phone after signup, inside the product, in context. If you need SMS 2FA, offer it as an option alongside TOTP apps or email OTP. Never make phone mandatory unless you have a legal or functional requirement (delivery, regulatory 2FA compliance).

Required SSN, national insurance number, or tax ID

WHAT IT LOOKS LIKE

Asking for a government identity number at signup triggers identity-theft fear in the majority of users, even when the use case is legitimate.

WHY IT HURTS

Users have been conditioned to guard SSNs and national identity numbers as the master key to identity theft. Asking for one at signup, before any trust has been established, creates an almost insurmountable friction barrier. The drop-off is catastrophic in non-regulated contexts.

THE FIX

Only request government identity numbers when legally required (e.g., regulated financial services, formal KYC contexts). If legally required, provide explicit context: explain the regulation, the secure handling process, and the consequences of not providing it. This is a case where the friction earns its keep - but it must be explained, not just demanded.

NIST-violating password complexity rules

WHAT IT LOOKS LIKE

Must contain uppercase, lowercase, number, symbol, be at least 12 characters, and cannot contain a dictionary word. These rules are explicitly deprecated by NIST and increase abandonment by forcing users to create unmemorable passwords.

WHY IT HURTS

NIST SP 800-63B (Section 5.1.1.2) states verifiers should not impose composition rules on memorized secrets. Forced composition reduces the user-chosen password space by making predictable patterns (Password1!) the path of least resistance. Longer passwords beat complex passwords on both security and usability.

THE FIX

Require a minimum length of 8 characters. Allow up to 64. Do not require composition rules. Check against breached-password lists (HIBP Pwned Passwords API, free and privacy-preserving). Add a zxcvbn-style strength meter to guide users toward better passwords without mandatory rules.

Confirm password field

WHAT IT LOOKS LIKE

A second password field requiring the user to retype their chosen password. Intended to prevent typos, but in practice users who mistype their password do so in both fields.

WHY IT HURTS

Nielsen Norman Group and Luke Wroblewski both recommend replacing confirm-password with a visibility toggle. When users mistype a password, they retype the same mistake in the confirm field because their mental model of what they typed is the same. The confirm field adds a field without meaningfully reducing errors.

THE FIX

Add a password visibility toggle (the eye icon). This achieves the same typo-prevention goal because users can verify what they typed before submitting. It is now standard across major products and expected by users.

Dense Terms and Privacy checkbox with no summary

WHAT IT LOOKS LIKE

A checkbox linking to a wall of legal text, sometimes bundled with a mandatory marketing opt-in on the same tick, presented to a user who just wants to start using the product.

WHY IT HURTS

GDPR and CCPA require meaningful consent, not a wall of text. Users have trained themselves to click through terms without reading, but the friction is real. The worst pattern bundles required service consent (ToS) with optional consent (marketing emails) on the same checkbox - this creates a false choice that damages trust.

THE FIX

Separate the required ToS consent from the optional marketing opt-in. Provide a one-sentence plain-English summary with a link to the full document. The marketing opt-in should be unchecked by default and clearly labelled optional. Legal does not require obfuscation - that is a product design choice.

Country dropdown defaulting to USA

WHAT IT LOOKS LIKE

The country dropdown is pre-selected to United States, requiring every non-US user to scroll or type to their country. Small friction, persistent conversion tax.

WHY IT HURTS

When 30-60% of your users are outside the US, this is a quiet but persistent 1-3% drop on those users. Alphabetically sorted dropdowns make it worse: users in the UK, Germany, or Japan are scrolling past dozens of countries. The US assumption is a leftover from US-market-first product thinking.

THE FIX

Use IP-based country defaulting with a manual override. Group likely countries at the top of the dropdown based on your user geography. Accept that you will occasionally get the wrong default and provide an easy correction path. Better: ask only for country if you genuinely need it for localisation, tax, or compliance.