Designing Long Forms and Applications
By CodexierPublished 5 min read
Long forms are unavoidable in some businesses: membership applications, insurance claims, supplier onboarding, detailed quote requests, patient intake. They are also where many potential customers give up. The good news is that length is rarely the real problem. People abandon forms that feel pointless, lose their input or punish small mistakes. This guide covers the design decisions that make a long form feel manageable, from questioning every field to explaining why you ask.
Question every field
Sit down with whoever uses the submitted data and go through the form field by field. For each, ask: what decision does this answer drive, and do we need it now? Fields that exist because the old paper form had them, or because someone might want the data one day, are the first to go. Under GDPR, data minimisation is also a legal principle, so fewer fields means less risk as well as less friction.
| Field type | Keep, move or remove |
|---|---|
| Needed to decide or deliver now | Keep |
| Needed only after approval or purchase | Move to a later step or follow-up |
| Available elsewhere, such as company data from the organisation number | Fetch automatically |
| Nice to know, no concrete use | Remove |
Steps and progress indicators
Breaking a form into steps makes each screen easier to finish and gives a sense of progress. Group questions by topic, such as about you, your company, your request and review. Put easy questions first to build momentum, and keep the most demanding ones, such as uploads or detailed descriptions, near the end when commitment is higher.
- Show step names, not just numbers, so people know what is coming.
- Make the progress indicator honest. Do not hide extra steps that appear later based on answers.
- Let people go back without losing input.
- End with a review screen where every answer can be edited before sending.
Saving and resuming
Long forms often need information people do not have at hand: an invoice number, a colleague's approval, a document to upload. If leaving means losing everything, many will not return. Save drafts automatically as people type. For logged-in users, store drafts on the server; for anonymous users, offer to send a resume link by email, or use BankID login when the form requires identification anyway.
Tell people clearly that their progress is saved, and how long drafts are kept. Delete abandoned drafts after a set period, since they contain personal data too.
Validation and errors
- Validate a field when the person leaves it, not on every keystroke and not only on submit.
- Accept common formats: personal identity numbers with or without the dash, phone numbers with spaces, postcodes with or without a space.
- Write errors that say what to do: enter the organisation number as ten digits, not invalid input.
- Place the error next to the field, and on submit move focus to the first error so screen reader users find it.
- Never clear the form because of one error.
Error messages are small pieces of writing with a big effect. Our guide to microcopy for buttons and errors has more examples, and accessible error handling is part of designing for WCAG 2.2.
Explaining why you ask
People hesitate at questions that feel intrusive: income, health, personal identity number, reasons for leaving a previous supplier. A short line of help text explaining why you ask and how the answer is used often removes that hesitation. It also helps you meet GDPR's transparency requirement right where the data is collected. If you cannot write a convincing reason, the question probably should not be there.
A product design sprint is a good format for redesigning a critical form: map it, prototype a new version and test it with real users within a short, fixed period. Prices are on the pricing page. When not to buy from us: if your form has a handful of fields and people complete it, it does not need a sprint; apply the checklist above yourself. If you are unsure, a free call will tell.
Frequently asked questions
Is one long page better than several steps?
For short forms, one page is fine. For long forms, steps usually work better because each screen feels achievable and progress is visible. What matters most is grouping related questions and letting people move back and forth freely.
Should we use BankID in forms?
When you need to verify identity or collect a personal identity number anyway, BankID can prefill name and number and reduce errors. For simple enquiries it adds an unnecessary step.
How do we know where people give up?
Track each step as an event in your analytics and look at where the drop is largest. Combine that with a few usability tests where you watch people fill in the form.
Are optional fields a good idea?
Sparingly. Every optional field still costs attention. If a field is truly optional, question whether it needs to be there at all, and mark optional fields rather than required ones when most are required.
Losing applicants or customers in a long form?
Send us the form and tell us where people drop off. In fifteen minutes we can point out the biggest problems and whether a design sprint would be worth it.
Book a free 15-minute call