How do you design a registration form that does not create work later?
By Donghui Qian (Milo)Updated 19 September 20264 min read
Short answer
Keep only the fields that decide identity, entitlement or price, each tied to a decision and a named owner, and move operational questions such as dietary needs to a follow-up after confirmation. Branch with conditional logic instead of adding fields for everyone, and treat any answer that can reveal health or belief as data you must protect and delete.
A registration form is the one part of an event that every single attendee touches. It is also where teams quietly create three months of work for themselves, one reasonable-sounding field at a time.
This is a field guide to deciding what goes on the form. It applies to any registration tool, ours included.
What the form is actually for
Two answers, and everything else is optional: who is this person, and what are they entitled to? Name and a contact route answer the first. Ticket type, session choices and any approval answer the second.
Anything beyond those two exists to serve a decision someone will make later — catering numbers, badge printing, a sponsor report. If you cannot name the decision and the person who makes it, the field is not earning its place.
Every field is paid for three times
| Who pays | When | What it costs |
|---|---|---|
| The attendee | At registration | Attention, and a reason to abandon the form — especially on a phone, where every extra field is another scroll |
| Your team | In the weeks after | Cleaning it. Free-text fields arrive in six formats and someone normalises them by hand before they are usable |
| Whoever is responsible for the data | Until it is deleted | It has to be stored, secured, disclosed in the privacy notice, and deleted on request — including the answers nobody ever used |
The third cost is the one that is invisible when the form is designed and undeniable when someone asks for their data.
Ask at the right moment, not all at once
Most of what teams put on the registration form does not have to be there. Three moments, three different jobs:
- At registration
- Only what decides entitlement or confirmation: identity, contact, ticket type, approval answers, and anything the price depends on.
- After confirmation
- Anything operational that can change: dietary needs, accessibility requirements, session choices, badge spelling. Ask in a follow-up that the attendee can revisit.
- Never on the form
- Anything you will not act on. A question whose answer changes nothing is a liability with a text box around it.
Moving a question later also improves the answer. Dietary needs asked four months out are guesses; asked two weeks out they are usable by a caterer.
Branch instead of adding
When a question applies to some people, conditional logic beats a longer form for everyone. Three branches carry most events:
- By ticket type. Speaker and exhibitor registrations need things an attendee ticket does not. Do not put those fields in front of the other ninety percent.
- By an answer already given. "Attending the dinner" opens the dietary question; "no" closes it and everything under it.
- By who is paying. A company buying for a delegate needs billing details and a purchase order reference; an individual paying by card does not.
A branch that hides four fields from most registrants is worth more than any amount of visual tidying of a long form.
The fields that cause the most cleanup
| Field | What goes wrong | Better |
|---|---|---|
| Job title, free text | Hundreds of spellings of the same five roles, useless for segmentation | A short list plus "other", if you will actually segment by it |
| Company name, free text | One organisation arrives as six variants and the sponsor report double-counts | Accept it, but normalise before reporting — or match against a list for invited audiences |
| Phone number | Collected by habit, rarely used, stored forever in fifteen formats | Ask only if someone will genuinely call, and store the country code |
| Badge name | Assumed to equal the legal name, then corrected by hand at the desk | A separate, optional field with the printed length shown |
| "Anything else we should know?" | A free-text field nobody has time to read, holding the occasional serious request | Either assign an owner who reads every answer, or remove it |
The compliance line
Two of the most common questions on event forms are treated differently by data protection law in the EEA and the UK: dietary requirements and accessibility needs can reveal health or belief, which GDPR treats as special category data with a higher bar.
- Collect them only when someone will act on them, and say at the point of collection who will see them.
- Keep them out of general exports and sponsor reports; they belong to catering and to the on-site team, not to the attendee list.
- Delete them once the event is over, on a schedule you wrote down before the event, not when someone asks.
- Whether your lawful basis is consent or something else is a question for your own counsel — this guide will not answer it for you.
The same principle covers the rest of the form: every question you ask becomes something you must be able to explain, produce, and erase.
Before you publish
Run the form once as an attendee, on a phone, with the payment step live in test mode. Then check five things:
- Every field maps to a decision, and you can name who makes it.
- Required fields are the ones that block confirmation — nothing else.
- Someone owns each free-text field, or it is gone.
- The confirmation email says what happens next, including whether approval is pending.
- You can export the whole thing — answers included — without asking anyone for help.
Frequently asked questions
There is no universal number, and any figure quoted without your context is invented. The working rule is that each field must map to a decision someone will make, with a named owner: identity and contact, what the person is entitled to, and anything the price or approval depends on. Everything else moves to a follow-up after confirmation.
Usually not at registration. Ask after confirmation, closer to the event, when the answer is accurate and the caterer can still use it. In the EEA and the UK these answers can reveal health or belief, which GDPR treats as special category data, so collect them only if someone will act on them, restrict who sees them, and delete them on a schedule you set in advance.
Showing a question only when it applies — by ticket type, by a previous answer, or by who is paying. It keeps the form short for the majority while still collecting what speakers, exhibitors or company buyers need, which is more effective than shortening a form everyone has to read.
Yes, if badges are printed. Legal name and the name someone wants on a badge are often different, and the difference is otherwise discovered at the desk and corrected by hand. Make it optional, default it to the given name, and show the length that will actually print.