Um bom sistema de nomenclatura aproxima design, desenvolvimento e produto, reduz ambiguidades e facilita a evolução das interfaces.

Dar nome a um componente, uma variável ou um recurso parece uma tarefa pequena. Na prática, a escolha pode influenciar como uma equipe conversa, documenta decisões e mantém uma interface ao longo do tempo. Um nome vago deixa dúvidas sobre o que está sendo descrito; um nome específico demais pode limitar o uso e dificultar a adaptação. Encontrar o equilíbrio exige compreender o contexto e as pessoas que vão usar aquela nomenclatura.

Esse desafio aparece em diferentes partes de um produto digital. Pode surgir ao organizar camadas em um arquivo de design, definir tokens visuais, nomear classes de código, descrever cores ou apresentar uma funcionalidade para usuários. Em cada caso, a pergunta central é semelhante: qual nome comunica a intenção com clareza para quem precisa reconhecê-la e usá-la?

Uma convenção consistente não depende de encontrar uma palavra engenhosa para cada elemento. Ela depende de criar critérios que possam ser repetidos e compreendidos por toda a equipe. A seguir, veja como abordar esse trabalho, que decisões considerar e como transformar nomes isolados em um sistema útil.

Por que a nomenclatura influencia o trabalho de uma equipe

As palavras organizam a maneira como descrevemos um produto. Se uma pessoa chama um elemento de “cartão”, outra de “bloco” e uma terceira de “painel”, a equipe pode estar falando da mesma coisa sem perceber. Também pode estar usando palavras iguais para elementos diferentes. Em ambos os casos, a conversa fica menos precisa e as decisões dependem de explicações adicionais.

O problema não se limita à comunicação verbal. Nomes aparecem em bibliotecas de componentes, arquivos de design, propriedades de código, documentação, relatórios e interfaces. Uma escolha pouco clara pode se repetir em todos esses lugares. Com o tempo, essa repetição aumenta o esforço necessário para localizar, manter e reutilizar o que já existe.

Uma nomenclatura útil ajuda a responder perguntas práticas: o que é este item? Para que serve? Em que contexto deve ser aplicado? Como se relaciona com outros elementos? Não é obrigatório que cada nome responda a tudo isso sozinho. A estrutura ao redor, como categorias e documentação, também fornece contexto. O importante é que nome e sistema trabalhem juntos.

Há ainda uma diferença entre nomes voltados à equipe e nomes apresentados ao público. Uma variável interna pode precisar expressar uma função técnica ou uma posição na arquitetura. Já o nome de uma funcionalidade deve fazer sentido para quem usa o produto, de preferência com palavras familiares a esse público. A mesma palavra nem sempre funciona bem nos dois ambientes.

Comece pelo significado, não pela aparência

Um critério recorrente para nomes de componentes e grupos é descrever sua função ou intenção, em vez de se apoiar apenas em características visuais. “Caixa azul” pode ser uma descrição imediata, mas deixa de servir se a cor mudar. “Mensagem de status” comunica um papel que pode continuar válido mesmo após uma atualização visual.

Isso não quer dizer que propriedades visuais nunca devam aparecer em nomes. Em certos sistemas, diferenças de tamanho, cor ou estado são parte necessária da identificação. A questão é decidir se a característica nomeada representa uma regra estável ou apenas a aparência atual de uma versão específica. Se o nome depende de um detalhe que pode mudar sem alterar a função, talvez esteja acoplado demais à apresentação.

Considere também a escala de uso. Um nome apropriado para uma camada de um arquivo pode não ser suficiente para representar um componente compartilhado entre produtos. Da mesma forma, um rótulo interno que funciona para designers e desenvolvedores pode ser confuso quando aparece diretamente na interface. Antes de escolher, identifique onde o nome será visto e por quem.

Equilibre clareza e possibilidade de reutilização

Nomes amplos demais têm pouca capacidade de distinguir elementos. “Item”, “grupo” e “conteúdo” podem significar quase qualquer coisa, especialmente em bibliotecas grandes. A equipe precisa abrir o arquivo, procurar documentação ou perguntar a alguém para descobrir a finalidade. Quando esse tipo de nome aparece repetidamente, a busca se torna ainda mais difícil.

No extremo oposto, um nome excessivamente específico pode descrever uma única tela, uma campanha temporária ou uma combinação visual que não deveria determinar a identidade do componente. Se cada situação receber uma criação e um nome exclusivos, a reutilização fica mais difícil e a biblioteca tende a crescer sem necessidade.

Um bom ponto de partida é nomear a responsabilidade principal do elemento e usar atributos adicionais apenas quando forem necessários. Por exemplo, “aviso” pode identificar a função geral, enquanto uma propriedade de estado indica se ele representa uma informação, um alerta ou uma confirmação. Essa separação mantém o conceito reconhecível sem embutir todas as variações em uma única palavra.

Use uma estrutura que possa ser repetida

Uma convenção eficiente não é apenas uma lista de nomes aprovados. É uma estrutura que explica como combinar termos para identificar elementos novos. Sem essa lógica, cada pessoa pode criar nomes aceitáveis isoladamente, mas incompatíveis entre si. Uma estrutura simples reduz interpretações particulares e torna mais fácil incluir novos itens.

Uma sequência de nomeação pode considerar, por exemplo, a categoria do elemento, sua função, o contexto em que aparece e uma variação relevante. Nem todo nome precisa conter todas essas partes. A estrutura serve como orientação para decidir quais informações são necessárias e em que ordem devem aparecer.

Uma convenção também precisa levar em conta o meio em que será aplicada. Nomes de propriedades em código podem seguir regras de formato específicas, enquanto nomes de camadas em um documento visual precisam ser fáceis de localizar e escanear. A terminologia deve manter coerência entre os ambientes, mas não precisa copiar mecanicamente a mesma sintaxe em todos eles.

Defina critérios antes de montar a lista

Antes de escolher termos, a equipe pode registrar alguns critérios curtos. Eles ajudam a avaliar alternativas quando há divergência e evitam que decisões recorrentes dependam apenas do gosto individual. Entre os critérios possíveis estão:

• Compreensível: pessoas de diferentes áreas reconhecem o sentido sem precisar de uma explicação particular.
• Significativo: o nome comunica a função, a relação ou a intenção relevante.
• Conciso: não inclui palavras que repetem informação já apresentada pela categoria.
• Consistente: segue padrões de vocabulário, ordem e formato adotados pelo sistema.
• Adaptável: não fica preso a uma tela ou a um detalhe visual sujeito a mudança, quando isso não for necessário.
• Distinguível: ajuda a separar conceitos que precisam ser encontrados ou usados de formas diferentes.

Esses critérios não são uma fórmula automática. Um nome pode ser curto e ainda assim ambíguo; outro pode ser um pouco mais longo e muito mais claro. A avaliação deve considerar o contexto real, incluindo os termos que a equipe e os usuários já conhecem.

Nomes de componentes de interface

Componentes como menus, abas, acordeões, campos e avisos aparecem em muitos sistemas de design, mas nem sempre recebem os mesmos nomes. Uma equipe pode chamar determinado padrão de “seletor”, enquanto outra usa um termo mais específico para indicar que se trata de um menu de opções. Comparar exemplos de sistemas existentes ajuda a perceber convenções, mas não substitui a decisão baseada no produto e no vocabulário da equipe.

Para nomear um componente, primeiro descreva o comportamento e a finalidade. Pergunte o que a pessoa faz com ele, que resultado espera e o que o diferencia de elementos próximos. Um campo que aceita texto livre, por exemplo, não deve ser confundido com um controle que apresenta opções predefinidas. A distinção pode parecer óbvia numa tela isolada, mas é importante quando a biblioteca reúne dezenas de padrões.

Depois, verifique se o termo escolhido é entendido por design, desenvolvimento, conteúdo e produto. Se cada área interpretar o nome de modo diferente, talvez seja necessário preferir uma palavra mais comum ou incluir uma definição no glossário. O objetivo não é eliminar toda variação linguística, mas criar um vocabulário compartilhado para o trabalho cotidiano.

Evite tratar sinônimos como componentes diferentes

Uma biblioteca pode acumular duplicatas porque elementos semelhantes são cadastrados com nomes distintos. Antes de criar um novo componente, procure por termos alternativos e compare o comportamento, a finalidade e as regras existentes. Uma busca cuidadosa pode revelar que o padrão já existe sob outra denominação.

O inverso também merece atenção: um único nome pode estar sendo usado para vários padrões diferentes. Se “menu” representa tanto uma lista de navegação quanto um conjunto de ações contextuais, a equipe pode acabar aplicando regras inadequadas de acessibilidade, interação ou conteúdo. Nesse caso, dividir conceitos pode deixar o sistema mais claro.

Uma forma prática de reduzir esse tipo de confusão é manter um glossário conciso. Para cada termo importante, registre o nome preferido, uma explicação breve e, quando útil, palavras alternativas que devem ser evitadas ou tratadas como sinônimos. O glossário não precisa descrever cada detalhe de implementação; sua função é estabilizar o significado compartilhado.

Como organizar nomes de camadas e grupos

Arquivos de design podem se tornar difíceis de navegar quando suas camadas conservam nomes automáticos ou descrições genéricas. Uma estrutura previsível facilita encontrar seções, compreender relações entre elementos e identificar componentes reutilizáveis. O benefício aparece tanto para quem criou o arquivo quanto para uma pessoa que precisa revisá-lo meses depois.

Comece nomeando grupos de acordo com o conteúdo ou a função que organizam. Em vez de usar uma sequência de rótulos como “Grupo 1” e “Grupo 2”, prefira categorias que ajudem a localizar a seção. Dentro de cada grupo, mantenha uma hierarquia que reflita a organização real da interface, sem criar níveis extras apenas para parecer detalhada.

Também é útil separar elementos de interface de observações e material de apoio. Comentários de revisão, referências temporárias e alternativas de exploração não devem ser confundidos com partes finais do desenho. Um padrão de nomes ou uma área própria para rascunhos ajuda a indicar o status do conteúdo.

Revise a estrutura com alguém que não participou da criação do arquivo. Peça que encontre um componente específico ou explique o que determinada camada representa. Se a pessoa precisar abrir muitos grupos ou depender de uma explicação oral, o problema pode estar na hierarquia, nos nomes ou em ambos.

Nomeie cores pelo papel que desempenham

Nomes de cores podem seguir abordagens diferentes. Uma paleta pode usar termos descritivos, nomes inspirados em referências visuais ou identificadores organizados por uma escala. Essas opções atendem a necessidades distintas. Para um sistema usado por muitas pessoas, a questão mais importante costuma ser saber se o nome comunica o papel da cor ou apenas sua aparência.

Um nome como “verde-claro” descreve uma característica perceptível, mas não informa necessariamente se a cor deve ser usada em um fundo, em um texto, num estado de sucesso ou em uma borda decorativa. Uma nomenclatura funcional pode diferenciar uma referência visual básica de um uso semântico. Assim, uma cor da paleta pode alimentar tokens que comunicam papéis diferentes no produto.

Separar essas camadas ajuda a acomodar temas e mudanças visuais. Uma cor definida como fundo de destaque pode ser substituída sem que cada componente precise incorporar novamente o valor cromático. O nome semântico continua apontando para a função, enquanto a referência visual pode variar de acordo com tema, marca ou contexto.

Isso não significa que cada sistema precise de uma arquitetura complexa. A estrutura deve corresponder ao número de produtos, temas e situações que realmente precisam ser atendidos. Para uma interface pequena, muitas camadas de abstração podem criar mais trabalho do que clareza. Para um conjunto amplo de experiências, uma separação explícita entre valor e papel pode tornar as mudanças mais administráveis.

Crie uma taxonomia de tokens que explique as relações

Tokens de design são nomes atribuídos a decisões reutilizáveis, como valores de cor, espaçamento ou tipografia. Uma taxonomia organiza esses nomes e ajuda a entender o que cada token representa, onde se encaixa e como pode ser usado. Não basta produzir uma sequência ordenada de identificadores; é preciso que a estrutura seja compreensível para quem mantém o sistema.

Uma taxonomia pode distinguir valores fundamentais, significados semânticos e aplicações específicas. Em outras palavras, pode separar o valor de base, o papel atribuído a esse valor e o contexto em que ele é empregado. Essa separação permite que diferentes experiências compartilhem uma estrutura sem exigir que todas tenham aparência idêntica.

Ao desenhar a estrutura, liste primeiro as perguntas que os nomes precisam responder. A equipe precisa saber a qual marca pertence o token? Precisa distinguir temas claros e escuros? Deve identificar se o valor é usado em uma página específica ou se tem significado compartilhado? As respostas ajudam a determinar quais níveis são necessários. Adicionar dimensões sem uma necessidade clara pode tornar os nomes longos e difíceis de manter.

Organize tokens sem transformar cada nome em uma frase

Nomes extensos podem parecer completos, mas dificultam leitura, busca e uso. Uma hierarquia bem definida permite que cada parte do nome tenha uma função, sem repetir dados que já estão implícitos no contexto. Para alcançar isso, estabeleça uma ordem estável e documente o significado de cada segmento.

Também é importante evitar abreviações obscuras. Uma abreviação familiar para uma pessoa pode ser indecifrável para outra ou perder significado com o passar do tempo. Se for indispensável encurtar nomes por limitações técnicas, registre as formas permitidas e use-as de maneira consistente. A concisão deve diminuir o atrito, não criar um código secreto.

Uma planilha de inventário pode apoiar a revisão. Ela pode reunir o nome, a categoria, o papel, o tema ou modo associado e uma explicação de uso. Filtros e agrupamentos tornam mais fácil localizar itens repetidos e identificar lacunas. O inventário também permite conversar sobre a taxonomia sem depender de uma busca fragmentada em várias ferramentas.

Antes de aplicar uma nova estrutura em larga escala, teste-a com exemplos reais. Inclua casos comuns, exceções e situações que exijam mais de uma dimensão. Se os nomes resultantes forem ambíguos ou longos, ajuste a estrutura antes de migrar todo o sistema. Um pequeno piloto pode revelar problemas que não aparecem numa discussão abstrata.

Variáveis e propriedades: mostre o que o nome precisa comunicar

Variáveis de interface e propriedades de código podem seguir a mesma lógica de intenção, contexto e consistência. Contudo, cada ambiente apresenta necessidades próprias. Uma variável deve ser reconhecível no ponto de uso e também se encaixar na organização do projeto. Um nome isolado pode parecer óbvio, mas perder clareza quando há centenas de outros identificadores.

Considere o ciclo de vida da variável. Se ela representa uma função duradoura, o nome deve expressar essa função. Se representa uma configuração temporária ou um valor ligado a um experimento, essa condição pode ser documentada ou indicada por um padrão apropriado. Evite depender de convenções implícitas que só a pessoa autora conhece.

Uma taxonomia visual pode ajudar a identificar as relações entre variáveis, tokens e páginas. Ela não deve servir apenas como diagrama bonito: precisa permitir que alguém acompanhe de onde vem um valor, que significado recebe e onde aparece. Quando as relações estão visíveis, a equipe pode avaliar com mais segurança as consequências de uma alteração.

As regras também devem esclarecer o que fazer quando um caso não se encaixa. Toda convenção encontra exceções. Se a equipe não souber como registrar uma nova necessidade, cada pessoa pode inventar uma solução incompatível. Definir um processo simples para propor termos, revisar duplicatas e atualizar a documentação torna o sistema mais resiliente.

Nomes de funcionalidades devem falar com quem usa o produto

O nome de uma funcionalidade tem um desafio adicional: precisa ajudar a pessoa a encontrá-la, entendê-la e decidir se vale a pena experimentá-la. Um termo interno da equipe pode descrever corretamente a implementação e, ainda assim, não comunicar o benefício. A linguagem da interface deve se aproximar do modo como o público descreve suas tarefas e necessidades.

Para descobrir esse vocabulário, reúna as expressões usadas pelas pessoas ao explicar o que querem fazer ou o problema que tentam resolver. Observe quais palavras aparecem espontaneamente e quais exigem tradução para termos técnicos. O nome final não precisa reproduzir literalmente uma frase de pesquisa, mas deve evitar afastar-se da compreensão cotidiana sem uma boa razão.

Também é útil avaliar se o nome sinaliza o resultado esperado. Uma expressão abstrata pode soar distintiva, mas deixar a pessoa sem pistas sobre o que acontecerá ao selecioná-la. Um nome mais descritivo tende a diminuir a distância entre a expectativa e a experiência. Se a funcionalidade for complexa, uma breve explicação complementar pode fornecer contexto sem sobrecarregar o rótulo.

O nome é apenas uma parte da descoberta. Organização da navegação, contexto, mensagens de apoio e momento de apresentação também influenciam se uma funcionalidade será percebida e compreendida. Por isso, se as pessoas não encontram um recurso, vale investigar o percurso completo antes de concluir que a palavra escolhida é a única causa.

Produto, serviço e marca pedem outro tipo de decisão

O nome de um produto ou serviço envolve questões mais amplas do que a organização de componentes. Pode ser necessário explorar associações, pronúncia, significado em diferentes contextos, disponibilidade e possíveis conflitos. Uma sessão de ideias pode ampliar as opções, mas não substitui etapas posteriores de avaliação e validação.

Comece definindo o que o nome precisa comunicar e quais restrições devem ser respeitadas. Registre o público, o tipo de oferta, o tom desejado e os termos que devem ser evitados. Depois, gere alternativas sem avaliar cada uma imediatamente. Na etapa seguinte, filtre as opções conforme os critérios definidos, verificando clareza, facilidade de uso e adequação ao contexto.

Não confunda um nome criativo com um nome automaticamente eficaz. Uma palavra inesperada pode despertar curiosidade, mas também exigir explicações contínuas. Uma expressão direta pode ser fácil de compreender, porém pouco diferenciada. O equilíbrio depende do posicionamento, da familiaridade do público e dos meios em que o nome será apresentado.

Quando a decisão tiver implicações legais ou comerciais, é prudente envolver as pessoas responsáveis por essas avaliações. Uma rodada interna de preferência não confirma disponibilidade nem garante que o nome possa ser adotado em todos os mercados e canais. A criação do nome e a verificação de sua viabilidade são partes relacionadas, mas diferentes do processo.

Um processo prático para escolher e revisar nomes

Uma equipe pode organizar o trabalho em etapas curtas, em vez de tentar resolver toda a nomenclatura de uma vez. O processo abaixo se aplica a componentes, tokens, grupos e funcionalidades, com adaptações de acordo com o escopo.

1. Delimite o objeto: esclareça o que está sendo nomeado e onde o nome será usado.
2. Identifique o público: liste quem precisa reconhecer, escolher ou manter o item.
3. Descreva a intenção: escreva em linguagem simples o que o elemento faz ou representa.
4. Pesquise o vocabulário existente: procure sinônimos, componentes semelhantes e padrões já adotados.
5. Gere alternativas: crie opções a partir da função, do contexto e da terminologia conhecida.
6. Aplique os critérios: compare clareza, concisão, consistência e possibilidade de adaptação.
7. Teste em contexto: leia o nome numa lista, num arquivo, numa conversa e, se for o caso, na própria interface.
8. Registre a decisão: documente o termo escolhido e qualquer distinção que possa evitar confusão futura.
9. Revise com o uso: recolha dúvidas e conflitos e ajuste a convenção quando houver evidências de dificuldade.

Essa sequência não precisa transformar cada nome numa reunião. Para decisões pequenas, uma revisão rápida por pares pode bastar. Para termos que atravessam produtos, equipes e documentação, vale registrar mais contexto e envolver as áreas que dependem da escolha. A intensidade do processo deve acompanhar o impacto da decisão.

Faça testes simples de compreensão

Uma pergunta útil é: “O que você esperaria encontrar com este nome?”. Mostre o termo sem explicar a resposta e observe como outras pessoas o interpretam. Se as respostas forem muito diferentes, o nome pode estar vago ou carregar significados concorrentes. Para funcionalidades, peça que a pessoa explique o que imagina que acontecerá ao selecioná-la.

Outra verificação é o teste de expansão. Pergunte se o nome ainda funciona quando o elemento aparece em outra página, com outro tema ou em um estado diferente. Se a resposta for não, identifique se isso representa uma diferença legítima ou se o nome ficou preso a uma ocorrência específica.

Também é útil testar a leitura em conjunto. Um grupo de nomes pode parecer coerente quando cada item é visto sozinho e revelar inconsistências quando comparado lado a lado. Observe ordem, singular e plural, nível de detalhe e uso de sinônimos. A consistência emerge do conjunto, não apenas de decisões individuais.

Como lidar com conflitos e mudanças

Mesmo um sistema bem cuidado pode apresentar nomes em conflito. Um termo antigo pode continuar em arquivos, documentos ou conversas, enquanto a equipe já adotou uma alternativa. Ignorar a divergência costuma prolongar a confusão; renomear tudo de imediato, sem avaliar dependências, também pode gerar trabalho desnecessário.

Registre os conflitos identificados e avalie seu impacto. Pergunte se causam erros, dificultam a busca ou apenas representam uma diferença estética. Priorize os que atrapalham tarefas frequentes ou levam a usos incorretos. Para itens de baixo impacto, uma correção pode ser planejada junto com a próxima manutenção, desde que a decisão fique visível para as pessoas envolvidas.

Ao mudar um nome, comunique o que foi alterado, por que a mudança ocorreu e quais termos anteriores ainda podem aparecer. Se houver dependências técnicas ou referências em arquivos compartilhados, planeje a atualização com cuidado. Uma política de versionamento ou um registro de mudanças pode ajudar a preservar o entendimento durante a transição.

Não trate a nomenclatura como algo finalizado para sempre. Novos produtos, equipes e necessidades podem exigir ajustes. O objetivo é manter critérios estáveis e permitir revisões justificadas, sem transformar cada preferência individual em uma renomeação geral.

Erros comuns que enfraquecem uma convenção

• Escolher nomes apenas pelo gosto pessoal: preferência pode iniciar uma conversa, mas não substitui critérios de entendimento e uso.
• Confundir aparência com função: um detalhe visual pode mudar sem que a responsabilidade do elemento mude.
• Acumular sinônimos sem distinção: várias palavras para o mesmo conceito tornam a busca e a comunicação menos previsíveis.
• Usar abreviações sem explicação: o que parece óbvio para quem criou pode não ser reconhecido pelo restante da equipe.
• Adicionar níveis desnecessários: uma taxonomia complexa pode exigir mais esforço para entender do que o próprio item.
• Ignorar quem usa a interface: rótulos internos podem não corresponder às palavras que o público compreende.
• Deixar decisões sem registro: sem documentação, a equipe pode reabrir a mesma discussão repetidamente.
• Confundir uniformidade com rigidez: manter uma regra não significa ignorar exceções justificadas ou mudanças de contexto.

Uma revisão periódica pode identificar esses problemas antes que se espalhem. Não é necessário auditar cada nome com a mesma frequência. Comece pelos itens mais usados, pelas áreas que recebem mais dúvidas e pelos pontos em que há duplicação. A partir daí, estabeleça uma lista de melhorias e trate-as conforme sua relevância.

Uma nomenclatura útil é construída em conjunto

A responsabilidade por nomes não pertence exclusivamente a designers, desenvolvedores ou profissionais de conteúdo. Cada grupo percebe necessidades diferentes. Design pode priorizar relações visuais e reutilização; desenvolvimento, consistência e facilidade de manutenção; produto, compreensão do comportamento; conteúdo, clareza da linguagem. A colaboração ajuda a revelar pontos cegos antes que se tornem parte do sistema.

Isso não significa que todas as decisões precisem de consenso amplo. É possível definir responsáveis, critérios e um caminho de consulta proporcional ao impacto. O essencial é que as pessoas afetadas saibam onde propor uma mudança e como descobrir a convenção vigente. Um sistema acessível reduz a dependência de conhecimento informal concentrado em poucas pessoas.

Para equipes que trabalham com produtos digitais, a nomenclatura é uma dimensão prática da experiência. Ela está presente na organização dos arquivos, na implementação, nas conversas e nos rótulos vistos pelo público. Investir em nomes claros não elimina todos os desencontros, mas facilita encontrar a origem de dúvidas e discutir soluções com menos interpretações paralelas.

Quando um termo gera confusão repetidamente, não basta pedir que todos se acostumem a ele. Vale investigar se o nome está descrevendo o conceito certo, se a estrutura ao redor está clara e se há uma diferença real entre os elementos que parecem iguais. A resposta pode ser uma mudança de palavra, uma definição melhor, uma divisão de categorias ou uma revisão da experiência.

A Sorting pode ajudar equipes a examinar como a linguagem, a organização de componentes e os sistemas de design se conectam à experiência digital. Esse trabalho pode começar pela identificação de termos ambíguos, duplicações e padrões difíceis de manter, avançando para critérios de nomenclatura e formas de documentar as decisões. A escolha do escopo depende das necessidades de cada produto: desde revisar rótulos de interface até organizar uma biblioteca e aproximar os vocabulários de design, tecnologia e produto. Com uma abordagem colaborativa, a equipe pode tornar seus nomes mais compreensíveis e facilitar a evolução do trabalho ao longo do tempo.