Which Form Fields Cause the Most User Frustration?

Understand which form fields are likely to be causing problems for your form visitors

‍

In this video session we partnered with Webtrends Optimize to run through the form fields that consistently cause user issues, explain why, and discuss how to avoid the common problems associated with them.

‍

‍

If you found this useful then check out some of our other form optimization webinars and guides.

‍

Webinar Transcript: Which Form Fields Cause the Most Friction?

Introductions

00:00
Sandeep: I think we can probably kick off — it looks like the influx has balanced out a bit.

00:08
Sandeep: Morning everyone, and thank you for joining our webinar today. Just to introduce the two of us: I’m Sandeep, and I run the product team at Webtrends Optimize. For those who don’t know us, we’re an experimentation provider and we’ve been around since around 2000. I run most of the tech side here, and I’m joined today by Alun from Zuko.

00:36
Alun: Hey everyone — I’m Alun Lucas, Managing Director at Zuko. For those who don’t know Zuko, we’re a form analytics platform designed to show you when, where, and why users drop out of forms. We’ve been working on forms for seven or eight years, and we also do consultancy as well as software — so as you can imagine, we know a lot about forms because it’s basically all we do. We’ve made the conscious decision to specialise.

When Sandeep suggested doing a webinar on this topic, it made a lot of sense. Hopefully it’ll be useful and interesting for you today.

01:21
Sandeep: Thanks, Alun. Forms are a really interesting topic. It’s easy for people to critique browsing journeys on retail sites, travel experiences, and so on — we’re all used to doing teardowns of those environments. But with forms, understanding where things are going wrong (and getting that initial steer) is often much trickier.

People look at forms and think, “It’s just fields — what can I really do?” So they’re reluctant to dig into them. Yet the gains are normally high, because form fields are right at the business end of most journeys — typically just before conversion.

02:07
Alun: Yeah — it’s definitely the sharp end. Historically, forms haven’t been the “sexy” end of UX. People like spending money on big marketing campaigns, driving people to the site, and improving landing pages and home pages.

But forms carry a legacy from pre-digital days: you’d get a horrible paper form for a visa application, a university application, and so on. People hated them, but they didn’t have much choice. Now, with the click of a mouse, you can be on a competitor’s site immediately. If the registration experience isn’t good, users leave.

Today’s Topic + Poll

03:16
Sandeep: That leads nicely to today’s topic. We want this to be very practical: focusing on which form fields cause the most frustration, which ones you should look at first, and why.

We’ve also got a quick poll / quiz to kick things off — it’d be great if people can vote. We’ll leave it open through the session and share results at the end.

03:57
Alun: We’ve got data from thousands of forms that pass through our platform. We looked at six of the most common field types that appear on a lot of forms, and compared abandonment rates.

Abandonment rate here means: the proportion of users who interact with a field type and then abandon on it. It’s an average across a large dataset, so it should give a useful benchmark.

Field 1: Phone Number

06:50
Alun: The first field we’re going to talk about is the phone number field. It seems like it should be easy — people know their own phone number — so why do users abandon on it?

There are two main reasons we consistently see.

1) Users don’t want to give their phone number

Users often dislike being asked for their phone number, especially if it isn’t explained. Baymard Institute research shows unexplained phone number requests are a significant source of form abandonment.

This is especially true in e-commerce. People think: you already have my delivery address and email address — why do you need my phone number? Many users assume it will be used for spam or marketing.

So you always need to ask: do we really need it? There will always be some attrition because certain users simply won’t provide a phone number under any circumstances.

08:13
Sandeep: It’s interesting because nowadays email is everywhere. Order confirmations, shipping updates, delivery updates — you’ll see them all in your email. It used to be the case that people didn’t pay attention to emails and SMS felt useful, but now most people don’t really need that.

08:59
Alun: Exactly. If you absolutely need the phone number, you need to explain why. With good microcopy, you can often reduce abandonment. For example: “We’ll only use this if the delivery driver needs to contact you.”

In most cases, you should either remove the phone number field, or explain clearly why it’s required.

2) Phone number field formatting causes friction

The second issue is execution. Phone number fields are often designed around backend requirements rather than user behaviour.

Users don’t know:

• Should I include the leading zero?
• Should I add the country code?
• Can I use spaces, dashes, brackets?
• Will this validation reject my format?

Baymard Institute tested phone number fields with specific formatting instructions and found that 89% of users entered their number differently to the requested format.

The best approach is usually: let the user enter the number naturally, then sanitise and format it on the backend.

Should Phone Number Be Mandatory?

12:53
Sandeep: We’ve got a question: should phone number be mandatory, as we see in many places?

13:01
Alun: If it’s not mandatory, you should ask yourself why you’re asking for it in the first place. If you don’t need it, don’t include it. If you absolutely need it, then it might as well be mandatory — but you should test it.

13:30
Sandeep: The most important thing is to run experiments. Test mandatory vs optional. Test the impact of the field. You’ll get clear signals quickly.

Field 2: Passwords

14:09
Alun: Next up is the password field. This is one we consistently see users struggle with — not just abandonment, but a lot of returning and correcting the field.

14:33
Sandeep: Password fields can be messy. When you look at examples, you realise how often people are forced to enter uppercase, special characters, numbers, and so on — especially frustrating on mobile. I often use my mum as a mental benchmark: how easily would she complete these requirements?

15:25
Alun: Our own research shows that over 50% of users return to the password field at least once. Even in best-case scenarios, it’s around 30%. Password fields are inherently friction-heavy.

Overly strict password rules reduce usability (and often security)

One of the biggest misconceptions is that complexity drives security. In reality, password length is often more important.

Forcing special characters and complex rules can actually reduce security, because users:

• write passwords down, or
• reuse the same password across multiple accounts.

Our recommendation is typically:

• enforce a minimum length (e.g. 8+ characters),
• allow special characters, but don’t force complexity rules,
• consider encouraging passphrases (e.g. three random words).

Confirm password is often unnecessary friction

Confirm password is another big friction point. We removed confirm password from our own flow and saw conversion increase by 56%, without materially increasing password resets.

Masking passwords should always allow unmasking

If you mask passwords, you should always allow users to unmask them. On mobile especially, it’s hard for users to check what they’ve typed otherwise.

Field 3: Email Address

21:38
Alun: The final “simple” field is the email field. Again, it seems like it should be easy — everyone knows their email address — but we still see drop-off.

Common issues with email fields

One key issue is mobile UX: if you don’t set the field type to email, users don’t get the correct keyboard with the @ symbol and helpful shortcuts.

Baymard Institute found that 61% of sites had at least one field that didn’t set the correct input type.

Another common source of friction is email confirmation. Most people don’t forget their email address, and many users have autofill — so asking users to confirm email can add unnecessary friction.

Broader Friction Areas (Beyond Simple Fields)

Financial Questions (Income, Assets, APR)

25:56
Alun: Moving beyond simple fields, financial questions are a major source of friction. This includes income, finance, assets, and related information.

These questions are tricky because they’re sensitive and because users may not understand the terminology. People in financial services understand what gross income, net assets, and APR mean — but many users don’t.

Users may also feel paranoid about getting the answer exactly right.

What helps reduce friction

• Explain clearly what you mean (in plain language).
• Show where the user can find the information (e.g. payslip examples).
• If possible, ask for ranges rather than exact figures.
• Prepare users upfront if they’ll need documents.

30:12
Sandeep: The “before you start” experience is really important. If a form is long and users reach step 7, 8, or 9 before realising they need their passport or payslips, the frustration is huge. It’s much better to warn them upfront and give them a way to return easily if they leave.

Credit Check Address History

32:16
Alun: Credit checks are another common friction point. In the UK, credit checks often require three years of address history. That’s fine if you’ve lived in one place for years, but you’ll lose many users who can’t remember exact dates.

Ways to reduce friction

• First ask: “Have you lived at this address for more than three years?” (Yes/No)
• Only ask previous address details if the user says no.
• Ask for month/year rather than exact dates.
• Do the duration calculations for the user.

Employment Details / Job Title Selection

35:26
Alun: Employment details are another major source of friction, especially in insurance. Users are often asked to select job titles, but job lists frequently don’t reflect modern roles.

People also worry that selecting the wrong job title could invalidate a policy later.

Better approaches (in order of preference)

1. Ask for the information later in the journey if possible.
2. Allow free text input and categorise it in the backend.
3. Use a smart search function with suggestions.
4. Worst case: provide a broad dropdown list with “closest match” options.

Poll Result: Most Problematic Field

40:09
Sandeep: The poll results are in — 49% of attendees selected phone number as the biggest deterrent.

40:17
Alun: Based on our data, the highest average abandonment rate occurs on the password field. Phone number and email were around 4% abandonment on average, but password was around 10% abandonment.

This is especially important because password fields often appear late in the journey. If users abandon there, they were probably serious — so it’s a high-value place to optimise.

Q&A Highlights

Form Builders vs Bespoke Forms

42:39
Sandeep: How do you decide whether to build a form bespoke or use a form builder?

43:01
Alun: Generally, we prefer bespoke forms if you have the time and resource. It gives you control over things like error messages and experimentation.

But the biggest factor is how much access you have to the form. If the form is hosted in an iframe on someone else’s domain, you lose control and experimentation becomes much harder.

Accessibility: How to Mark Mandatory Fields

47:12
Sandeep: What’s the most accessible way to denote a mandatory field?

47:19
Alun: Red asterisks are common, but can be unclear — especially for screen readers. Adding small text like “Required” or “Optional” can improve clarity. Placeholder text can also help guide users, but shouldn’t replace proper labels.

48:36
Alun: We’re seeing a move away from stars, because they can be confusing. Sometimes asterisks are used for notes elsewhere on the page, and some forms even use stars to indicate optional fields. Clear microcopy is often more effective.

Closing

50:15
Alun: Thanks everyone for attending. If you have any form-related questions, feel free to reach out — LinkedIn is probably the easiest way to contact me.

51:13
Sandeep: We’ll share the recording on YouTube and LinkedIn as well. Thanks again for joining — take care.

51:41
Alun: Thanks everyone. Hope you found it useful.

‍