Smashing reúne um guia prático para dar nome às coisas na interface

A Smashing Magazine publicou um guia de leitura de sete minutos sobre uma tarefa que todo time de produto enfrenta e pouco documenta: escolher nomes. O ponto de partida é que um nome pode errar para os dois lados. Genérico demais, ninguém sabe o que ele designa. Específico demais, ele não serve para reaproveitar.

O texto funciona como uma lista comentada de fontes, uma por problema. Para classes e funções de código, um site de listas de palavras por tema. Para cores, um repositório com mais de trinta mil nomes. Para camadas e grupos no arquivo de design, um conjunto de boas práticas que pede nomes curtos, conhecidos por todos e sem relação com aparência visual. Para tokens, o estudo de caso da Intuit e o mapa de variáveis da Vodafone UK. Para componentes, uma galeria que cataloga como diferentes design systems chamam a mesma peça. Para funcionalidades, uma recomendação que vale para qualquer produto: perguntar ao usuário como ele explicaria aquilo e usar as palavras dele.

A conclusão é que o melhor nome é o que o time e os usuários realmente entendem e usam. Baixa adoção de uma funcionalidade pode ser, no fundo, problema de nome.

O que isso muda pra quem faz design/produto

Nada de novo na tese, e é justamente por isso que vale marcar o guia: ele vira checklist barato para uma revisão de nomes antes de fechar uma biblioteca. Há um motivo extra para fazer essa revisão agora. Ferramentas que leem o arquivo, como os agentes de IA, tomam decisões a partir do que está escrito nas camadas e nos tokens. Nome confuso deixou de ser só um incômodo entre pessoas.

Fonte: Vitaly Friedman, “A Practical Guide To Naming Things”, Smashing Magazine, 6 de outubro de 2026.

Leitura do hub: este resumo e o trecho “O que isso muda” foram escritos com apoio de inteligência artificial a partir da fonte citada e revisados antes de entrar no ar. Viu algum erro? Avise e eu corrijo.