Every event registration form is designed twice. Once at the start, when somebody lists what would be good to know, and once on the morning of the event, at the door, when it becomes obvious what was actually needed. The second design is always better than the first, and it always arrives too late to be used.
The way to get the second design first is to build the form backwards. Start at the check in desk, work out what has to be true on the list by then, and add only the fields that make it true. Everything else is optional, and most of it turns out to be unnecessary.
The fields that earn their place
For a single session event, the list is shorter than most people expect.
Full name, as one field. Splitting first and last name is a habit from database design, not from registration. It creates two taps instead of one, produces inconsistent capitalisation across two columns, and handles names from outside a narrow Western convention badly. One field labelled as the name to print on a badge collects what is needed and reads correctly on the badge.
Email address. This is the only genuinely load bearing field. Confirmation, reminders, room changes and the follow up all depend on it, and it doubles as the key that identifies a person across several forms. It is worth adding a confirmation step or a clear echo of the address on the confirmation screen, because a mistyped address is a registration that silently never hears anything.
Which session, date or ticket type. Only if there is more than one. A form for a single fixed event does not need to ask when the event is.
Anything that changes the arrangements on the day. Dietary requirements if food is served. Accessibility requirements if the venue has steps, or if materials might need to be provided differently. These two are not optional extras. They are the reason somebody either can or cannot attend comfortably, and they cannot be collected after the fact.
That is four fields at most, and for a free internal talk it is two.
Organisation name, and when it is real
Company or organisation is the borderline case. It earns its place when badges are printed with it, when the event is a trade gathering where people want to know who they are talking to, or when attendance is being reported back to a sponsor. It fails when it is collected because the marketing spreadsheet has a column for it. The distinction is whether anybody uses the value before or during the event.
Fields that look useful and are not
Phone number. Almost never called. It is usually justified as being for last minute changes, but last minute changes go out by email, because emailing three hundred people is a single action and calling them is not. If it is genuinely for a same day emergency, mark it optional and say what it is for.
Job title. Changes nothing about the event. It is a profiling field, and profiling fields belong in the post event survey, where an unanswered question costs nothing and a respondent who has already had a good experience is far more willing to answer.
How did you hear about this event. A reasonable question in the wrong place. On the registration form it adds a field and produces low quality answers, because people pick the first plausible option to get past it. In the follow up email, with no submit button depending on it, the answers are better and the cost is zero.
Postal address. Only if something is being posted. Collecting a home address for an event with no physical mailing is collecting sensitive data with no purpose, which creates a retention obligation and nothing else.
A catch all box asking whether there is anything else to mention. Sounds generous. In practice it produces a column that has to be read by a human, mostly contains nothing, and occasionally contains something critical buried in row 213 that nobody notices until afterwards. If there is a category of information that matters, ask for it directly.
The test that resolves all of these is the same one: if this field were blank for every registrant, would anything about the event be done differently?
Optional fields are not free either
A common compromise is to keep the questionable fields and mark them optional. This is better than requiring them, and it is not the same as removing them. An optional field still occupies screen space, still has to be read and skipped, and still lengthens the form in the only way that matters to somebody deciding whether to start it. On a phone, a form with four required fields and eight optional ones looks like a twelve field form, because the respondent cannot tell which is which until they are already scrolling.
Optional is the right setting for a field with a genuine but occasional consumer, such as an accessibility note. It is the wrong setting for a field kept because deleting it felt like a loss.
Dietary, accessibility and consent
These three deserve their own treatment because getting them wrong is more visible than getting anything else wrong.
Dietary requirements work better as a free text field than a set of checkboxes. Checkbox lists always miss something, and the person with the allergy that is not on the list is exactly the person whose answer matters. A short text field with a note that it will be passed to the caterer collects the real answer.
Accessibility requirements should be asked as an open question, phrased as an offer rather than an audit. Something along the lines of asking whether there is anything the organisers should arrange to make attending easier. This avoids requiring anyone to disclose a category about themselves while still surfacing the practical need, which is the only part that matters operationally.
Consent should be split. Agreeing to receive information about this event is not the same as agreeing to join a mailing list, and bundling them into one tick makes the second one worthless. Separate checkboxes, both unticked by default, with a link to the privacy notice next to them, is the arrangement that holds up. Photography consent is a third, separate thing, and it is better handled with a visible notice at the venue and an opt out than with a checkbox that most people tick without reading.
Multiple ticket types, sessions and group bookings
Complexity on registration forms comes almost entirely from these three cases, and each has a standard trap.
Ticket types with different prices or capacities need the selection to be a single choice with the capacity enforced, not a text field. If a session fills, the option needs to close, otherwise the form keeps taking registrations for a room that is full and somebody has to write apology emails afterwards.
Multi session events where an attendee picks a track need the choice recorded per person, not per booking. This sounds obvious and is routinely got wrong when one person books for three colleagues.
Group bookings are where forms break. The person filling in the form is often not an attendee. If the form collects one name and one email and a quantity, then on the day there are three unnamed places and a check in desk that cannot verify anyone. The two workable designs are either to collect each attendee's name and email as repeated fields, or to register the booker and send them a link to add names later. Both are more work than a quantity box. Both prevent the situation at the door.
| Situation | What to collect | The failure if not |
|---|---|---|
| One ticket type | Name, email | None |
| Several sessions | Choice per attendee | Wrong room lists |
| Capacity limits | Enforced single choice | Overbooked sessions |
| Group booking | Each attendee separately | Unnamed places at the door |
| Paid tickets | Payment state on the record | Manual reconciliation |
The confirmation email is part of the form
A registration is not complete when the submit button is pressed. It is complete when the registrant believes they have a place, and that belief comes from the confirmation.
A confirmation that arrives within seconds and repeats what was entered does three jobs at once. It reassures. It lets the registrant catch their own typo in the email address or the session choice, while there is still time to fix it. And it removes the most common inbound message an organiser receives, which is somebody asking whether their registration went through.
The confirmation should carry the date, the time, the venue with enough detail to actually find it, what to bring, and how to cancel. That last one matters more than it seems. If the only way to cancel is to write to an organiser, cancellations arrive as free text emails that have to be transcribed by hand, and transcription is where the attendee count stops being accurate. A cancellation route that updates the record directly is what keeps the number trustworthy.
This is also where the form tool's capabilities start to matter more than the editor. Sending a confirmation is common. Sending one that includes the person's own answers, and keeping a record of it against that registration, is less so.
Designing backwards from the check in desk
Here is the test that catches everything the field list misses. On the morning of the event, somebody stands at a desk with a phone or a laptop and needs to do exactly three things: find a person by name, confirm they are on the list, and mark them as arrived.
Work through what that requires. The list has to be current as of that minute, which rules out a printed sheet produced the night before, because every cancellation received that morning is invisible on it. It has to show confirmed attendees only, with cancellations and waitlist entries filtered out rather than mixed in. It has to be searchable by partial name, because people give their name in whatever form they use. It needs to be readable on a phone.
If producing that list involves an export, a manual filter, a deletion of cancelled rows and a print, then the process has a step that will be skipped under pressure, and the skipped step is always the one that matters. If the list is simply the live set of registrations filtered by status, there is nothing to skip.
Running that walkthrough before the form goes live usually changes two things about the form: it removes a field nobody uses at the desk, and it adds a status that nobody had thought to track.
What to change first
Take the registration form as it stands and delete every field that fails the blank test, then check whether a cancellation can be made without emailing a person. Those two changes do more for the day itself than anything else on the list. If the answer list still has to be exported and cleaned before the doors open, the gap is between the responses and the status attached to them, which is what Halict keeps on a single record.
Q1. What fields should an event registration form include?
Name, email address, the session or ticket type if there is more than one, and anything that changes the arrangements on the day, such as dietary or accessibility requirements. For a simple free event that is often just two fields.
Q2. Should first name and last name be separate fields?
Usually not. One name field is a single tap instead of two, produces consistent data for badges, and handles naming conventions from outside a narrow Western convention properly. Split them only when a system downstream genuinely requires the parts separately.
Q3. How should dietary requirements be collected?
As a short free text field rather than a checkbox list. Fixed lists always omit something, and the registrant whose requirement is missing from the list is precisely the one whose answer matters most to the caterer.
Q4. How should group bookings be handled on a registration form?
Collect each attendee's name and email, either as repeated fields on the same form or by sending the booker a link to add names afterwards. A quantity box produces unnamed places, which cannot be checked in and cannot be sent reminders.
Q5. What should the confirmation email contain?
The answers the registrant submitted, the date, the time, the venue in enough detail to find it, anything to bring, and a direct way to cancel. Repeating the answers lets people catch their own typos while there is still time to correct them.
Q6. How can the attendee list be kept accurate up to the day?
Give registrants a cancellation route that updates the record directly rather than sending an email to an organiser, and work from a live filtered list at the door rather than a print produced the night before. Both changes remove manual transcription, which is where counts drift.