Ines runs a small physiotherapy practice with one colleague and a part-time receptionist. Her website has an enquiry form, and for a while she was proud of it.
It asks for first name, last name, email, phone, date of birth, how you heard about the practice, preferred days, a dropdown of twenty-six conditions, and a box to “describe your injury in detail”. At the bottom: a pre-ticked box to receive the newsletter, and a button that says “Send”.
A man with a sore knee fills it in on his phone at a bus stop. He types his email with a stray space. He presses Send. The page reloads, the top now says “Your form contains errors”, and every field he typed is empty again.
He does not try twice. He calls the practice across the road.
Ines and her practice are imagined. The research, laws and court rulings below are real.
Every field has a price
We have a whole tip on the first cut: Cut your form in half covers how to decide which questions to ask now, which to ask later and which to delete. This chapter starts where that one stops. Once you know which fields stay, how do you label them, check them, explain errors, and stay on the right side of the law?
First, a story that shows how much a single field can matter, and why it is about more than counting boxes.
In 2010, ZDNet's Nick Heath reported a talk by Joe Megibow, then Expedia's vice president of global analytics and optimisation, at a SAS conference. Megibow said that some customers who clicked “Buy Now” were not completing their purchase. The cause was an optional field labelled “Company” under the name. Some customers entered their bank's name there, then entered the bank's address as their address. Card address checks failed. After the field was deleted, he said, the change was worth $12 million of profit a year.
No data or method were published, and the figure comes from Expedia's own description. What makes it useful is the mechanism: the problem was not the number of fields but one ambiguous, optional field that confused people into entering wrong data elsewhere.
Do this: for each remaining field, ask two questions. What will we do with this answer? And could anyone misunderstand what we are asking? A field that fails either test is a liability, even if it is optional.
Labels that stay put
The single most damaging form trend of the last decade is the disappearing label: grey placeholder text inside the box that vanishes when you start typing.
Katie Sherwin's NN/g article Placeholders in Form Fields Are Harmful lists the costs. Once you type, the hint is gone, so you have to remember what the field wanted. You cannot easily check your answers before sending. When an error appears, the instruction you need has vanished. Some people mistake placeholder text for a filled-in default and skip the field. Light grey placeholder text also tends to fail contrast checks, and some screen readers do not announce it.
WCAG 2.2 makes visible guidance a baseline: success criterion 3.3.2 Labels or Instructions (Level A) requires labels or instructions when content requires input. A real <label> above or beside each field meets it. A placeholder alone is a fragile way to try.
Above, or to the left?
A 2006 eye-tracking test by Matteo Penzo, published on UXmatters as Label Placement in Forms, is still quoted everywhere. He compared four short forms with four required fields and a dropdown. With left-aligned labels to the left of the fields, he reported eye movements between label and field of around 500 milliseconds. Right-aligning those labels roughly halved fixations and completion times. Labels placed above the fields produced the fastest movement, about 50 milliseconds.
Read Penzo's numbers with care. The article does not say how many people took part, the forms were tiny, some label texts differed between versions, and commenters, including the form specialist Caroline Jarrett, argued the findings do not carry over to long or complex forms. What survives the caveats is practical: labels above fields are quick to scan and work at any screen width, which is why most mobile-friendly forms use them.
Let the browser fill it in
The fastest field is one the visitor does not have to type. Success criterion 1.3.5 Identify Input Purpose (Level AA) requires that fields collecting information about the user have a purpose that software can determine. In practice that means the HTML autocomplete attribute: autocomplete="email", "tel", "given-name". It helps people with memory or motor impairments, and it lets every phone offer to fill the field. Use the right type too, such as type="email" or type="tel", so phones show the right keyboard.
Do this: give every field a visible label above it, keep placeholders for examples only, and add autocomplete and the correct input type to every personal-data field.
Choosing from a list
Ines's dropdown of twenty-six conditions brings in one of the best-known laws in interface design.
In choice-reaction experiments with up to ten alternatives, Hick found that reaction time grew with the logarithm of the number of equally likely choices: each doubling adds a roughly constant amount of time. Hyman showed that what matters is the amount of information in the choice, so likely options are picked faster than rare ones. Both studies used simple, well-practised tasks, such as pressing the key that matched a light.
The law is often misused as “fewer options are always faster”. Hick's participants knew every option in advance. A visitor opening an unfamiliar dropdown has to read through it, and reading a list takes time roughly in proportion to its length. Either way, the conclusion for a form is similar: long lists cost time, and the cost lands on the person who knows least about your categories.
Dropdowns have a second cost. Penzo noticed that in every one of his test forms, the dropdown drew the first fixation, ahead of even the submit button. A closed dropdown also hides its options, so people cannot see what is possible without opening it.
For a lead form, the patient knows they have a sore knee. They do not know whether your practice files that under “sports injury” or “joint pain”. A free-text question in their own words, such as “What would you like help with?”, is often easier to answer and more useful to read. When you do need a choice, show up to about five options as radio buttons, and order them by how often people pick them.
Do this: replace any dropdown that sorts people into your internal categories with a short free-text question, and turn short dropdowns into visible radio buttons.
When to check the answer
In 2009 Luke Wroblewski, author of the 2008 book Web Form Design: Filling in the Blanks, published a study he ran with the London usability firm Etre: Inline Validation in Web Forms, in A List Apart. Twenty-two people aged 21 to 49 used six versions of a registration form: one that checked answers only after submission, and five that gave feedback while people filled it in.
The best inline version beat the control on every measure. Just as interesting was the comparison between inline versions. Showing feedback after someone finished a field and moved on was seven to ten seconds faster than checking while they typed. Checking on every keystroke made people type one character, wait for the message to change, and type another.
Twenty-two people is a small sample, and this was a lab test of one registration form. The direction has held up in larger observational work, though. Baymard Institute's Edward Scott, in a 2024 summary of their checkout testing, reports that 31% of the sites in their benchmark lack inline validation, and describes participants frustrated by errors that appear too early. One tester asked why the site was telling him his email was wrong when he had not finished typing it. Baymard's advice: check most fields when the person leaves them, check fixed-length fields like card numbers once they are complete, remove an error as soon as it is fixed, and confirm valid answers.
A respectable dissent
The UK government's design system takes a different view. Its validation pattern says not to validate when a user moves away from a field, but to wait until they try to continue, and to avoid validating before someone has finished entering information, because it can cause problems for people who type slowly. Errors then appear together in a summary at the top, with the same wording next to each field.
The two approaches agree on more than they disagree. Neither shows errors while someone is still typing. Both keep what the person entered. Both explain each error next to the field. The real enemy is the version Ines had: a generic message after submission and a form wiped clean.
Fill in the form, make a mistake on purpose (try an email without the @), and press the button. Then switch versions and try again. Nothing is sent anywhere.
Do this: never clear a form after an error. Check fields after the person leaves them or when they submit, not while they type, and remove an error the moment it is fixed.
Errors that help
An error message has one job: get the person from stuck to finished with as little effort as possible.
NN/g's 2023 error-message guidelines by Tim Neusesser and Evan Sunwall boil this down to visibility, communication and efficiency. Put the message next to the field. Make it high-contrast and do not rely on color alone. Use plain language that says what went wrong and how to fix it, in a neutral tone that does not blame the user. Preserve what they typed. Their summary: good errors protect the user's effort and time.
Baymard's research shows how rarely sites do the specific part. In a 2023 article, Edward Scott reports that 98% of sites in their e-commerce benchmark use generic error messages, often one or two per field, so an empty email field and an email missing its domain get the same text. In testing, vague messages had some participants taking up to five minutes to fix simple errors, and some got completely stuck.
Generic
- Invalid input.
- Please enter a valid email.
- Phone number error.
- An error occurred.
Says something is wrong, not what or how to fix it.
Specific
- Enter your name.
- Your email is missing an @, like name@example.com.
- Your phone number is too short. Include the area code.
- We could not send this. Your answers are saved; try again.
Names the problem and the fix, in the visitor's words.
GOV.UK's error message component adds useful house rules: describe what happened and how to fix it, use direct instructions such as “Enter your first name” rather than “First name must have an entry”, and avoid words like “invalid”, “please”, “sorry” and “oops”. It also adds a visually hidden “Error:” prefix so screen-reader users hear immediately what the message is.
Two WCAG 2.2 criteria turn this into a standard. 3.3.1 Error Identification (Level A) requires that when an input error is detected automatically, the field is identified and the error is described in text. 3.3.3 Error Suggestion (Level AA) requires suggesting a correction when one is known, unless that would compromise security. WCAG 2.2 also added 3.3.7 Redundant Entry (Level A): information a person already entered in the same process must be filled in again for them or offered for selection, not demanded twice. Ines's form, which emptied itself, would fail the spirit of all three.
In the EU, these standards are increasingly more than good manners. The European Accessibility Act, Directive 2019/882, covers many consumer services provided after 28 June 2025, including e-commerce, though microenterprises providing services, meaning fewer than 10 people and an annual turnover or balance sheet of no more than €2 million, are exempt from its service requirements. For the wider picture, see Accessibility as conversion.
Do this: list every error your form can produce. Rewrite each as “what is wrong + how to fix it”, put it next to the field, and add an error summary at the top that links to each field.
The law of asking less
For anyone collecting personal data from people in the EU or UK, “every field must earn its place” is not just a usability slogan. It is close to the wording of the GDPR.
Article 5(1)(c), “data minimisation”, requires personal data to be “adequate, relevant and limited to what is necessary” for the purposes of processing. Article 25(2), data protection by default, requires measures ensuring that by default only data necessary for each specific purpose are processed, and says this applies to the amount of data collected. Breaching the Article 5 principles can bring fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher.
Source: Regulation (EU) 2016/679, Arts. 5, 25 and 83(5). General information, not legal advice; check your own jurisdiction.
Every field also needs a lawful basis under Article 6. For an enquiry form, the usual basis is that processing is necessary “to take steps at the request of the data subject prior to entering into a contract”: they asked for a quote or an appointment, you need their email to reply. That basis covers what is needed for the reply. It does not cover “how did you hear about us?” or a date of birth you never use.
Article 13 adds a transparency duty at the moment of collection: who you are, what the data is for, the legal basis, who receives it, how long you keep it, and the person's rights. A short line next to the button with a link to the full notice is the common way to meet it on a small form: “We use these details only to reply to your enquiry. Privacy notice.”, with the last two words linking to the full notice.
| Field | What we do with it | Basis and notes | Decision |
|---|---|---|---|
| Name, email | Reply to the enquiry | Steps at the person's request (Art. 6(1)(b)) | Keep |
| Phone | Call back, if they want one | Optional, with a reason beside it | Optional |
| What would you like help with? | Choose the right appointment | Free text; may reveal health data, see below | Keep, reword |
| Date of birth | Nothing at enquiry stage | Not necessary for a reply (Art. 5(1)(c)) | Ask later or never |
| How did you hear about us? | Marketing reports | Not needed to reply; ask after booking, optionally | Move |
| 26-item conditions list | Internal sorting | Special category data collected up front | Delete |
| Newsletter box | Marketing email | Needs separate, unticked consent | Fix |
Health, beliefs and other special categories
Ines's injury box is where small businesses most often wander into the strictest part of the GDPR without noticing.
Processing data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used to identify someone, data concerning health, or data concerning a person's sex life or sexual orientation is prohibited unless one of the exceptions in Article 9(2) applies, such as explicit consent. Health practices, therapists, clinics and coaches meet this quickly.
Source: Regulation (EU) 2016/679, Art. 9. Not legal advice; health providers usually have specific national rules too.
The practical answer is usually to ask for less detail up front. “Briefly, what would you like help with? You do not need to share medical details here; we will talk about them at your appointment.” If you do need health details before the first visit, get advice on the right exception, secure the form and the inbox it lands in, and say clearly why you ask.
Do this: write the purpose and lawful basis next to every field in a spreadsheet. Delete what has none. Add a one-line privacy statement with a link beside the button.
Consent and marketing, done properly
The pre-ticked newsletter box at the bottom of Ines's form is a classic, and it is not valid consent in the EU.
Recital 32 states that “silence, pre-ticked boxes or inactivity should not” constitute consent. Article 7(2) requires a consent request to be clearly distinguishable from other matters; 7(3) says withdrawing must be as easy as giving consent; and 7(4) says that making a service conditional on consent to unnecessary processing counts against consent being freely given. In Planet49, judgment of 1 October 2019, the Court of Justice ruled that a pre-ticked checkbox, which the user had to untick to refuse, does not give valid consent.
Sources: Regulation (EU) 2016/679; Case C-673/17. Not legal advice.
Not valid consent
Ticked by default, bundled, and a condition of getting a reply.
Separate and optional
The reply does not depend on the newsletter. The person chooses.
For marketing email, the EU's ePrivacy Directive adds its own rule. Article 13(1) of Directive 2002/58/EC allows email direct marketing only to people who have given prior consent. Article 13(2) carves out the so-called soft opt-in: a business that obtained a customer's email address in the context of a sale may market its own similar products, provided the customer is clearly given an easy, free way to object when the address is collected and in every message. A first enquiry is usually not a sale, so most lead forms need consent for marketing. National implementations differ, so check yours.
In the US, the CAN-SPAM Act works the other way round: it does not require prior consent for commercial email, but it requires accurate headers and subject lines, identification as an ad, a valid physical postal address, a clear way to opt out, and honoring opt-outs within 10 business days. The FTC's guide lists penalties of up to $53,088 per violating email, a figure adjusted for inflation.
Being strict here costs fewer leads than people fear. The enquiry is the conversion. A newsletter sign-up that someone chose is worth more than one they did not notice. For what to say after the form is sent, see Thank-you pages and next steps.
Do this: untick every marketing box, separate it from the enquiry, make it optional, and describe what people will actually receive.
What to change tomorrow
Audit every field twice
Once for effort and clarity, once for purpose and lawful basis. Delete or postpone anything that fails either. Remove ambiguous optional fields, like Expedia's “Company”.
Put real labels above fields
Visible
<label>elements, placeholders only for examples,autocompleteand correct input types on personal data.Swap long dropdowns
Use free text for “what do you need?” and radio buttons for short choices.
Never wipe the form
Keep every answer after an error. Validate after a field is completed or on submit, never mid-typing, and clear errors as soon as they are fixed.
Rewrite every error message
Next to the field, specific, “what is wrong + how to fix it”, plus a linked summary at the top.
Add the privacy line
One sentence next to the button on what you do with the data, linking to your notice (GDPR Art. 13).
Fix marketing consent
Unticked, separate, optional, specific. Check ePrivacy rules for your country, or CAN-SPAM for US recipients.
Handle sensitive data deliberately
If your service touches health or other special categories, ask for less up front and get advice on Article 9.
Ines's new form has three required fields, an optional phone number with a reason beside it, and a question about what hurts that tells people not to send medical details yet. When the man with the sore knee mistypes his email now, the form tells him there is a space in it, and keeps everything else.
What the research supports
The case for inline validation rests on one small lab study (22 participants, Wroblewski and Etre, 2009) and on Baymard's large-scale usability observations, while GOV.UK's design system recommends validating on submit; they agree on not interrupting typing, keeping input and specific messages. Label placement evidence is thin: Penzo's 2006 test was small and simple. The Hick–Hyman law is robust for practised choices and only loosely applies to unfamiliar lists. The Expedia figure is a company anecdote. The legal requirements are in force where stated.
Sources
- Heath, N. (2010). Expedia on how one extra data field can cost $12m. ZDNet, 1 November 2010. Report of Joe Megibow's conference talk consulted.
- Wroblewski, L. (2008). Web Form Design: Filling in the Blanks. Rosenfeld Media. Bibliographic details checked.
- Wroblewski, L. (2009). Inline Validation in Web Forms. A List Apart, issue 291. Study design, sample and results consulted.
- Penzo, M. (2006). Label Placement in Forms. UXmatters. Method, reported timings, limitations and reader comments consulted.
- Sherwin, K. (2014). Placeholders in Form Fields Are Harmful. Nielsen Norman Group. Guidance consulted.
- Neusesser, T. & Sunwall, E. (2023). Error-Message Guidelines. Nielsen Norman Group. Guidelines consulted.
- Scott, E. (2024). Usability Testing of Inline Form Validation. Baymard Institute. Benchmark figure, observations and recommendations consulted.
- Scott, E. (2023). How to Improve Validation Errors. Baymard Institute. Benchmark figure and test observations consulted.
- GOV.UK Design System. Validation and Error message. Guidance on timing and wording consulted.
- Hick, W. E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4(1), 11–26. Abstract consulted.
- Hyman, R. (1953). Stimulus information as a determinant of reaction time. Journal of Experimental Psychology, 45(3), 188–196. Opening of the paper consulted.
- W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2. Success criteria 1.3.5, 3.3.1, 3.3.2, 3.3.3 and 3.3.7 consulted.
- European Parliament and Council (2016). Regulation (EU) 2016/679 (GDPR). Articles 5, 6, 7, 9, 13, 25, 83 and Recital 32 consulted.
- Court of Justice of the EU (2019). Case C-673/17, Planet49 GmbH, judgment of 1 October 2019. Facts and operative part consulted.
- European Parliament and Council (2002). Directive 2002/58/EC (ePrivacy Directive), consolidated. Article 13 consulted.
- European Parliament and Council (2019). Directive (EU) 2019/882 (European Accessibility Act). Scope, Art. 3(23) and Art. 4(5) consulted.
- Federal Trade Commission. CAN-SPAM Act: A Compliance Guide for Business. Requirements and penalty figure consulted.
Sources checked 18 October 2026. Legal sections are general information, not legal advice; check the rules in your own jurisdiction and with a qualified adviser. The physiotherapy practice and all form mock-ups are fictional; the figures are original illustrations.