Form design best practices: a practical checklist
Well-designed forms share a few traits: a single column layout, labels above each field (never placeholder-only), the right field type for each answer, inline error messages that say exactly what's wrong, and thumb-friendly controls on mobile. Mark only truly required fields, group related fields together, and name the submit button after its outcome. Below is each rule with examples, plus a checklist to run before you launch.
Form design isn't decoration — it's whether people can fill the form out quickly and correctly. A handful of practical rules cover most of the wins. This guide goes lever by lever (layout, labels, field types, error handling, mobile), shows good versus bad examples, and ends with a checklist you can run against any form before it ships.
Layout: one column, logical order
- Use a single column. Multi-column forms cause people to skip fields or read them in the wrong order. The exception is short, obviously paired fields like City and ZIP.
- Order fields the way people think: easy and expected first, sensitive last.
- Group related fields together (contact details, then preferences, then consent) with a little visual separation.
- Give fields room to breathe — cramped forms feel harder than they are.
- Keep the submit button reachable; on long forms, consider splitting into steps.
Labels: above the field, always visible
Labels are how people know what to type. The biggest, most common mistake is using placeholder text as the only label.
| Practice | Do this | Not this |
|---|---|---|
| Label position | Label above the field, always visible | Label only as placeholder text |
| Placeholder use | An example or hint ('e.g. jane@company.com') | The field's name, which vanishes on typing |
| Required marker | Mark required fields clearly, or mark optional ones | Leave people guessing what's required |
| Wording | Plain, specific ('Work email') | Jargon or ambiguous ('Identifier') |
Placeholder-only labels disappear the moment someone starts typing, so they lose track of what the field was — and screen readers handle them poorly. Keep a real label above every field.
Field types: match the type to the answer
The right field type prevents bad data and triggers the right keyboard on mobile. Don't make people type what they could tap.
| You're collecting... | Use this field type |
|---|---|
| An email address | Email field (validates format, @ keyboard on mobile) |
| A phone number | Phone field (number pad on mobile) |
| A choice of one option | Multiple choice or dropdown |
| A choice of several | Checkboxes |
| A number or quantity | Number field (digit pad, no 'two-ish') |
| A date | Date picker (no ambiguous 03/04 formats) |
| A rating or score | Rating, NPS, or star field |
| A long explanation | Long text |
| A file or document | File upload |
| Agreement / consent | Consent checkbox |
A builder with many field types makes this easy — Formkii offers 18, so there's a purpose-built field for almost any answer rather than forcing everything through a text box.
Use a dropdown or multiple choice anywhere there's a fixed set of answers. A short text field for 'Which plan?' gets you 'pro', 'Pro plan', and 'the middle one'; a dropdown gets you clean, comparable data with zero cleanup.
Error handling: inline, specific, kind
- Validate inline, as people leave a field — not only after they hit submit.
- Put the error next to the field it belongs to, not in a banner they have to scroll to find.
- Be specific: 'That email is missing an @' beats 'Invalid input'.
- Be kind in tone — the person made a typo, not a crime.
- Don't clear the field's contents on error; let them fix, not retype.
- Confirm success clearly so people know the form went through.
Mobile: thumb-friendly by default
- Full-width fields and buttons sized for thumbs, with generous spacing.
- Typed fields so the right keyboard appears (email, number, phone).
- No tiny tap targets crammed side by side.
- Avoid huge dropdowns; break long option lists into clearer choices.
- Test on a real phone, including the submit button and any error states.
Required fields and the submit button
- Mark only the fields you truly need as required. Optional fields like 'How did you hear about us?' should never block submission.
- If most fields are required, mark the optional ones instead — whichever is less cluttered.
- Name the submit button after the outcome: 'Get my quote', 'Send feedback', 'Reserve my seat' — not a generic 'Submit'.
- Set expectations up front: a welcome line like 'Takes about 1 minute' or 'Just 5 questions'.
Common form design mistakes
- Placeholder text used as the only label.
- Everything marked required, including optional comments.
- A short text field where a dropdown or date picker belongs.
- Errors that appear only after submit, in a banner far from the field.
- Multi-column layouts that make people skip or misread fields.
- A generic 'Submit' button that doesn't say what happens next.
- Never testing on a phone, where much of the traffic lives.
The pre-launch form design checklist
- Single column layout, fields in a logical order, related fields grouped.
- A visible label above every field; placeholders are hints, not labels.
- Each field uses the type that matches its answer (email, number, date, choice).
- Only essential fields are required; optional ones are clearly optional.
- Validation is inline, specific, and shown next to the field.
- The form is thumb-friendly and tested on a real phone.
- The submit button names the outcome.
- A clear confirmation or thank-you screen follows submission.
Frequently asked questions
What are the most important form design best practices?
Use a single column layout, keep a visible label above every field, match each field type to its answer, validate errors inline with specific messages, and make everything thumb-friendly on mobile. Mark only truly required fields and name the submit button after its outcome.
Should form labels go above or beside the field?
Above the field is the safest default — it reads well in a single column, works on narrow mobile screens, and stays visible while typing. The one thing to avoid is using placeholder text as the only label, since it disappears the moment someone starts typing.
How should forms handle errors?
Validate inline as people leave each field rather than only on submit, and show the error right next to the field it belongs to. Use specific, friendly wording like 'That email is missing an @' instead of 'Invalid input', and never clear what the person already typed.
Why does field type matter in form design?
The right field type prevents bad data and triggers the correct mobile keyboard — an email field validates format, a number field blocks non-numeric answers, a date picker avoids ambiguous formats. Using dropdowns and choices instead of free text also keeps answers clean and comparable.