An event registration form has one job: turn interest into a confirmed seat with the least friction possible. Most of them do the opposite — they ask for a job title, a company size, and a dietary preference before the visitor has decided to come. Below is a lean Arabic registration template, ordered so the required fields come first and the optional ones never block the submit button.
Every field has a cost
This is the rule that should govern the whole form: each additional required field measurably lowers completion. The illustrative drop below is conservative — on mobile, in Arabic, with a phone field that misbehaves, the slope is steeper. Ask for what you need to confirm a seat; collect the rest at the event.
The template
| # | Field | Type | Required |
|---|---|---|---|
| 1 | Full name | Short text | Yes |
| 2 | Yes | ||
| 3 | Mobile number | Phone (with country code) | Yes |
| 4 | Organisation / role | Short text | No |
| 5 | Which sessions will you attend? | Multiple choice | No |
| 6 | Accessibility or dietary needs | Long text | No |
| 7 | I agree to be contacted about this event | Consent checkbox | Yes |
Confirm immediately
The moment of registration is the moment of highest intent. Send the confirmation email on submit, with the date, time, location (a map link, not just an address), and a calendar attachment. A registration the attendee cannot find in their inbox three weeks later is a no-show waiting to happen.
Consent is not optional, but it is honest
Field 7 is required because you genuinely need to email the attendee about the event — that is the legitimate purpose. What it must not do is bundle in marketing consent. If you want to add them to a newsletter, that is a second, separate, unticked checkbox. Bundling the two is the kind of dark pattern that reads badly and, under PDPL, does not count as valid consent for the marketing half.