Inclusive design teams: from pronouns to belonging

There’s a simple principle that’s held up well: a product reflects the culture of the team that built it. A team that treats each other with care shows up in more careful copy, in less invasive forms, in design decisions that catch cultural details before they ship.

A team that doesn’t treat each other with care also shows up. In sloppy microcopy, in invasive forms, in launched features that hurt someone. The product is the product, but it smells of culture.

This post lists practices I’ve seen work to build a team that does inclusive design by default, without needing a checklist for every decision.

Pronouns everywhere

The smallest thing that makes the biggest difference: pronouns visible in Slack, in meetings, in email signatures, in any internal tool.

It’s not a statement. It’s a gesture that normalises the importance of knowing how each person wants to be referred to. When everyone shows them, no one has to make a solo move. And when a new colleague joins, they see the signal before they have to ask.

Cost is zero. Effect compounds quietly.

”How do you want to be addressed?”

The question every team should make a habit of. Not just about pronouns:

• The name to use (I, at Talkdesk, prefer Ferrão to João)
• Pronunciation
• Form of address in meetings (formal, informal)
• How to receive feedback (in public, in private)
• Which channels and hours you’re available in

The first time this question enters a team, it feels strange. By the fifth time it’s habit. By the tenth, it’s culture.

Room to mess up

Everyone will mess up. Use the wrong pronoun. Make a clumsy comment. Forget something that had been asked.

What sets inclusive teams apart from teams that just talk about inclusion is how they react to mistakes:

Wrong: shame, defensiveness, ignoring. Right: acknowledge (“sorry, I got that wrong”), correct, move on.

The second pattern requires that the team doesn’t punish the mistake. If a slip is treated as a major failure, no one learns, everyone pretends to be perfect, and it weighs on everything.

The rule I follow: correct once, no drama. If the person repeats, talk in private. No more rituals than that.

Book club or weekly sharing slot

One of the most useful practices I had on a team: 30 minutes a week, someone shares something they’ve learned about inclusion, design, research, anything related.

Topics that came up on my team: dyslexia (a colleague has it, shared what it changes in design), neurodiversity, ageism, design for grief, gender archetypes in research, accessible facilitation.

It works because:

• Each person becomes temporary “expert” and gains confidence.
• The team learns without investing in formal courses.
• A common vocabulary builds.
• Inclusion stops being an HR topic and becomes part of the work.

Cost is half an hour a week. Return is high.

”We” instead of “I”

Small change in internal copy that shifts a lot. When someone presents work:

Wrong: “I designed this, I tested, I decided”. Right: “we designed this, we tested, we decided”.

Even if it was one person doing the work. Design doesn’t happen in a vacuum: research, PM, engineering, people who gave feedback. Acknowledging that in language builds belonging.

Real diversity, not decorative diversity

There are teams that talk about inclusion and where real diversity is zero. Same ages, same origins, same academic backgrounds. The blind spots are predictable.

Building diversity asks for hiring decisions:

• Diverse pipeline: source candidates from different places, not just the same portfolio cluster.
• Diverse interview panel: not just senior + manager, but varied profiles.
• Clear evaluation criteria: cognitive biases hurt more when criteria are vague.
• Careful onboarding: hiring isn’t enough; the person has to stay and grow.

The diversity in a team photo isn’t diversity. Real diversity shows up in the list of people who decide, who present, who speak loudly in meetings.

Conflict and disagreement

Inclusive teams aren’t teams where everyone agrees. They’re teams where everyone can disagree safely.

Practices:

• Disagree with the work, not the person. “This solution doesn’t convince me” is different from “you don’t get it”.
• Explicit permission to disagree with seniors. Echo chambers among seniors are toxic.
• Don’t decide under pressure. If there’s urgency, slowing down is almost always right.

The last one is one of the most important tips for any work environment. When we’re pressured, especially emotionally, we make decisions that aren’t our best. The brain goes on autopilot. The biases (covered in Cognitive biases explained) get more weight.

We aren’t experts

Probably the most important thing: no team is expert in inclusion. I’m not, my team wasn’t, no one fully is.

Accepting that changes how you work. Instead of pretending to know, we ask. Instead of assuming, we validate. Instead of reacting defensively when someone points out a flaw, we thank and adjust.

This humility is, ultimately, what separates a team that ships inclusive design from a team that ships exclusionary design with the aspiration of being inclusive.

Where to start this week

Three concrete steps:

1. Add pronouns to your profile. No statement. Just do it.
2. Ask three colleagues how they prefer to be addressed. Name, pronoun, feedback form.
3. Suggest a 30-min weekly book club. Start with a topic related to the product you build.

More on the background in the Inclusion and Diversity guide. On the cognitive biases that affect team decisions, see Cognitive biases explained. On how inclusive language flows naturally from a team that practises this, see Inclusive language in design.