Why forms are hard
Web-forms (subsequently just “forms”) have been one of my focus areas, while working for different companies in varying fields. Here I want to lay out some of the reasons why building forms usually turns out to be more complex than anticipated, even if the forms are simple and the scope is clear.
Forms are an important part of almost every website and app. They are usually considered tedious and un-sexy. As of today, they are still the most used solution to collect data from users. There are attempts to replace forms by chatbots or other more interactive methods. Theses solutions will not be the topic of this article.
When planning for a project that requires forms you will most likely come across several people who will tell you that “forms are simple” or that the difficult part of forms is everything that happens after pressing “Send”. In this article I will try to shed some light on why forms usually turn out to quite difficult to get right.
The problem is mostly UX
But not entirely…
What makes forms difficult is rarely the technical implementation. There is only one pitfall I would like to point out here, which I have encountered multiple times: re-usability. Making form elements modular and re-usable is certainly a good idea. But achieving real modularity can be challenging. Suppose you are asking for exactly the same piece of data in two different forms. Even a small change in wording can void re-usability. Think for example of two different forms asking for a health insurance number. In both cases, you will need the same validation to ensure the correct format. But the error message that is showing when entering wrong data might be different, depending on the context. Here is a real life example, where the help text had to be adjusted:
Sure, you could use the same wording in both cases, but the UX would not be ideal. A good architect would certainly know how to handle these challenges properly. But keep that in mind when planning your form project.
So what are the real challenges?
People don’t read
If your form is extremely simple, e.g. a newsletter sign-up, there is very little that can go wrong. But if things get slightly more complex, you need to make sure users enter the correct data into the respective input field. This can be done by adding additional information to a field.
The problem here is that many users will not read and skip right to the input field to enter whatever they think is appropriate. The problem can be alleviated by being as concise and unambiguous as possible when labelling a field. In some cases, you might be able to intercept wrong input data by using smart field validation (more on that later).
In general, the longer a form gets, the more likely something will go wrong and data ends up in the wrong field. Which brings me to the next point:
Forms can grow into monstrosities
From my experience, most forms start out fairly simple and straightforward but may end up becoming complex and frustrating.
Every time a new input is added to a form (because someone from the sales department really needs that additional piece of info) the complexity of the form grows non-linearly. For the reasons stated in this article, a form with eight input fields will probably be many times more complex than a form with only four input fields.
Therefore, any information that can be inferred or most certainly assumed (with mistakes being manageable), should not be asked from the user. Figuring out which fields are absolutely necessary can be a real hassle and can make certain stakeholders unhappy.
Forms (should) have a lot of rules
A good form takes care of you, while you fill it. It only shows you relevant information and tells you if the data you entered is invalid or does not make sense. This requires setting up rules. You might be surprised how quickly these rules add up. A form with eight form fields can easily have 20 to 30 rules that apply to various input combinations.
Keeping these rules manageable will probably require documentation. Otherwise, any future adjustments to said form will cause confusion, if existing rules are not taken into consideration.
You can easily lose your progress
If forms require the user to enter data that they don’t have at hand, e.g. an invoice number, you will have users pausing during the filling process.
Many things can happen at the moment when they found the piece of information and return to the form: They accidentally click on a link, leading them away from the form, they re-load the page or the user session has expired. If these cases are not handled carefully, the user might lose all their progress. It happened to all of us and is one of the most frustrating things, when filling forms.
While it’s technically possible to solve this by saving the form data before re-loading the form or by making a user session very long, this poses the risk of a privacy violation: Personal data of a user could be exposed to someone else who opens the same form at a later stage. A possible solution to this is to ask the user to confirm if they re-load the form or navigate away from the form and warn the user when the session is about to run out. But this can be annoying too, when the intention was to abort the filling process. The best solution here depends on the individual use case.
Auto-fill can be a curse
This probably sounds familiar: You start filling a form and your browser tries to help you by auto-filling fields. The browser then proceeds to overwrite some of the data you have already entered with some nonsense.
Getting auto-fill right can be really challenging and is sometimes straight up impossible: The options for telling a browser how to enter an address into an address fieldset are very limited, especially outside of the United States. The auto-fill functionality is heavily tailored towards US addresses.
Simply disabling auto-fill is also not a good option, especially on mobile devices. Having to enter all data manually on a phone screen can be a real hassle. Problems with auto-fill can be reduced by explicitly disabling auto-fill for fields, where it definitely does not make sense.
Localising forms can break the UX
Have you ever entered you address into a form and wondered why the address format is so strange? It is for the same reason that auto-fill does not work properly.
Every country has their own address format. There are some countries that don’t use zip codes and in other countries there are no street names. Here are some solutions, to this problem: Resort to “Address line 1”, “Address line 2”, “Address line 3” in your form and hope, that user enter meaningful data. Or build custom address fieldsets for every country. Another solution would be to mix both approaches: If 90% of your users are from the same country, add a fieldset that matches the format for that country and otherwise resort to the “Address-line-approach”.
The problem with localisation does not end here. Another example are names. In some countries, people have many first, middle and family names. In other countries, the family name comes before the “first” name. For the best UX, you should use a single field to enter the full name. But this can cause data management issues and people might be addressed wrongly by your CRM system if their names get mixed up.
Forms on mobile are extra difficult
Filling forms is a hassle - even more so when using a mobile phone. Input elements that work well on desktop, can be wonky on mobile. The on-screen keyboard of mobile phones can hide vital information when trying to enter data. It is also hard for the user to keep the overview when filling a mobile form. You need to make sure that people realise if they missed a required field when they click “Submit”. The best solution here is to scroll to the first error on the form.
Triggering field validation at the right time is impossible
You might have come across a form that has been spewing error messages at you, while you were typing. A common example is the email address input. You start typing your email address, and the form tells you “Wrong format! Email address must contain @!”.
This happens, because the field validation is triggered whenever you type or after a certain time has passed after typing the last character. This sounds like an illogical thing to do - but it does make sense in certain cases. Ask yourself, when is the right moment to tell a user that their input is wrong? Probably right after finishing their input, while still having the respective field focused, since that would make correcting the error easiest. But how to you know if the person finished typing? Most forms trigger the validation, after the respective field lost focus, or after no input has been provided for a certain amount of time or when the user clicks the “Submit” button. Which solution is best depends on the type of data and if the validation requires an asynchronous call to a service (e.g. to check if an invoice number exists within a system). Whatever solution you choose, there will be instances when the behaviour is going to be an annoyance to users.
There are many more thing that can make forms difficult to get right: Multiple validation errors, internet connection issues, accessibility for impaired users and cognitive load to name a few.
Some form solutions like Typeform try to avoid many form problems by having exactly one input element per form page. But this introduces other problems: Forms can get extremely long and it is impossible to scan over the data that was entered, since you will only see one field at a time. Speaking of which: Using a form builder like Typeform or Jotform will probably result in better forms than building them yourself. Not necessarily because of the technical implementation, but because form builders allow you to quickly iterate and test multiple versions of a form, make adjustments and small fixes without needing a developer and having to re-deploy.
The next time somebody tells you to “just build a small form” you might want to refer them to this article. :)
- Ellen Zimmermann11th July, 2022
Was ist eigentlich VBU.Labs?
Kundinnen und Kunden fragen, ob sie neue Features unserer App oder digitale Lösungen von anderen vorab testen wollen – macht da überhaupt jemand mit? Wir probierten es aus und gründeten VBU.Labs, die Testlabore einer gesetzlichen Krankenkasse.
- Sascha Kohlmann17th May, 2022
Going Open Source
At vbu.tech, we believe in the Public Money, Public Code paradigm, so we made our health insurance number library available to everyone.