Glossary / Inclusive language
Inclusive language
Inclusive language communicates respectfully and clearly across identities, abilities, cultures, and lived experiences. In software, it affects UI copy, error messages, documentation, data models, examples, and team terminology. The goal is not a universal banned-word list; it is to avoid needless assumptions or demeaning language, respect people’s self-identification, and use precise wording that helps users complete tasks.
Principles
- Describe the user’s task or system behavior rather than blaming the person: “We couldn’t save your changes” is more helpful than “You entered bad data.”
- Avoid assuming gender, family structure, nationality, literacy, ability, or access to a particular device or payment method. Ask only for data needed for the task.
- Respect identity language and user preference; terminology varies across communities and changes over time. Seek input from affected people and follow a product’s editorial guidance.
- Use person-first or identity-first language according to community and individual preference rather than forcing one rule on everyone.
- Write concise, concrete instructions. Avoid idioms, metaphors, jokes, and culturally specific references when they obscure meaning, especially in high-stakes flows.
- Avoid labels that stigmatize or imply that a person is the problem. Describe barriers and functional needs precisely.
- Inclusive copy must still be specific. Vague euphemisms can make errors, eligibility, or instructions harder to understand.
Engineering and governance
Create content guidelines with examples, review processes, and localization context. Make messages editable outside code and allow regional variation. Treat accessibility terminology as an evolving domain; consult people with disabilities and relevant organizations. Consider inclusive language in default values, gender fields, names, salutations, and validation rules. Do not make an optional demographic attribute mandatory without a clear purpose, and protect sensitive data appropriately.
Interview questions
- How do you make error messages more inclusive? State what happened and what the user can do, avoid blame, and preserve clear actionable guidance.
- Is person-first language always best? No; preferences differ by person and community. Follow the individual’s or community’s chosen terminology.
- How can data models create exclusion? Rigid assumptions about names, gender, family, address, or identity can block valid users or expose sensitive information.
- How do you handle terminology changes? Maintain editorial guidance, consult affected users, version content, and localize with context.
- What is the relationship between inclusive language and usability? Clear, respectful language reduces ambiguity and blame while supporting task completion.