Schermata con un form

13 October 2026

Why Users Don't Fill Out Your Form

You've added a form to your digital product but your users never make it to submit? Maybe the problem isn't them, it's you.

Tech

The form is often a critical point for landing pages and digital platforms. It's used to collect data from the user and can serve a variety of purposes, including:

  • Validating a product that isn't on the market yet.
  • Creating and editing an entity on a platform.
  • Letting future users join the waiting list for a product.


Unfortunately, as industry professionals know all too well, many users don't make it to the end of the form. Of course, the reason may have nothing to do with us; the user might realize they don't have time to fill it out right then, or get interrupted by factors beyond our control.


But in some cases, the way we handle the form contributes to driving the user away. So let's look at how to build a form that encourages the user to hit “send”.


Clear terms make for good friends: what kind of form is this?

The first way to earn the user's time and interest is to be clear about what's being asked of them:

  • How will the data they're entering be used?
  • How long will it take to fill out?
  • Why is certain information being requested, especially if it's sensitive?


Clarity serves a dual purpose: on one hand, it builds user trust, and on the other, it sets the right expectations.


If, on the other hand, the user is asked to fill out a questionnaire made up of “a few questions” about their in-app experience and finds themselves facing a dozen open-ended questions, they're very likely to give up, if only because when they opened it they weren't expecting to set aside half an hour of their time.


What should be stated up front

Which aspects should be made clear before the user starts filling out the form? First and foremost, obviously, the ultimate purpose; whether it's entering your email to receive marketing emails or a form on a platform to create a new user, the goal must be made explicit before the user starts.


The estimated time also plays an important role, especially for very long forms. For a questionnaire, for example, there should be a realistic indication of how long it takes to complete. Writing “5 minutes” when it actually takes a quarter of an hour is forbidden!


Also, if the form includes sensitive data, it's always helpful to state how it will be used. Moreover, what counts as sensitive data varies a lot depending on the context:

  • On a platform the user has already signed up for, payment-related data is particularly delicate.
  • But on a landing page, where the user hasn't yet developed an attachment to the product, even just an email address is something they might be reluctant to provide.


You don't need to ask for everything

A glaring mistake, though a common one, often made when creating a form is asking for unnecessary information. By unnecessary, we mean anything the user has already entered at an earlier stage.


For example, if a shipping address is needed to complete a purchase but the user already added their address to their profile when signing up, it may be legitimate to ask them to confirm it, but asking them to enter it again from scratch is a waste of resources.


From a different perspective, asking for a shipping address at sign-up, when the user hasn't bought anything yet, can help drive them away, again for reasons of trust, as well as weighing down the form itself. It's better to ask for data as it becomes necessary.


What to keep in mind while the form is being filled out

Have you ever filled out a form so unclear that it made you lose any desire to finish it? If you've dealt with some public administration portals, the answer is probably yes.


A form's clarity doesn't depend only on the copy used (which still deserves attention!), but also on aspects of how it's built. In this section we'll go over some usability rules your users will thank you for.


Prevention is better than correction

First of all, it's important to choose the right component for the data we want the user to enter. In this article, for example, we talked about how entering dates and numeric values is often needlessly complex.


Particular attention should be paid to labels, which must clearly suggest what content is expected. For example, if we're filling out a form to create a user and their company, the label “name” with no further indication risks being ambiguous: does it mean the name of the company or of the person signing up?


But it's also important to give specific instructions: how often, when signing up for a website, are you asked for a password with at least one uppercase letter, one number, one symbol and a minimum number of characters, but the instructions only appear after validation?


If the field requires a specific format, it's good practice to make it explicit through helper text, that is, the text below the input, or at the very least to anticipate it in the placeholder.


Choose the right moment to validate

When should the user find out they've made a mistake while filling out the form? Ideally, at the very moment they make it, so they don't have to go back to the form fields afterwards. But this can be tricky to implement.


Let's say the user has to enter their email. If validation happens while they're typing, as soon as they enter the first few letters, before the @ sign appears, the field will indicate that the email isn't valid.


Yet in this situation we don't really know whether the user has typed the correct letters so far or not; an error that shows up this early can be misleading.


The right compromise, then, is to validate when focus is removed from the input, or possibly on submit for shorter forms, and then in real time when the user goes back to edit a field with an error (in our example, as soon as the user goes back into the field and enters the @ sign, the error will disappear).


An extra note: when a form field has an error or not all the data has been entered, the submit button shouldn't be disabled! Making it unusable isn't feedback the user can understand. On the contrary, that button can be used to take the user, on click, to the field that needs to be filled in or corrected.


Watch out for errors

Error handling is an aspect of the form that deserves consideration. First of all, you need to take into account the accessibility of the error message: on one hand, it's good to use the appropriate colors to highlight the fields that need correcting, but on the other, to comply with accessibility criteria, color shouldn't be the only means of indicating the error; it should be accompanied by a corresponding icon or text.


And, speaking of which, the error message is often underestimated. Many forms provide vague error messages, such as “Invalid value” or, even worse, an error code. A message like that, however, doesn't let the user understand what they're doing wrong.


The message should clearly state what is expected of the user, for example “The start date must be before the end date”. Otherwise, the confusion caused by a vague message could push them to abandon the form, especially if they have to make several attempts to figure out how to correct their input.


A little gem: when the error stems from technical requirements and there's no ambiguity about the user's intention (for example, when the name field doesn't accept leading spaces and the user typed “ Marco”), autocorrection can make sense: on blur, the unnecessary spaces are automatically removed, without requiring any action from the user.


The form doesn't end when it's filled out

The user has finally reached the submit button, now what? Okay, if the button has been pressed, you've already got what you wanted from the user, but there are still some good practices to follow so that the user gets their satisfaction too.


Feedback is a must

What happens on click? The part that isn't visible to the user is that the server receives the entered data, but attention should also be paid to what the user sees.


From a practical standpoint, ideally right after the click the button switches to a loading state and becomes disabled, to prevent the data from being sent multiple times.


As for the screen as a whole, once its purpose has been fulfilled, some indications should be given, which vary depending on the case:

  • What the next steps are (e.g. the user will receive an email to complete their sign-up).
  • A celebration of the operation's success (e.g. confetti to celebrate signing up to the platform).
  • Whether the entity was created or edited successfully (e.g. a snackbar saying the article was published successfully).
  • A redirect to a relevant page (e.g. after creating a new user, automatically navigate to the user list).


Don't celebrate too early

One of the most annoying things that can happen, as a user, is getting to the end of a form, maybe even a very long one, clicking submit and… The form fails, maybe because of a server error, but the fields get cleared!


When something like this happens, it's very likely that the user decides to give up, and who could blame them. So, if you want to avoid losing a user, make sure the form isn't reset when the user finishes filling it out, but when the form has been submitted successfully, and in case of error, let them resubmit without any extra steps.


We hope these tips have helped you create forms that live up to your users' expectations. And if you'd like more tips, want to dig deeper into these topics (or challenge them, why not) or suggest new topics to cover, don't hesitate to write to us.