Nomeando componentes de um Design System

Eu não sei vocês, mas pra mim, sempre foi uma dor dar nome a componentes. Principalmente aqueles organismos mais complexos. Pensando nisso e também, cansado de ficar pensando em nomes do além, eu elaborei uma proposta de abordagem que segue a seguinte estrutura:

[Definição atômica] + [Estrutura do componente] + [Contexto] + [Variação e/ou modificadores]

Abaixo, o passo a passo e o conceito de cada parte da estrutura. No final tenho conclusões ao aplicar no dia-a-dia e um bônus de como usamos o ChatGPT como nosso aliado.

Primeiro: Declarar o que de fato é um Átomo, Molécula e um Organismo

Aqui no Bmg, o Design System foi construído com base no Atomic Design, e apesar do que a literatura diz sobre as definições atômicas, é comum no dia-a-dia me ver olhando com cara de dúvida pra um componente, aparentemente complexo e tentando chegar em uma definição…

É uma Molécula ou é um Organismo esse trem aqui? 🤔

Quem nunca, né.

Bom. Então para chegar em uma proposta de lógica de Nomeação de componentes o meu primeiro passo foi tentar deixar declarado o que é cada coisa e ficou assim:

Átomo (Atom): Elemento básico, como botões, ícones ou texto. Menor unidade funcional estilizada.

Molécula (Molecule): Combinação de átomos formando um componente funcional como campos de formulários e listas.

Organismo (Organism): Conjunto complexo de átomos e moléculas formando uma seção completa e funcional.

Exemplos de Átomos, Moléculas e Organismos

Segundo: Abordagem descritiva Contextual e Literal

Após a definição atomica, adicionar uma pitada de descrição. Ai ficou a dúvida, ser literal ou contextual? Descrever exatamente o que estou vendo ou descrever seu contexto de uso? Fui entender vantagens e desvantagens de ambos mas no final optei por somar as abordagens.

Exemplo de componente com nome Contextual

Contextual: Explica o propósito e uso do componente em um contexto específico ou cenário.

Exemplos:

• SearchInput: Um campo de entrada de texto projetado especificamente para pesquisar conteúdo;
• ProductCard: Um cartão que exibe informações e ações relacionadas a um produto em uma loja online;
• NavigationMenu: Um menu de navegação que inclui links e funcionalidades para navegar pelo site ou aplicativo.

Exemplo de componente com nome Literal

Literal (Estrutural): Detalha a estrutura e os elementos visuais do componente sem considerar seu contexto de uso.

Exemplos:

• PrimaryButton: Um botão com estilo principal, independente de sua função específica.
• CardWithImage: Um cartão genérico que contém uma imagem, um título e um subtítulo.
• Header: Um cabeçalho genérico que pode ser usado em várias páginas ou seções de um site.

Vantagens e desvantagens de cada abordagem descritiva:

Vantagens da abordagem CONTEXTUAL

Clareza de propósito: Os nomes baseados em descrição contextual indicam claramente a função e o uso específico do componente, facilitando o entendimento de sua aplicação.

Facilita a manutenção: Quando um componente tem um nome baseado no contexto, é mais fácil identificar onde ele é usado e como deve ser atualizado ou corrigido.

Promove a reutilização: Componentes nomeados de acordo com seu contexto podem ajudar a equipe a identificar rapidamente onde um componente pode ser reutilizado em cenários semelhantes.

Desvantagens da abordagem CONTEXTUAL

Especificidade excessiva: Pode limitar a reutilização do componente em outros contextos ou situações que não estejam claramente relacionados ao nome.

Nomenclatura mais longa: Os nomes podem se tornar mais longos e complexos, especialmente se incluírem detalhes funcionais e de contexto.

Dificuldade na padronização: Pode ser mais difícil padronizar nomes de componentes quando o foco é no contexto, levando a inconsistências na nomenclatura.

Vantagens da abordagem LITERAL

Flexibilidade: Os nomes baseados na descrição literal focam na aparência e na estrutura do componente, permitindo que ele seja usado em diversos contextos e propósitos.

Consistência visual: Componentes nomeados com descrições literais ajudam a manter a consistência visual em todo o design system, já que focam na aparência em vez do uso específico.

Simplificação: Ao focar na estrutura e no estilo, os nomes baseados em descrição literal podem ser mais simples e fáceis de entender, sem a necessidade de conhecer o contexto em que o componente é usado.

Desvantagens da abordagem LITERAL

Ambiguidade de propósito: Os nomes podem não transmitir a função ou uso específico do componente, dificultando o entendimento de sua aplicação.

Falta de orientação de uso: Sem indicação de contexto, os desenvolvedores podem usar componentes de maneira inadequada ou inconsistente.

Inconsistências funcionais: Componentes com nomes baseados na descrição literal podem ter funções diferentes, mesmo que tenham uma aparência semelhante, levando a confusão.

Terceiro: Variações e modificadores.

Já sei qual é a categorização macro (definição atômica), já consigo visualizar o componente e onde devo usa-lo, mas, e se ele tiver variações muito semelhantes, como diferenciar? Aqui não teve muito segredo. Foi trazer a lógica de modificadores que já estamos acostumados. Variações e Modificadores.

Variações: Versões de um componente com características distintas, alterando estilo, layout ou funcionalidade para atender a diferentes casos de uso.

• buttonPrimary
• buttonSecondary
• buttonTertiary

Modificadores: Propriedades ou atributos aplicados a um componente para ajustar seu comportamento, estilo ou funcionalidade sem alterar sua estrutura básica (Left, Right, Sticky, Top, WithImage).

• buttonPrimaryIconLeft
• cardImageLeft
• HeaderSticky

Quarto e último: Aplicação

Imagem de tabela com exemplo de nome de componente + Listagem de exemplos de atributos

No exemplo abaixo, tudo que eu preciso fazer é selecionar e combinar cada atributo para chegar em uma proposta de nome:

Componente tipo Card que serve para identificar Nome de uma pessoa, cargo, foto e a opção de editar em forma de icone

[Definição atômica] +

• Atom
• Molecule 👈
• Organism

[Estrutura do componente] +

• Card 👈
• List
• Modal

[contexto] +

• Login
• Signup
• Profile 👈

[variação e/ou modificadores] +

• Light
• Compact
• Horizontal 👈

Nome final: MoleculeCardProfileHorizontal

Se fosse preciso, daria para combinar outros modificadores para trazer mais descrições, ou combinar descritivos pra deixar mais evidente contexto de aplicação ou formato.

No final, o grande objetivo é que só de ler o nome do componente você consiga imaginar como ele pode ser e como deve ser aplicado.

Aprendizados do dia-a-dia:

Levei essa abordagem para o time, discutimos e estamos aplicando. A seguir alguns aprendizados e até mudanças que já fizemos:

• Definição atômica não precisa estar presente no nome. Eu tinha pensando em incluir essa categorização pensando em facilitar a busca. Seja no código ou no Figma. Porém, em ambos locais, podemos usar outras estratégias para ter essas categorizações presentes, mas não necessariamente no nome do componente. O que diminui um pouco o tamanho do nome.
• O contexto de aplicação pode fazer mais sentido somente em organismos. Entendemos que aplicar descrição contextual em um átomo ou molécula logo na sua criação tem um risco dele ficar incompreensível muito rápido. Afinal, nem sempre temos ideia de todas as possíveis aplicações daquele componente. Diferente de organismo ou telas que geralmente já tem bem claro um contexto de uso.
• No flutter, modificadores dão nome as variações do componente. No nosso contexto os nossos componentes que tem variações, cada variação recebe um nome. O componente inicial, é uma variação que geralmente chamamos de standard. Exemplo: ProductBanner.standard. Se esse mesmo banner passar a ter outras varições, seja de tamanho ou até mesmo cor, é aí que entram os modificadores nomeando. Exemplo: ProductBanner.Small, ProductBanner.WithIcon. No Figma, o nome do componente fica sendo ProductBanner, e os modificadores viram propriedades.

Aprendizados do dia-a-dia:

Levei essa abordagem para o time, discutimos e estamos aplicando. A seguir alguns aprendizados e até mudanças que já fizemos:

• Definição atômica não precisa estar presente no nome. Eu tinha pensando em incluir essa categorização pensando em facilitar a busca. Seja no código ou no Figma. Porém, em ambos locais, podemos usar outras estratégias para ter essas categorizações presentes, mas não necessariamente no nome do componente. O que diminui um pouco o tamanho do nome.
• O contexto de aplicação pode fazer mais sentido somente em organismos. Entendemos que aplicar descrição contextual em um átomo ou molécula logo na sua criação tem um risco dele ficar incompreensível muito rápido. Afinal, nem sempre temos ideia de todas as possíveis aplicações daquele componente. Diferente de organismo ou telas que geralmente já tem bem claro um contexto de uso.
• No flutter, modificadores dão nome as variações do componente. No nosso contexto os nossos componentes que tem variações, cada variação recebe um nome. O componente inicial, é uma variação que geralmente chamamos de standard. Exemplo: ProductBanner.standard. Se esse mesmo banner passar a ter outras varições, seja de tamanho ou até mesmo cor, é aí que entram os modificadores nomeando. Exemplo: ProductBanner.Small, ProductBanner.WithIcon. No Figma, o nome do componente fica sendo ProductBanner, e os modificadores viram propriedades.

Exemplo de como o componente é visto no Figma

Exemplo de como componente é visto no Código (Imagem: Genesis Doc — site interno)

BONUS: Usando o chatGPT como ferramenta de dar nomes a componentes:

Primeiramente, todo esse estudo eu fiz com o apoio do chatGPT + meus anos de experiência. Ao final de toda a nossa conversa, brainstorming etc., eu pensei… bom, eu tenho claro na minha cabeça a estrutura pra dar nome a novos componentes, e o chat também, ainda com o bônus de ter um vocabulário muito mais extenso, logo…..:

Ei chat, agora que você já sabe todas as regras, estrutura e conceitos, sempre que eu te enviar uma descrição de componente, você me retorna sugestões de nomes para o mesmo…

Print de uma conversa com chatGPT. Pedindo sugestões de nomes para componentes.

Resultado: Agora eu tenho uma conversa fixa no chatGPT que chamo de NAMING-COMPONENTES e sempre que preciso de uma ideia vou consulta-lo.

Ah e serve não só para dar nome mas também para me ajudar a validar a definição atômica.

Espero que tenha gostado conteúdo. Fique a vontade para explorar no seu dia-a-dia essa abordagem.

Até a próxima :)