How to fix the problems in your online form

‍

Zuko has partnered with Abi Hough from UU3, the respected UX consultancy, to bring you a webinar covering topics such as how to identify the pain points in your forms, how to evaluate the reasons behind them and how to fix them so your users' experience improves.

‍

‍

If you enjoyed this video, be sure to check out our previous Crimes of Form Design session and our Big Guide to Form Optimization and Analytics.

By watching this video you'll gain insight (including a live form example) on how to:

1. Discover user pain points
2. Evaluate your forms objectively
3. Break your form to understand where the issues are
4. Triangulate the pain points
5. Order & prioritise the issues
6. Which fixes to "just do"
7. Test and measure each issue and solution

‍

Conversion Killers to Conversion Winners (Webinar Transcript)

Welcome & Introductions

Alun Lucas:
Okay — so first of all, welcome everyone to our webinar workshop today, which is all about online forms: conversion killers to conversion winners.

What we’ll be taking you through is essentially how to diagnose issues with your forms — the problem areas — and then how to fix, or go about fixing, some of the common issues you might come across.

A little bit of housekeeping: we’ll be taking questions and answers, but we’ll do those at the end. If you could add any questions you have to the Q&A function, we’ll pick those up at the end.

So first up, a few introductions.

My name is Alun, I’m the Managing Director of Zuko Analytics. For those of you who don’t know Zuko, it’s a form analytics platform designed to tell you when, where and why your potential customers are dropping out of your form — so there’s a lot of synergy around the form optimisation topic there as well.

I have my colleague here, Lena — hello.

Lena:
Hello.

Alun:
One of our Account Managers. And of course today we’ve got with us Abi Hough, one of the foremost UX consultants around. Abi runs her own consultancy at UU3, which does a lot of work around UX improvement and optimisation.

But I’ll hand over to Abi now, because she’ll introduce herself and take you through the start of the webinar.

Over to you, Abi.

Abi Hough:
Okay — thanks Alun.

We’re going to turn cameras off now. Apologies guys, hang on a minute…

Okay.

So welcome to the webinar. Alun’s given us a very nice intro. As he mentioned, my name is Abi.

I’ve been in this industry for more years than I care to mention, and I’ve got a bit of a reputation for being quite straight-talking. Just a heads-up for this entire webinar: there might be some swearing, so apologies.

I’ve been dealing with websites generally for about 20 years or so. I started as a front-end developer, then moved into wondering why my websites weren’t doing as well as they should have — which led into more interest in the UX side of things.

Part of my work is to carry out audits on websites for clients across desktop, mobile and tablet. From the audits that I’ve done, I’ve raised thousands of issues that need to be fixed — whether they’re functionality problems or UX problems — a whole plethora of issues to be resolved.

I’ve probably identified around £250 million in lost revenue for those clients, due to functionality issues their websites had.

Apart from auditing websites, I’ve also run thousands of A/B tests. That’s right the way from doing the research, to designing, building, QA, running and analysing the results.

That’s given me lots of opportunities to discover what works most of the time, discover new learnings — or failings, whichever you want to call it — and also figure out what you really shouldn’t be doing.

So that’s a bit about me.

Let’s carry on with the webinar.

Why Forms Still Matter (and Still Suck)

So, what have I learned in all of this experience?

Well basically: forms still suck.

There are crap forms everywhere, and nearly every audit that I carry out, one of the main issues relates to interactions on forms — and the conversion rates of those forms.

Alun:
Yeah — and obviously we can see that from our side. We see forms every day, and you very rarely get a form that doesn’t have an issue, or something that can’t be improved, because of the bad user experience it’s creating.

Abi Hough:
Yeah, that’s really true. For any audit that I do, I’d say a quarter of the issues raised relate to forms on the site.

So it’s a big area to look at, and a good place to start optimising and improving for your users.

So we need to fix forms generally, from what I’ve seen working in the industry. But why do we need to fix them?

Well, it’s not just for my own sanity — there are lots of other reasons.

Forms are really the only way that your users can send you information about them.

You use forms (or form elements) for your users to tell you what they want: selecting product options, filtering products, searching for a product.

And once they’ve found that product, they need to tell you who they are if they decide to purchase it: their name, their contact details, delivery information, and payment information.

Forms are everywhere.

So we need to make sure they work.

You might think your forms are doing just as well as José here — our little Mexican spider who looks very happy about his form.

But that’s not the truth of it from what I’ve seen — and I’m sure Alun would agree.

Alun:
No, no — certainly. Definitely.

Abi Hough:
Exactly.

So how it’s actually going, in my view, is a bit like this penguin being pecked on the beak.

You’re setting your users up to fail when it comes to your forms.

Most forms are still really difficult to use in terms of UX and UI. They are poorly designed and implemented across devices in particular.

They’ve got bugs that prevent or hinder completion of the form.

They make you use System 2 thinking way too hard.

And there’s also the question your user might ask: “Why are you asking me this?” — because you’re requesting too much information.

Alun:
Just to add a little quantitative data to that: studies we’ve done at Zuko, and other external studies, have shown that about two-thirds of form visitors don’t complete your form successfully.

So there’s a large group of users who don’t complete, and a lot of room for improvement — which backs up what you were saying.

Abi Hough:
Yeah, I totally agree. They’re one of the biggest conversion blockers.

You can do all you like further up the funnel, but if it all rests on a form at the end and that form is bad, you’re wasting your time.

So a bad form basically means bad conversions, bad user experience, bad customer retention — who’s going to want to redo that anytime soon?

There’s also bad accessibility, which is a whole raft of other problems you need to be dealing with.

It’s just bad everything, and you’re setting yourself up to fail — a bit like entering Squid Game, for example. Awesome series. Everybody should watch that.

So we know forms in general are pretty awful — but how do we go about fixing them?

How to Identify Form Pain Points

We’re going to run through my process for how I evaluate a form, and the steps we need to complete to do that thoroughly and correctly.

The first step is to discover all the pain points that your form might be imposing on your user.

There are lots of ways to do this, but this is the standard list I go through.

1. Google Analytics Tracking

The first thing we can look at is setting up GA tracking.

This allows you to send form errors into Google Analytics — for example, tracking specific validation errors.

There’s a great article linked here from a guy called Charles Needham, who gives four steps:

• creating a new trigger in GTM
• identifying the unique ID for a given form error
• adding that unique ID to a trigger
• creating a new tag

This approach is great because most of you probably have Google Analytics (or another analytics platform) in place already, and it’s useful for basic error tracking.

It lets you filter by device type (desktop, tablet, mobile), so you can see where the problems are.

It’s also good for setting up a “tripwire” — basically a red flag alert for anything going wrong.

The downsides are that it depends on technical capability, because it requires dev time to implement the triggers and tagging.

And if you want to do anything complicated, it can get tricky quite quickly.

It’s also just numeric data — it tells you how often something happens, but not why.

2. Hotjar (or Similar Tools)

Next, we want to look at something like Hotjar (or similar).

If you haven’t got something like this set up on your website, you probably want to ask yourself why.

It’s wonderful for getting insights into how your website performs generally, or in particular areas.

But from what I’ve found with clients, it can become an insight wasteland: it’s all set up, but nobody looks at the data.

You really need to dedicate time weekly to dive into it.

It gives you lots of useful things:

• heatmaps
• clickmaps
• scrollmaps
• recorded user sessions
• live feedback and surveys

I believe they’re offering a free trial at the moment, so if you haven’t got it, you should.

One downside: they used to have form tracking functionality, but they’ve now removed it — which is a shame.

Probably good for Alun though…

Alun:
Yes, yes — good for us.

Abi Hough:
And as mentioned, it can become an insight silo. People install it and forget it.

But it’s really important to set up the reports you want, and look at them regularly.

3. Customer Surveys and Live Feedback

Another thing we can look at is customer surveys and live feedback.

A great question to ask post-purchase would be:

“What was the number one thing that stopped you from purchasing today?”

Or if you want to evaluate a specific page, you could ask:

“What’s holding you back from completing this task right now?”

Ask users to be as specific as possible.

The advantage is that it tells you how users are actually feeling, directly.

It can also give you additional insights you weren’t even expecting.

The disadvantage is that the data can be messy and noisy, and it takes time to distil key takeaways.

And if surveys are poorly implemented, they can have a detrimental effect — placement and timing are critical.

Nobody wants a survey popup 30 seconds after landing on a website.

One clever approach is triggering a survey after a user has been “faffing around” on a page for a certain amount of time — which can indicate something’s wrong.

4. Device Testing

This is kind of my speciality: device testing.

If you’re using Chrome DevTools or any emulator or simulator, you’re not really device testing.

To do it properly, you need physical devices that represent your users: phones, tablets, desktops.

Typically:

• two or three different mobiles (different sizes and operating systems)
• one tablet
• desktop testing on Windows and Mac
• testing different resolutions

You can use BrowserStack, but I’d consider that a last resort compared to physical devices.

Once you start testing on physical devices, you’ll see what a difference it makes.

The advantages: you’re testing what your users actually use.

The disadvantages: you need to figure out which devices matter, but there are great articles on this.

The cost is usually not prohibitive — you can buy second-hand devices cheaply.

Your users are not all on brand new shiny phones — they’re often on older ones.

(Abi pauses to grab a drink.)

5. Expert Review / UX Audit

Another option is getting an expert in to review your website or your form.

Sometimes, when you’ve worked on a project for too long, you can’t see the wood for the trees.

It’s like banner blindness — you stop seeing obvious issues.

A fresh set of eyes will pick up what you missed, and identify opportunities you hadn’t even considered.

A frequent argument against this is cost — but the ROI is usually substantial.

To give an example: an audit I carried out cost about £8,000.

One issue identified showed the company was losing £133 million per year.

So they spent £8k and recovered around £133 million.

Well worth it.

6. Zuko Analytics

Next we’re going to move on to Zuko — and I’ll hand over to Alun so he can talk you through how that can help identify problems.

Using Zuko to Identify Form Issues

Alun:
As Abi says, Zuko is another option to identify where issues might be with your form.

One thing I would add is it’s very easy to set up compared to Google Analytics. You don’t need to be a developer — it’s just a couple of tags to add to your forms, and Zuko will automatically pull everything through.

What I’m going to show you today is some real-life examples of how you can use data to identify exactly where the issues are in your form.

The first obvious place to start is abandonment.

Field Abandonment

Where do users abandon? What is the last thing they touch before they leave the form?

There are two things you need to look at:

1. Abandonment volume
Which fields are people abandoning on the most?

You can see in this example:

• Employment
• Submit button
• Employment status

These are causing a lot of abandonments.

2. Abandonment rate
This is the proportion of users who interact with a field, and then leave on that field.

This is especially important for conditional forms where not all users see every question.

A field might not have high abandonment volume, but it could have a very high abandonment rate.

For example here there’s an ID check field with a 37% abandonment rate — which is very high.

In this case, it’s probably kicking out under-18s — but it’s still a good starting point to investigate.

Behaviour Differences Between Completers and Abandoners

The next thing you need to look at is difference in behaviour.

There are two types of people who visit your form:

• those who abandon
• those who successfully complete

If you can identify different behaviours between those two groups, it’s a great insight into where the problem might be.

Here we’re looking at the proportion of sessions where someone returns to a particular field.

For example: Rent / Mortgage.

In abandoned sessions, 10.35% return to that field.

In completed sessions, just under 7% return.

That’s a significant difference — and we highlight statistically significant differences automatically.

That suggests users are having to return to that field (often due to error messages) and eventually abandoning.

Sometimes you see the opposite, like Home telephone number — where completed users return more often than abandoners.

That usually indicates usability friction, but motivated users push through.

The key is the difference in behaviour.

Submit Button Abandonment and Field Flow

The next thing is the submit button.

If you see high abandonment around the submit button, does that mean the button is bad?

Sometimes it’s technical, but more often it’s caused by error messages in other fields.

Users click submit, see errors, and give up.

So you need to surface what’s actually happening.

Zuko has a report called Field Flow.

You select a field (e.g. Submit), and it shows what users do next.

This is filtered to abandoned sessions.

You can see:

• many click submit and abandon immediately
• others go back to fix specific fields

In this pet insurance form example, users go back to:

• Animal name
• Select your product
• Animal birthday

That tells you where the issues are.

And Animal birthday is interesting — maybe users don’t know it. Are you asking for irrelevant information?

The key point is: if you can see where users go after hitting submit, you can identify where the friction is.

Mobile vs Desktop Segmentation

One last piece of data is comparing mobile vs desktop behaviour.

Often users have different pain points depending on device.

For example:

• Contact number makes up 7% of abandons on mobile
• but nearly 15% of abandons on desktop

Conversely, email is worse on mobile than desktop.

That might indicate formatting issues, keyboard issues, or validation problems.

So segmentation is a key thing to look at.

Hopefully that gives you some ideas of how to use real-life data to identify where the problems are.

I’ll hand back to Abi now.

How to Evaluate Your Form (The Right Mindset)

Abi Hough:
Cool, thank you.

So how do we evaluate forms?

First thing: it’s about the mindset you go into this challenge with.

This might be what you think users do: perfectly logical, straightforward, no distractions.

But what we see from user research is it’s actually like this…

This is the Magic Roundabout in Swindon — utter chaos. Traffic going left, traffic going right, distractions everywhere.

This is the mindset you need to be in when evaluating forms.

Don’t think like a professional calmly reviewing your form.

Think like a real user: a mum with kids crying, someone cooking dinner, someone multitasking.

Users rarely fill out forms in a calm environment.

They’re distracted, overloaded, and rushed.

So keep that in mind as we go through the checklist.

Form Evaluation Checklist

These are relatively low-risk activities.

We’ll talk about more advanced and risky things later.

1. Error Handling

What happens if you enter nothing into the form and hit submit?

What happens if you miss a mandatory field?

What happens if you miss all optional fields — are there hidden mandatory inputs you didn’t realise were mandatory?

What happens if you enter unexpected data?

• too many characters
• lorem ipsum
• special characters like symbols
• Unicode
• the wrong type of data

What happens if you enter numbers into an input expecting letters?

If your form requires a file upload:

• what happens if you upload the wrong format?
• what happens if the file is too large?

What happens if you enter a malformed email address?

Does the form provide suggestions or totally fail?

Another good test: enter a wonky postcode — like using “O” instead of zero.

Then check the timing of errors.

Do errors trigger at the right time?

Not too soon, and certainly not only after the user completes the whole form and hits submit.

Do errors clear when corrected?

Is the user told when data is valid?

Are errors placed correctly?

Errors should be close to the problem field.

Also: don’t rely only on colour. Use helpful error copy.

Alun:
Just to quantify this: moving error messages inline and triggering them at the right time can have a big impact.

There was a study by Luke Wroblewski showing a 22% increase in conversion rates just by sorting out error messaging.

It’s one of the most consistent high-impact changes we see.

Abi Hough:
Absolutely.

And please stop using sloppy errors like:

“This field is a required input.”

2. Ease of Use

Is the form keyboard accessible?

Can I tab through it?

Is the tab order logical?

This is important for desktop-heavy audiences and accessibility.

Does the form have correct input labelling for screen readers?

On touch devices, does the correct virtual keyboard appear?

Phone number should trigger numeric keyboard — not QWERTY.

Is there enough whitespace to avoid tapping the wrong thing?

Copy/paste is controversial, but disabling it is infuriating — especially for password managers.

If you insist on passwords, make them easy to understand.

Password validation should be clear.

Alun:
If you make passwords too complex, you often make security worse — because users revert to predictable passwords like adding “123”.

Passphrases can be better.

Abi Hough:
Exactly.

Two-factor authentication is another option.

There are links on this slide for accessible forms and keyboard types.

3. Data Handling

Users don’t always complete forms in one session.

What’s the timeout behaviour?

If users move back and forth through steps, is data retained?

What should be retained vs cleared for security?

If users edit billing and delivery addresses, does it update properly when they return?

If you require strict formatting (like date of birth), provide guidance.

Abi Hough:
Alun, any insight on date of birth entry fields?

Alun:
Yes — the most effective format is usually three separate text boxes.

Dropdowns and date pickers often perform badly because users have to scroll back years.

Also: always explain why you need the data. Date of birth and phone number are big trust blockers.

4. Styling

Make sure form labels are clear and well placed.

There are lots of arguments on label placement — experiment to see what works.

Check contrast — labels are often too faint.

Labels should be persistent — avoid disappearing in-field labels.

Inputs should look like inputs.

Use optimal input types for the device.

Two great resources:

• GOV.UK Design System
• Baymard Institute

5. Copy and Microcopy

Error messages should be helpful, not generic.

Provide security messaging so users feel safe.

Provide tooltips for sensitive data (e.g. date of birth) and complex data (e.g. passwords).

Explain why you need certain information.

6. Viewport Issues

Especially on mobile and tablet:

Tooltips and errors must stay in the viewport.

They must be easy to dismiss.

Auto-zoom on iOS inputs should be disabled — it causes friction.

And despite what people say, the fold matters.

Make sure progression and key actions are visible.

7. Integration Failures

If you use integrations, what happens if they fail?

What happens if reCAPTCHA fails?

What happens if payment gateways fail?

Is there a Plan B?

Also check the thank you page experience.

Do users receive confirmation emails?

Some users leave the browser window open until confirmation arrives — so make sure that reassurance is there.

8. Security Testing (Advanced)

These are things you can do, but don’t do them unless you know what you’re doing:

• cross-site scripting testing
• SQL injection testing
• modifying form variables client-side

Not something to do on a live site unless you like chaos.

If you want to check form integrity, get technical QA or developers involved.

Triangulating Issues and Prioritising Fixes

So once you’ve gathered all this information, you need to triangulate the pain points.

Log all issues and group them by type:

• error handling
• cognitive load
• abandonment hotspots
• accessibility
• functionality bugs

Then identify how many times each issue appears across your research.

Once that’s done, prioritise.

I tend to prioritise by:

• Just do it (obvious fixes)
• A/B test
• Measure before/after
• Difficult business stuff (red tape, politics, compliance)

Frameworks you can use:

• CXL’s PXL framework
• conversion.com scoring framework

“Just Do It” Fixes

Some examples of things that should just be fixed:

• wrong mobile keyboard types
• autocorrect triggering
• auto-capitalise triggering
• auto-zoom on input focus
• whitespace and tap target issues
• critical content above the fold
• errors shown only after submit
• inline validation timing
• generic error messages
• tiny red error text
• lack of instructions
• no explanation for sensitive fields (trust building)
• disappearing in-field labels
• wrong input sizes
• unclear optional vs mandatory fields
• broken keyboard accessibility/tab order
• no show-password option
• password manager interference
• distractions on the page
• trapping users in the funnel with no navigation

Things to Test and Measure

Examples:

• label position and font size
• grouping/chunking of information
• order of questions
• input sizes and types
• password rules and reset process
• tooltip usage

When You Might Add Friction

Sometimes increasing friction improves trust.

If something feels too fast, users may think the process isn’t legitimate.

Example: insurance quote forms.

If the “quote loading” is instant, users may believe no effort was made.

A slight delay can increase perceived credibility.

Difficult Business Stuff: Example Case Study

Let’s run through an example.

This was an e-commerce site I worked on.

The checkout had loads of steps:

• personal details
• address details
• previous address details
• payment method
• income declaration
• terms and conditions
• review order
• confirmation

Loads of steps.

But our research showed the main pain points were on:

• personal details
• address details
• previous address details

The control looked like this: personal details on the left, loads of distractions on the right.

Then address details with postcode lookup, and a question about how long they’d lived at their previous address.

When I first saw it, I felt like this — because there was huge opportunity, but also a lot of stakeholder negotiation required.

Using Zuko Data

This is where I first came across Zuko.

We ran it and identified the most difficult inputs:

• yellow = users who dropped off
• blue = time taken
• purple = number of corrections

We saw issues with:

• email
• password hints
• years at address

And it was device-dependent.

We then did device testing and expert review:

• iPhone 6S
• iPhone 5
• iPad
• Windows Chrome at 1366x768

We found over 80 UX issues and bugs.

Zuko showed us what was happening — and the device testing told us why.

Business Pushback

We asked questions like:

• why do users have to confirm email?
• why do they have to confirm password?

The business response was usually reluctant to change.

So we countered with: “What if we did X, Y or Z?”

We also identified who we needed to speak to directly to get answers.

And because this was checkout, it was risky to A/B test — so we built mitigations:

• what if information isn’t entered correctly?
• what if the test bombs?
• what if stakeholders complain?
• what if customers complain?

Iteration 1 Changes

We moved personal details to the start.

We changed the date of birth entry format.

We added age restriction messaging near the related input.

We simplified phone number entry.

We clarified why email was required.

We pre-filled the login email address based on contact email.

We added simple password rules and show-password functionality.

On address details:

• reduced prominence of optional fields
• reduced prominence of BFPO field
• clarified order updates section

It went okay — but we learned:

• title wasn’t used
• DOB wasn’t retained
• existing account users got booted out due to control issues
• additional phone numbers weren’t being entered
• email still incorrectly typed
• password rules still causing errors
• order preference number used incorrectly
• excess scrolling
• users opted out of marketing too early
• postcode lookup was missed
• address dropdown selection issues
• months at address not completed
• address data not retained when moving through funnel
• marketing opt-in placement questioned

Iteration 2 Changes

We added inline validation.

We improved clarity.

We improved password validation.

The “About You” section performed well, but we improved validation further.

We made address details multi-step with progressive disclosure:

• postcode lookup shown first
• then dropdown of addresses
• then pre-fill of address fields

We removed the month requirement for “years lived at address”.

We only showed previous address info if users selected “two years or less”.

We only displayed mobile number update if users opted in for order updates.

Results

This produced:

• 2.9% increase in conversions
• £2.3 million uplift
• 1.8% increase in completion of form pages

Key takeaways:

• build self-efficacy
• remove distractions
• reduce cognitive load
• chunk information
• logical sequencing
• progressive disclosure
• help users with tricky inputs
• optimise mobile UX
• prevent mistakes rather than just handling them
• reduce effort wherever possible

Summary Takeaways

Forms are an inevitable part of your funnel.

Even if your forms work, dependent elements may not.

Optimise:

• order of information requests
• what information is truly necessary
• device-specific UX and UI
• clarity and feedback
• retention of data
• cognitive load

Also remember: it’s not just about the form.

User motivation matters.

During the pandemic, users tolerated awful forms because their desire was high.

So desirability impacts form completion.

Do lots of research.

Don’t give up without a fight.

That case study took about two months of negotiation — but it was worth it.

Closing

Alun:
Thank you very much, Abi — and minimal swearing. I’m disappointed.

Abi Hough:
I’ll make it up next time, sorry.

Alun:
So yes — that’s it. Thanks for your time today.

We will do Q&A for those who can stick around. I appreciate we’re slightly out of time, but a couple of things first:

If you want to improve your forms and discuss anything with us further, our details are on screen for Abi and myself. If you want a chat or just an opinion on your form, feel free to ask.

If you want to learn more, Zuko has created a big chunky book on form optimisation and form analytics. The link is there to download.

We’ll share all these slides with everyone afterwards, as well as the recording.

And if you want to hear more from Abi, she will be at the Experimentation Elite conference in March next year in London.

That’s correct, isn’t it Abi?

Abi Hough:
Yep — who knows these days! Might be there virtually, but yeah — hopefully everything will be okay.

Q&A

Alun:
Let’s see if we can cover off the Q&A that’s come in.

Lena — have we had questions?

Lena:
Yep, we’ve had a few coming through.

So I’ll start with the first one.

Q: What’s the maximum number of fields per page?

Lena:
What do you suggest as the max fields per page? And what do you suggest for very long forms where pagination isn’t viable and all fields must be on one page?

Alun:
We do have an article on this in the Zuko blog. If you Google “Zuko multi-step forms” there’s an article covering a lot of this.

In terms of max fields per page, the main principle is to chunk together similar questions.

Personal details together, financial details together — that sort of thing dictates it.

Typically, between three to six fields per page is what we commonly see.

I don’t know if you agree with that, Abi?

Abi Hough:
Yeah.

I think it’s okay to have a long form. What I would avoid is what I call an “Andrex form” — a form that just goes on and on and on down the page.

But there are ways around it. If you must keep it on one page, use progressive disclosure — show one section at a time, then reveal the next section once completed.

You don’t want users loading the form and wishing they were dead by halfway through it.

So it’s about chunking information and reducing cognitive load.

In terms of field numbers, it’s highly dependent on the goal. I’d A/B test to find the optimal solution.

Q: Do multi-step forms improve completion?

Alun:
Jake’s asked: do you find breaking a form into two or three steps increases completion rates? He said tests he’s been involved in didn’t show much difference.

From the research we’ve seen — and it’s in the blog — it tends either to have little impact, or a positive impact.

It’s very rare that a single-page form performs significantly better than a multi-step form.

Abi, is that your experience?

Abi Hough:
Yes and no.

It’s highly dependent. It goes back to the argument of best practice.

There’s no right or wrong answer — you need to test and figure out what works for your audience.

My personal preference is not to be presented with a massive amount of information in one go.

If it is massively long, allow users to save and come back later.

The general preference is not to overload users with too many requests at once.

Q: Is GA error tracking GA4 or Universal Analytics?

Lena:
When you talk about tracking form errors in GA, Abi — is that GA4 or Universal Analytics? Do both support it?

Abi Hough:
Charles is your person for this — he’s the GA expert, not me.

I believe his solution relates to GA3, but read the article and drop Charles an email.

Q: Drop-offs at the beginning vs end of form — is there a pattern?

Lena:
Do you see correlation between drop-offs at the beginning of a form versus the end — general mental load — or is it always field-specific?

Alun:
From a data perspective, you tend to see high drop-off at the start of a form — people not serious about completing it.

They drop off on name fields or titles — not because they’re hard, but because they lose interest.

It could also be because the form looks horrible.

Then at the end, you often see drop-off around the submit button — people hit submit, get a wall of red error messages, and leave.

At the end it’s usually field-specific.

Abi Hough:
Yeah — if a user gets to the end, it shows high intent.

So what’s stopping them at the last hurdle? Usually errors shown after submit, instead of inline.

You’ll also always see field-level bail-outs, especially for sensitive inputs like email or date of birth, particularly if the user doesn’t understand why you’re asking.

Q: Do error message colours vary by culture?

Lena:
Do the colours of error messages depend on the culture of the region — China versus USA for example?

Abi Hough:
Yes — localisation matters.

But also: accessibility matters. Don’t rely solely on red and green, because of colour blindness.

Copy is critical.

Alun:
Agreed. Localisation also affects error message copy — what works in Germany can be very different to what works in the UK.

Q: How does postcode lookup work in the UK?

Alun:
Christoph asked: how does the address search button work next to the postcode field?

Abi, do you want to explain it?

Abi Hough:
Sure.

In the UK, a postcode narrows down a location to a small group of addresses.

You enter your postcode and click “Find address”, and it produces a list of all the addresses in that postcode.

You select your address, and the form pre-fills the full address details.

It’s quicker and improves conversion rates.

Q: Social login vs forms, and what if you need a field that causes drop-off?

Alun:
Michael asked: thoughts on login gateways versus forms — like Google or Facebook login.

Abi Hough:
It can be effective, but it depends on your audience.

For example, I personally hate social media and would never use social sign-in.

But younger demographics may be more receptive.

So a good approach is segmenting — show social sign-in to users more likely to accept it, and conventional signup to others.

Alun:
Also, we see differences between B2B and B2C. B2B users are often reluctant to give personal social data in a business context.

Michael also asked: if a question causes high abandonment but you require the information, what do you do?

Often the question itself isn’t the problem.

It might be:

• validation issues
• unclear formatting
• poor error messaging
• lack of microcopy
• not explaining why you need the data

Phone number is a classic example. If you need it, explain why.

Abi Hough:
And in the example I gave about “years lived at address”, it was required for a soft credit check — but that wasn’t explained.

Once we clarified why it was needed, users accepted it.

Expectation-setting earlier in the funnel is key.

Wrap-Up

Alun:
Great — we’ll wrap it up there.

Sorry we ran over.

If you have any more questions, please email us and we’ll be happy to respond.

Thanks for attending today, and thank you Abi for a sterling presentation.

Abi Hough:
Thank you everybody — bye bye.

‍