Inclusive language in design

There are copy decisions we make without thinking. “Hi, make your choice.” “Invite your friend.” “Each user must fill in their data.” Innocent sentences, well-written even. But each picks a pronoun, a number, a person archetype. And anyone who doesn’t fit notices.

Inclusive language in design isn’t about policing words. It’s about choosing a more inclusive default and letting whoever prefers another form ask. This is the practical list I use day-to-day, plus the reasoning behind it.

Where language shows up

When you think about product copy, the instinct is to look at buttons and headlines. But inclusive language has to reach less obvious places:

Automated emails (“Welcome to…” vs. “Welcome, John”).
Interview scripts with users and customers.
Tooltips, error messages, help text.
Forms (especially gender, marital status labels).
Internal communication that shapes culture, and by extension the product.

Each one touches someone. The email is the most common complaint I hear: “it starts with ‘Dear’, but I don’t feel like that word is for me”.

Practical substitutions

The list below is simple and works across most contexts. Not exhaustive, but it covers 80% of cases:

boyfriend, girlfriend, wife, husband → partner, spouse
he/him, she/her (when you don’t know) → they/them
manpower → people power, staff, workforce
salesman → salesperson
chairman → chair, chairperson
guys (in a group) → everyone, folks, team
mailman → mail carrier
mankind → humanity, humankind
dear sir/madam (in email) → hello, good morning, the person’s name
male/female (radio buttons) → reconsider whether the question is needed; if it is, use self-describe or “prefer not to say”

The mental rule: when a word implies a gender, age, family status, or cultural marker, there’s almost always a version without that marker. And that version is nearly always equally clear.

The most subtle point: pronouns when describing groups

In product copy, you’ll write about “the user” a thousand times. The instinct is to default to “he” or “she”, or to alternate clumsily. The cleaner solution is “they”: singular, pronoun-neutral, grammatically correct in modern English.

“When the user signs in, they see…” reads well. It’s not awkward, it’s not academic. It’s just plain English now.

The special case of forms

Forms are where inclusive language fails most often. Gender gets asked with radio buttons “Male / Female” in forms where it never had to be there. “Husband / wife” gets asked in healthcare forms where “partner” would have done.

The rule I follow: before adding a question, ask whether it’s needed for the task. If not, drop it. If yes:

Make it optional wherever possible.
Offer “prefer not to say”.
Allow self-describe (free text input).

I go deeper in Inclusive forms: asking without excluding.

Language for describing people

Another subtle area. In research notes, personas, presentations:

“users” is technical but can depersonalise. “people” is more human but less precise. I use “people” in internal communication and “users” only when I need to distinguish from a non-user.
“the disabled”, “handicapped” → people with disabilities.
“the elderly” → older people, or people aged X.
“diabetics” → people with diabetes.

The rule: person first, condition second. “Person with dyslexia”, not “dyslexic”.

What this asks of your flow

Three concrete changes:

Run a pass through your templates. Emails, autoresponders, frequent error messages. Swap “he/she” for neutral, “husband/wife” for “partner” or “spouse”.
Create a copy review checklist. Before any string ships to production, run it through the checklist: gender, age, status, culture.
Ask someone different from you to review. You don’t have to be expert in every axis of inclusion. But you need people who are. Even a quick Slack DM works.

More on the background in the Inclusion and Diversity guide. On forms specifically, see Inclusive forms. On cultural sensitivity that intersects with word and symbol choice, see Cultural sensitivity in product design.