Vocabulário do usuário e padrões de nomenclatura

Vocabulário do usuário é o conjunto de palavras, expressões e referências que as pessoas realmente usam para descrever tarefas, objetos e resultados no seu contexto. Em microcopy, isso se traduz em escolher termos que o usuário reconhece imediatamente, sem precisar “traduzir” mentalmente jargões internos, nomes de features, siglas ou categorias criadas pela empresa. Padrões de nomenclatura são as regras que mantêm esses termos consistentes ao longo do produto: o mesmo conceito recebe o mesmo nome, com a mesma forma (singular/plural), o mesmo verbo, a mesma capitalização e o mesmo nível de especificidade em botões, menus, telas, mensagens de erro e ajuda.

Quando o vocabulário do usuário e os padrões de nomenclatura estão bem definidos, o produto reduz atrito cognitivo: a pessoa encontra o que procura mais rápido, entende o que vai acontecer antes de clicar e se orienta melhor ao voltar para uma tela. Quando estão mal definidos, surgem sintomas comuns: termos diferentes para a mesma coisa (“pedido” vs “compra”), o mesmo termo para coisas diferentes (“conta” como login e como conta bancária), labels que parecem internos (“entidade”, “instância”), e ações que não batem com o que o usuário espera (“processar”, “executar”).

O que significa “falar a língua do usuário” na prática

Não é apenas usar palavras “simples”. É usar palavras que são familiares no domínio do usuário e que correspondem ao modelo mental dele. Um contador pode achar “competência” natural; um usuário comum pode entender melhor “mês de referência”. Um time de logística pode falar “romaneio”; um cliente final pode entender “lista de entrega”.

Também envolve escolher o nível certo de especificidade. “Documento” pode ser genérico demais se o usuário procura “nota fiscal”. “Pagamento” pode ser vago se o usuário precisa “pagar boleto” ou “pagar com cartão”. A nomenclatura deve refletir como a pessoa decide e age.

Três fontes de desalinhamento comuns

• Jargão interno: termos do time (ex.: “pipeline”, “lead qualificado”, “SKU master”) viram labels sem validação.
• Termos legais/técnicos sem mediação: “inadimplemento”, “autenticação multifator” aparecem onde o usuário esperaria “pagamento em atraso” e “verificação em duas etapas”.
• Marketing vs uso real: nome promocional da feature (“Turbo Checkout”) substitui o termo que descreve a tarefa (“Finalizar compra mais rápido”).

Padrões de nomenclatura: o que padronizar (e por quê)

Padronizar não é “engessar”; é reduzir variação desnecessária. Em interfaces, variação custa atenção. O objetivo é que o usuário reconheça padrões e não precise reaprender a cada tela.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

1) Nome de objetos (substantivos)

Defina como o produto chama as principais “coisas” com que o usuário lida: itens, registros, documentos, pessoas, espaços, planos, permissões. Para cada objeto, registre:

• Termo preferido: o nome principal (ex.: “Pedido”).
• Sinônimos proibidos: termos que não devem aparecer (ex.: “Compra”, “Ordem”).
• Escopo: o que entra e o que não entra nesse termo (ex.: “Pedido” inclui pedidos em rascunho? inclui orçamento?).
• Forma: singular/plural e capitalização (ex.: “pedido” em texto corrido; “Pedidos” como título de menu).

2) Nome de ações (verbos)

Verbos precisam ser consistentes e descrever o efeito real. Padronize:

• Verbo por intenção: “Criar” vs “Adicionar” vs “Novo”.
• Verbo por etapa: “Salvar” (persistir), “Enviar” (submeter), “Publicar” (tornar visível), “Agendar” (executar no futuro).
• Verbo por reversão: “Desfazer”, “Cancelar”, “Excluir”, “Arquivar” (não são equivalentes).

Exemplo de inconsistência comum: em uma tela o botão é “Salvar”, em outra “Concluir”, em outra “Aplicar”, mas todas fazem a mesma coisa (persistem alterações). Isso cria dúvida sobre consequências e aumenta erros.

3) Estados e status

Status são especialmente sensíveis porque orientam decisão. Padronize a lista de estados, seus nomes e critérios. Evite status ambíguos (“Em andamento”) quando há múltiplas etapas. Prefira termos que indiquem claramente o que falta ou o que ocorreu.

• Bom: “Aguardando pagamento”, “Pagamento confirmado”, “Enviado”, “Entregue”.
• Arriscado: “Processando”, “Em análise”, “Pendente” (pendente de quê?).

4) Campos e labels de formulário

Labels devem refletir o que o usuário reconhece e o formato esperado. Padronize:

• Nome do campo: “CPF” vs “CPF/CNPJ” vs “Documento”.
• Formato e exemplo: quando necessário, use placeholder ou texto de ajuda para indicar padrão (ex.: “000.000.000-00”).
• Unidades: “Valor (R$)”, “Peso (kg)”, “Prazo (dias)”.

5) Capitalização, pontuação e estilo

Decida regras simples e aplique em todo o produto:

• Menus e botões: “Salvar” vs “SALVAR” vs “Salvar alterações”.
• Títulos: “Meus pedidos” vs “Meus Pedidos” (defina um padrão).
• Abreviações: quando usar siglas (ex.: “CPF”) e quando expandir (ex.: “Código de verificação”).

Como descobrir o vocabulário do usuário (sem adivinhar)

Você não precisa de pesquisa complexa para começar, mas precisa de evidências. A seguir, um conjunto de métodos práticos e complementares.

1) Coleta rápida de termos reais

• Tickets e chats de suporte: extraia palavras que usuários usam para descrever o problema (“não consigo entrar”, “minha senha expirou”, “cobrança duplicada”).
• Buscas internas: termos digitados na busca do produto revelam o que as pessoas esperam encontrar (ex.: “2 via boleto”, “nota fiscal”).
• Reviews e redes: linguagem espontânea, especialmente para dores e expectativas.
• Documentos do domínio: quando o usuário é especialista (ex.: área médica, fiscal), termos oficiais podem ser apropriados, mas verifique se são os mesmos usados no dia a dia.

2) Entrevistas curtas focadas em linguagem

Em vez de perguntar “você entende este termo?”, peça para a pessoa nomear coisas e ações:

• “Como você chamaria esta tela?”
• “Se você fosse procurar isso no menu, que palavra clicaria?”
• “O que significa ‘X’ para você?”
• “Qual a diferença entre ‘A’ e ‘B’?”

Registre sinônimos e, principalmente, divergências: quando diferentes usuários usam termos distintos, pode ser sinal de segmentação (perfis) ou de necessidade de um termo mais neutro.

3) Teste de nomenclatura (rápido)

Monte uma lista com 8–15 termos candidatos para objetos e ações críticas e faça um teste simples:

• Correspondência: mostre uma descrição (“ver cobranças do mês”) e peça qual termo melhor representa (“Faturas”, “Cobranças”, “Pagamentos”).
• Localização: pergunte onde a pessoa esperaria encontrar (“Faturas” fica em “Financeiro” ou em “Conta”?)

Mesmo com poucos participantes, você identifica termos que geram confusão imediata.

Passo a passo prático para criar um padrão de nomenclatura

Passo 1: Liste os conceitos e ações mais importantes

Comece pelo que aparece com mais frequência e tem maior impacto em navegação e decisão:

• Objetos principais (ex.: Pedido, Cliente, Produto, Fatura).
• Ações principais (ex.: Criar, Editar, Enviar, Cancelar, Excluir).
• Status principais (ex.: Rascunho, Aguardando aprovação, Aprovado).

Dica prática: percorra o produto e capture screenshots das telas-chave. Em seguida, extraia todos os termos usados em menus, botões, títulos, tabelas e mensagens. Isso vira seu inventário inicial.

Passo 2: Identifique inconsistências e conflitos

Marque ocorrências de:

• Sinônimos para o mesmo conceito: “Fatura” e “Boleto” usados como se fossem iguais.
• Homônimos: “Conta” significando “perfil” e “conta bancária”.
• Termos genéricos: “Item”, “Registro”, “Documento” sem contexto.
• Verbos diferentes para a mesma ação: “Salvar” vs “Aplicar”.

Priorize conflitos em fluxos críticos (cadastro, pagamento, envio, login) e em pontos de erro.

Passo 3: Escolha o termo preferido com critérios objetivos

Para cada conceito, escolha um termo preferido usando critérios:

• Frequência no vocabulário do usuário: aparece em buscas, suporte, entrevistas.
• Precisão: descreve o objeto sem ambiguidade.
• Escalabilidade: funciona com variações futuras (ex.: “Pagamento” pode abranger cartão e Pix; “Boleto” não).
• Compatibilidade com o domínio: respeita termos obrigatórios quando necessário (ex.: fiscal), mas com apoio de explicação quando o termo for incomum.

Quando houver disputa entre termo técnico e termo popular, uma solução comum é usar o termo popular como label e o técnico em texto de apoio, quando exigido. Ex.: label “Imposto” com ajuda “(ISS)” se o público não usa a sigla.

Passo 4: Defina regras de forma (singular/plural, capitalização, artigos)

Crie regras simples e documente:

• Menus: plural (“Pedidos”, “Clientes”).
• Botões de criação: “Novo pedido” ou “Criar pedido” (escolha um padrão).
• Títulos de página: “Pedido #1234” (objeto no singular quando é detalhe).
• Texto corrido: minúsculas, exceto nomes próprios e siglas.

Evite alternar entre “Novo” e “Adicionar” sem motivo. Se “Adicionar” for usado para inserir algo dentro de um objeto (ex.: adicionar item ao pedido), mantenha “Novo”/“Criar” para criar o objeto em si.

Passo 5: Padronize verbos por resultado

Monte uma tabela de verbos e quando usar:

• Salvar: guardar alterações sem mudar visibilidade.
• Enviar: submeter para outra pessoa/sistema.
• Publicar: tornar visível para audiência.
• Confirmar: finalizar uma decisão irreversível ou importante.
• Cancelar: interromper um processo em andamento (mantendo histórico).
• Excluir: remover (idealmente com aviso e, se possível, recuperação).
• Arquivar: tirar da lista principal sem apagar.

Depois, revise botões e mensagens para garantir que o verbo corresponde ao efeito real. Se clicar em “Cancelar” apaga dados, o verbo está errado (ou a ação está errada).

Passo 6: Crie um glossário operacional (leve e útil)

O glossário deve ser consultável por design, produto, engenharia e suporte. Para cada termo, inclua:

• Termo: “Fatura”.
• Definição curta: “Cobrança mensal gerada para o cliente”.
• Onde aparece: menu, tela X, e-mails, notificações.
• Não usar: “Cobrança”, “Boleto” (se não forem equivalentes).
• Notas: diferenças importantes (ex.: “Boleto é um meio de pagamento; fatura é a cobrança”).

Esse glossário evita que cada nova tela reinvente termos e reduz divergências entre produto e suporte.

Passo 7: Aplique em lote nos pontos de maior impacto

Comece por:

• Navegação: menus, categorias, títulos de páginas.
• CTAs principais: botões de criação, envio, pagamento.
• Status visíveis: listas, cards, timelines.
• Erros recorrentes: mensagens que citam objetos/ações (ex.: “Não foi possível processar a entidade”).

Ao atualizar, procure também consistência entre interface e comunicações (e-mail, push, SMS). Se o produto chama “Fatura”, o e-mail não deve chamar “Cobrança” sem explicar.

Exemplos práticos de ajustes de vocabulário e nomenclatura

Exemplo 1: “Conta” ambígua

Problema: “Conta” aparece em “Minha conta” (perfil) e em “Conta” (dados bancários). Usuários confundem onde alterar informações.

Ajuste:

• Perfil: “Perfil” ou “Dados da conta” (se for login).
• Bancário: “Conta bancária”.
• Se houver área financeira: “Pagamentos”/“Financeiro” para agrupar.

Regra: “Conta” sozinha não pode ser usada; sempre qualificar (“conta bancária”, “conta de acesso”).

Exemplo 2: “Processar” vs “Enviar”

Problema: botão “Processar pedido” em um fluxo onde o usuário espera apenas enviar para aprovação. “Processar” sugere automação, cobrança ou execução imediata.

Ajuste: trocar para “Enviar para aprovação” (ação real) e, se houver etapa automática posterior, mostrar status “Em aprovação”.

Regra: verbos devem descrever a ação do usuário e o resultado imediato, não o que o sistema faz internamente.

Exemplo 3: “Documento” genérico em upload

Problema: campo “Documento” para upload, mas o sistema aceita tipos diferentes (RG, CNH, comprovante).

Ajuste: label “Tipo de documento” + seletor (RG, CNH, Passaporte) e campo “Enviar arquivo”.

Regra: quando há múltiplas opções, nomeie a escolha e separe do envio.

Exemplo 4: Status “Pendente”

Problema: lista de itens com status “Pendente”. Usuário não sabe se falta pagamento, aprovação ou envio de dados.

Ajuste: substituir por status específicos: “Aguardando pagamento”, “Aguardando aprovação”, “Aguardando documentos”.

Regra: status deve indicar o próximo passo ou a dependência.

Como lidar com sinônimos, regionalismos e preferências de público

Sinônimos: escolha um e dê suporte ao restante

Usuários podem falar “boleto” quando querem dizer “fatura”, ou “mensalidade” quando querem dizer “assinatura”. Você pode:

• Escolher um termo principal para a interface.
• Reconhecer sinônimos em busca interna e ajuda (ex.: busca por “mensalidade” retorna “Assinatura”).
• Usar microexplicações quando necessário (ex.: “Fatura (cobrança do mês)”).

Regionalismos e variações

Se o produto atende públicos de regiões diferentes, evite termos muito locais quando houver alternativa amplamente compreendida. Quando não houver, use o termo mais comum e complemente com exemplos. Em produtos B2B, a variação pode ser por setor: o mesmo conceito muda de nome entre áreas.

Segmentação por perfil

Às vezes, “vocabulário do usuário” não é único. Um administrador e um operador podem usar termos diferentes. Nesses casos:

• Use nomenclatura mais técnica nas áreas administrativas (se o público for especialista).
• Use termos orientados à tarefa nas áreas operacionais.
• Evite que o mesmo objeto mude de nome entre perfis; se mudar, documente e garanta que a navegação deixe claro o contexto.

Checklist de revisão de nomenclatura em telas e fluxos

• Um conceito tem um nome só? Se não, qual será o termo preferido?
• Um termo aponta para um conceito só? Se “Conta” aparece, está qualificado?
• Os verbos descrevem o resultado imediato? “Enviar”, “Salvar”, “Publicar” estão coerentes com o que acontece?
• Status são específicos? Evite “Pendente” sem complemento.
• Plural/singular está consistente? Menu em plural, detalhe em singular, por exemplo.
• Siglas estão justificadas? O público reconhece? Há expansão quando necessário?
• Termos aparecem iguais em interface e mensagens? Notificações e e-mails usam a mesma nomenclatura?

Modelo de guia de nomenclatura (para copiar e adaptar)

Objetos principais
- Pedido
  - Definição: solicitação de compra criada pelo cliente.
  - Onde aparece: Menu Pedidos, Lista de pedidos, Detalhe do pedido.
  - Não usar: Compra, Ordem.
  - Notas: Orçamento é um objeto diferente.

- Fatura
  - Definição: cobrança gerada para um período.
  - Onde aparece: Menu Financeiro > Faturas, Tela de pagamento.
  - Não usar: Cobrança (como label), Boleto (a menos que seja meio de pagamento).

Ações (verbos)
- Criar: gerar um novo objeto (Criar pedido).
- Adicionar: inserir item dentro de um objeto (Adicionar item).
- Salvar: persistir alterações sem enviar.
- Enviar: submeter para aprovação/validação.
- Cancelar: interromper processo sem apagar histórico.
- Excluir: remover definitivamente (usar com confirmação).

Status
- Rascunho: ainda não enviado.
- Aguardando pagamento: falta pagamento.
- Pagamento confirmado: pagamento recebido.
- Enviado: entregue à transportadora.

Armadilhas frequentes e como evitar

Inventar nomes “de produto” para conceitos comuns

Se o usuário procura “Relatórios”, chamar de “Insights” pode reduzir encontrabilidade. Se houver motivo de marca, mantenha o termo comum como suporte: menu “Relatórios” e, dentro, “Insights” como nome de uma seção específica.

Usar o mesmo termo para níveis diferentes

Ex.: “Projeto” como área (workspace) e como item (um projeto dentro do workspace). Isso cria confusão em breadcrumbs, permissões e mensagens (“Você não tem acesso ao projeto”). Diferencie: “Espaço” (nível superior) e “Projeto” (nível inferior), ou “Área” e “Projeto”.

Trocar nomenclatura por preferências internas

Se o time prefere “colaborador” mas o usuário busca “funcionário”, a preferência interna não deve vencer sem evidência. Quando houver sensibilidade (ex.: termos inclusivos), faça a transição com cuidado: use o termo escolhido e garanta que busca e ajuda reconheçam o termo antigo durante um período.

Não alinhar nomenclatura com regras do sistema

Se o sistema diferencia “Excluir” (permanente) e “Arquivar” (reversível), a interface não pode usar “Excluir” para arquivar. A nomenclatura precisa refletir a regra real, senão o usuário perde confiança.