In an HR product's content style guide, what does inclusive language cover, and how would you apply it to interface text?
answer
- nobody excluded by default
- gender-neutral defaults and singular 'they'
- metaphors that borrow from disability
- legal names versus policy names
- plain language helps everyone
basics
~10 sInclusive language is wording that does not exclude or stereotype people by gender, age, disability, culture or family: gender-neutral defaults, no loaded metaphors, no assumptions about names or families, and plain words.
solid answer
~50 sAn HR product describes every employee, so its defaults decide who feels written for. I apply inclusive language in a few areas. **Gender**: singular 'they' as the default, neutral role names such as 'chair', 'parental leave' rather than assuming who takes it. **Disability**: no metaphors like 'sanity check' or 'blind to', and no labels that define people by a condition. **Family and names**: 'partner' and 'dependant' rather than 'wife' and 'children', 'first name' rather than 'Christian name'. **Age and culture**: no 'young, energetic team', no idioms that do not travel. **Plain language**, which helps readers with cognitive disabilities and second-language readers. Where a law names a benefit, the legal name is used where it is required, with neutral wording for the wider policy. The style guide lists preferred and avoided terms with reasons, and the list is reviewed with the people it affects and updated as language changes.
go deeper
Use gender-neutral defaults such as singular 'they', avoid metaphors that borrow from disability, and follow the style guide's list of preferred terms.
Explain the areas inclusive language covers, why defaults in an HR product decide who feels included, and how plain language supports accessibility.
Show how you would handle a gendered legal term alongside a neutral policy name, and how you would review assumptions a word list cannot catch.
Weigh how to keep an inclusive-language standard current and credible across regions and cultures, and who should have a voice in changing it.
## What inclusive language covers **Inclusive language** is wording that does not exclude, stereotype or make assumptions about people because of gender, age, disability, ethnicity, religion, family structure or background. In a content style guide it becomes a list of preferred and avoided terms, each with a reason, plus principles for cases the list does not cover. | Area | Avoid | Prefer | Why | |---|---|---|---| | Gender | 'he or she', 'his/her', 'chairman' | singular 'they', 'chair' | Includes everyone without drawing attention | | Family | 'wife', 'mother', 'children' in forms | 'partner', 'parent', 'dependant' | Families take many shapes | | Names | 'Christian name', 'surname' as universal | 'first name' or 'given name', 'family name' | Naming conventions vary by culture | | Disability | 'sanity check', 'blind spot', 'crippled' | 'quick check', 'gap', 'broken' | Avoids borrowing conditions as metaphors | | Age | 'young, energetic team' | 'motivated team' | Avoids age-coded language | | Technical terms | 'blacklist', 'master/slave' | 'blocklist', 'primary/replica' | Avoids loaded metaphors | ## Why it matters in an HR product An HR and payroll product holds records for every employee in an organisation and speaks to people at sensitive moments - joining, parental leave, sickness, bereavement, leaving. A default that assumes a husband and wife, a mother taking leave or a Western naming order does not just sound dated; it tells a real employee, on a real form, that the system was not built for them. Because the product is used by employers, it also shapes how organisations talk to their staff. Inclusive defaults reduce support load too: a parent who cannot find where to add a second parent, or an employee whose name the form rejects, becomes a ticket and an HR workaround. ## Principles behind the list - **Default to neutral.** Use singular 'they' for an unknown person; most major style references now accept it. - **Describe roles, not identities.** 'The approver', 'the employee', 'the parent taking leave'. - **Do not borrow conditions as metaphors.** Words like 'sanity', 'blind', 'lame' and 'crazy' used figuratively turn people's conditions into shorthand for 'bad' or 'wrong'. - **Do not assume structure.** Names, families, genders and working patterns vary; copy should not presume one pattern. - **Use people's own terms.** When someone records a preferred name or pronouns, the product uses them everywhere it addresses or describes that person. - **Mention a characteristic only when relevant.** An error message rarely needs to reference anyone's age or gender. - **Prefer plain words.** Plain language is inclusive in itself: it helps readers with cognitive disabilities, readers in a second language and anyone reading under stress. ## When a legal term conflicts Payroll and HR law sometimes names benefits and categories in gendered or dated ways. The style guide should settle how to handle this: 1. **Use the legal name where it is required** - on a payslip line, in a statutory notice - because accuracy matters there. 2. **Use neutral wording for the wider policy** - 'parental leave' for a company policy open to all parents, even if one statutory component has a gendered name. 3. **Explain the relationship once** - 'Parental leave includes statutory maternity pay where it applies' - so users are not confused by two names. 4. **Record the decision in the glossary** so each team does not solve it again. ## Plain language and WCAG WCAG 2.2 includes 3.1.5 Reading Level at Level AAA: when text requires reading ability more advanced than the lower secondary education level, after removal of proper names and titles, supplemental content or a simpler version is available. Few products claim AAA conformance, but the criterion describes a sensible target for interface text, which should be understandable at a glance by anyone doing their job. ## Keeping the list current - **Review with the people affected**, through employee groups or research participants, rather than guessing what is respectful. - **Revisit the list periodically**; preferred terms change and a list frozen years ago can itself become exclusionary. - **Explain every entry** with a reason, so writers understand the principle and can handle new cases. - **Check strings automatically** for the avoided terms, while remembering that no list catches every assumption; review still matters. Inclusive language is not a list of forbidden words. It is the habit of asking, for each default, who it leaves out.
- A colleague says singular 'they' is grammatically wrong in interface text; how do you respond?Singular 'they' has long been used in English for a person whose gender is unknown or irrelevant, and major style references now accept it. It is shorter and clearer than 'he or she', and it includes people who use neither. In an HR product, where the system rarely knows or needs a person's gender, it is the natural default.
- Is an automated banned-terms check enough to make copy inclusive?No. A check catches known words such as 'blacklist' or 'chairman', which is useful, but most exclusion comes from assumptions - a form that expects two parents, a name field that assumes one family name. Those need review by people who think about who is left out, ideally with input from the people affected. The check is a floor, not the whole practice.
saying these in an interview costs you the question
- Inclusive language is a matter of politeness with no effect on usability.
- Using 'he' as a default is fine because it is grammatically generic.
- Singular 'they' is grammatically wrong and should be avoided in interface text.
- Once a list of avoided words exists, the work is finished.
- Plain language only matters for users with low literacy.