Inclusive forms: asking without excluding

There’s a pattern that repeats in nearly every form in the world: too much gets asked. It gets asked as required. It gets asked with binary options when the reality is continuous. The result is that people who don’t fit the form feel bad before they even reach the next page.

Most of this can be solved by design, without touching the product. This post lists the principles and patterns I use to build more inclusive forms.

The first rule: is the question even necessary?

Before adding any field, ask:

Is this information needed to deliver the service, or is it only “nice to have”?

If the answer is “nice to have”, drop it. If it’s “needed”, then move to the rest of this post. But most fields that exclude (gender, exact age, marital status, nationality) are “nice to have” and almost never truly required.

The exception: legal or clinical contexts where the info really matters. The bar shifts there, but the thinking is the same: justify before asking.

Transparency: why are you asking?

When you ask something sensitive, explain:

“We ask for your date of birth to verify legal age of use.”

Doesn’t have to be a paragraph. One short line below the field, or a tooltip. But it has to exist. The difference between “Date of birth *” and “Date of birth (needed for legal age verification)” is huge in terms of trust.

The rule: if the user doesn’t understand why they’re giving the info, they’ll leave, or they’ll give wrong info.

Make optional whenever you can

Most forms mark too many fields as required. Each red asterisk is a potential friction point.

Ask yourself: if this field came in empty, did you break the system? If not, it should be optional. Email for confirmation, yes required. Job title, optional. Company size, optional.

Making something optional isn’t giving up on the data. It’s trusting that whoever wants to share, will.

”Prefer not to say” as an option

For sensitive questions (gender, ethnicity, orientation, religion, immigration status), offering “prefer not to say” isn’t a nice-to-have. It’s an inclusive design requirement.

The person who prefers not to answer shouldn’t have to lie, leave it blank and risk validation errors, or abandon.

In practice:

• In select dropdowns, “Prefer not to say” as an option.
• In radio buttons, same.
• For required sensitive fields, offer a “Skip this field” button.

Self-describe: the free input that changes everything

For gender, identity, ethnicity, occupation, orientation, there’s always someone who doesn’t fit the pre-defined options. The classic “Other” is weak: what do I do if I’m “other”?

The better solution is free input:

Gender (optional):
( ) Woman
( ) Man
( ) Non-binary
( ) Other: _______________
( ) Prefer not to say

Free input lets the person describe themselves on their own terms. If you need to aggregate data, you can categorise internally, but the person feels seen.

The special case of names

Names are surprisingly complicated. There are forms that reject:

• Names with apostrophes (O’Connor)
• Names with hyphens (Sá-Pinto)
• Very short or very long names
• Non-Latin names
• Names with a single component (in some cultures)
• Names with more than two components (in Hispanic and Arabic cultures)

The safest rule: a single free name field. Not “first name” + “last name”. Just “Name”. Accept Unicode, any reasonable length (between 1 and 100), with any punctuation.

Gender: the most delicate case

If you really do need to ask gender (and in most contexts, you don’t), the recommended pattern is:

Gender (optional):
( ) Woman
( ) Man  
( ) Non-binary
( ) Prefer to describe: _______________
( ) Prefer not to say

The order can change, with no implicit hierarchy. Some teams alphabetise, others randomise, others start with “prefer not to say” to signal it’s a valid choice from the top.

Error messages

When something goes wrong on a form, the message matters.

Wrong: “Error: invalid data.” Better: “The email doesn’t look right. Check that you included @.” Even better: visually mark the field, keep the rest of the form filled, focus the wrong field.

And never, ever clear what the person already typed because of one wrong field.

Final checklist

Before any form ships, check:

1. Is each question needed for the task?
2. Do sensitive fields explain why?
3. Is there “prefer not to say” where applicable?
4. Is there self-describe where categories fall short?
5. Does the name field accept real-world variations?
6. Are error messages helpful and is form state preserved?
7. Does the form work without a mouse (keyboard only)?
8. Can a screen reader navigate it meaningfully?

More on the principles behind this in the Inclusion and Diversity guide. On inclusive language in labels and messages, see Inclusive language in design. On technical accessibility in forms (labels, ARIA, screen readers), see Accessibility beyond contrast.