Linguagem inclusiva no design

Há decisões de copy que fazemos sem pensar. “Olá, faz a tua escolha.” “Convida o teu amigo.” “Cada utilizador deve preencher os seus dados.” São frases inocentes, e até bem escritas. Mas escolhem um pronome, um número, um arquétipo de pessoa. E quem não cabe nesse arquétipo nota.

Linguagem inclusiva no design não é sobre policiar palavras. É sobre escolher um default mais inclusivo, e deixar quem prefere outra forma pedir. Esta é a lista prática que uso no dia a dia, e o raciocínio por trás dela.

Onde a linguagem aparece

Quando pensas em copy de produto, o instinto é olhar para os botões e títulos. Mas a linguagem inclusiva tem de chegar a sítios menos óbvios:

• Emails automáticos (“Bem-vindo ao…” vs. “Bem-vindo, John”).
• Scripts de entrevista com utilizadores e clientes.
• Tooltips, mensagens de erro, texto de help.
• Formulários (especialmente labels de género, estado civil, etc.).
• Comunicação interna que afeta a cultura, e por consequência o produto.

Cada um destes pontos toca em alguém. O email errado é o que mais vezes ouvi: “começa com ‘Caro’, mas eu não me sinto incluído nessa palavra”.

Substituições práticas

A lista abaixo é simples e funciona em PT-PT, PT-BR e EN. Não é exaustiva, mas resolve 80% dos casos:

• boyfriend, girlfriend, wife, husband → partner, spouse
• he/him, she/her (quando não sabes) → they/them
• ele/ela (em formulário ou copy genérico) → a pessoa, quem, ou pronome neutro
• manpower → people power, staff, workforce, equipa
• salesman → salesperson
• chairman → chair, chairperson
• guys (em grupo) → everyone, folks, pessoal, equipa
• mailman → mail carrier
• mankind → humanity, humankind
• caro/a, querido/a (em email) → olá, bom dia, bem-vindo/a (sem “/a” se possível)
• homem/mulher (radio buttons) → repensa se a pergunta é necessária; se for, usar self-describe ou “prefiro não dizer”

A regra mental por trás: quando uma palavra implica um género, idade, estatuto familiar ou cultural, há provavelmente uma versão sem essa marca. E essa versão é, quase sempre, igualmente clara.

O ponto mais delicado: o “tu” vs. “vós” em PT-PT

Em português europeu, o tratamento por “tu” é íntimo, “você” é formal. Em inglês, o “you” cobre os dois sem ambiguidade. Em produtos digitais, isto força uma escolha de tom.

A maior parte dos produtos modernos opta por “tu”, mais próximo, menos hierárquico. Funciona bem para a maioria. Mas em produtos de saúde, finanças ou serviços públicos, “tu” pode soar invasivo. Aí “você” funciona melhor, mesmo que pareça mais distante.

A escolha é editorial, não há regra. Mas vale a pena ser consistente: se escolhes “tu” no produto, mantém em todos os pontos de contacto. Misturar é o que mais soa errado.

O caso especial dos formulários

Os formulários são o sítio onde a linguagem inclusiva mais falha. Pergunta-se género com radio buttons “Masculino / Feminino” em formulários onde nunca seria necessário. Pergunta-se “marido / esposa” em formulários de saúde quando “parceiro/a” cobria.

A regra que sigo: antes de adicionar uma pergunta, perguntar se ela é necessária para a tarefa. Se não for, fora. Se for, então:

1. Tornar opcional sempre que possível.
2. Oferecer “prefiro não dizer”.
3. Permitir self-describe (input de texto).

Aprofundo isto em Formulários inclusivos: perguntar sem excluir.

Linguagem para descrever pessoas

Outra área subtil. Em research notes, em personas, em apresentações:

• “users” é técnico mas pode despersonalizar. “pessoas” é mais humano mas menos preciso. Uso “pessoas” em comunicação interna e “utilizadores” só quando preciso de distinguir do não-utilizador.
• “deficientes”, “portadores de” → pessoas com deficiência (people with disabilities).
• “idosos” → pessoas mais velhas, ou pessoas com X anos.
• “diabéticos” → pessoas com diabetes.

A regra: a pessoa primeiro, a condição depois. “Pessoa com dislexia”, não “disléxico”.

O que isto pede do teu fluxo

Três mudanças concretas:

1. Faz um pass aos templates. Emails, autoresponders, mensagens de erro frequentes. Substitui “ele/ela” por neutro, “marido/esposa” por “parceiro/a” ou “spouse”.
2. Cria uma checklist de copy review. Antes de qualquer string ir para produção, passar pela checklist: género, idade, estatuto, cultura.
3. Pede review a uma pessoa diferente de ti. Não tens de ser expert em cada eixo de inclusão. Mas precisas de pessoas que sejam. Mesmo se for por mensagem direta no Slack.

Mais sobre o pano de fundo no guia Inclusão e Diversidade. Sobre formulários especificamente, ver Formulários inclusivos. Sobre a sensibilidade cultural que se cruza com escolha de palavras (e símbolos), ver Sensibilidade cultural no design de produto.