Atomicidade espelhada: designers e desenvolvedores falando a mesma língua
Como aplicar a mesma estrutura de componentização do design ao código
O conceito de atomicidade no design e desenvolvimento front-end já é bem explorado, mas o problema é o seguinte:
designers e front-ends tendem a criar estruturas de componentização diferentes entre si.
Um dia me peguei pensando porque a estrutura atômica do meu layout era diferente daquela utilizada no front-end do mesmo projeto. Bateu um momento eureka e o termo atomicidade espelhada me ocorreu.
Na hora achei que tinha todas as respostas para resolver esse problema, mas não estava nem perto disso… Este artigo trata dos fracassos, sucessos e boas práticas em torno de minhas experiências ao aplicar esta ideia no dia a dia de um time em um produto real.
Premissas que segui
Para explorar essa ideia, parti de alguns pontos:
- Design atômico é uma coisa boa;
- “Espelhar a estrutura” é uma ideia, não uma meta de vida ou morte. O mais importante é essa lógica se manter viva durante o processo;
- Tanto designers quando front-ends estão acostumados a componentizar coisas. Seja com símbolos, variáveis, web components ou outro método;
Nesse contexto o Sketch é o software mais preparado para o trabalho de UI (UPDATE: já não acho isso. O Figma, por exemplo é outra ótima opção é o Incisional Studio também tem muito potencial.)
- Comunicação é fundamental, especialmente entre os profissionais diretamente envolvidos em um projeto.
Meu ponto de vista sobre atomicidade
As bases do design atômico estavam aí antes do Brad Frost e você deveria entender como tirar proveito desse conceito em seu dia a dia.
Design atômico não é uma técnica, nem uma metodologia. É um conceito: componentizar uma coisa, do menor para o maior elemento.
Mesmo em plataformas diferentes (editor de código x editor de imagem), é possível melhorar o alinhamento entre design e código aplicando o mesmo conceito e, a partir daí, uma árvore hierárquica e controles equivalentes.
Todo designer ama trabalhar com símbolos e desenvolvedores já componentizavam coisas antes de você ter aberto o Photoshop pela primeira vez. Mas, será que ainda tem espaço pra você melhorar? Sempre tem :)
Não vou me estender, já que o assunto não é novidade, mas quero deixar claro porque considero parte fundamental do processo de UI:
Consistência
Componentes bem definidos não deixam margem para problemas de consistência não importa quantas telas seu projeto tenha.
Flexibilidade
Pode soar contraditório a lógica de componentes “fixos” gerarem flexibilidade, mas tenho uma palavra pra você: LEGO.
Velocidade
Uma vez estruturada sua gama de componentes, a construção de novas telas fica incrivelmente mais rápida (coisa de uns 80% pela minha experiência pessoal).
Controle
Uma estrutura atômica implica naturalmente no aumento do controle em escala. Se um ícone é um quark, alterando ele você altera até mesmo os elementos mais complexos como moléculas ou páginas.
Para referência, no momento utilizo mais ou menos a proposta sugerida pelo Suissa composta por Bósons e Quarks além de Átomos, Moléculas, Organismos, Templates e Páginas.
É só um botão…
Como cada um enxerga o mesmo elemento?
No front ele pode ser um átomo, com propriedades controladas através de quarks (ícones, fontes…) e bósons (cores, tamanhos, media queries, alturas, alinhamentos…) ou algo assim.
UPDATE: O Henrique Perticarati comentou a dificuldade que algumas pessoas podem ter na hora de interpretar essas metáforas com elementos da física. Não é meu objetivo retrabalhar a ideia do Brad Frost, mas você pode pesquisar mais sobre isso por aqui.
A ideia geral é ir do menor elemento pro maior, não porta muito se a analogia é com química, física, um sanduíche ou um motor de carro… ;)
No design ele é um símbolo. Em um workflow habitual, suas variações não vão além de cópias com cores alteradas manualmente gerando novos símbolos. Você poderia evoluir isso, aplicando esquemas de overrides de símbolos e textos, mas ainda assim, sem que haja uma estrutura atômica clara isso não tem tanto valor.
Essa dicotomia impede que o processo de trabalho entre fronts e designers seja totalmente fluido.
É como se fronts e designers falassem o mesmo idioma, mas com sotaques bem diferentes. Dá pra entender o outro, mas seria bem mais fácil se todo mundo falasse do mesmo jeito.
Fazendo o exercício de espelhar a estrutura do front-end, você pode chegar a alguma coisa parecida com isso:
Atomicidade espelhada
Seguindo a mesma estrutura atômica do layout até o front-end.
A teoria é simples:
Se UI e código seguirem a mesma estrutura de componentização isso irá diminuir atritos entre designer e desenvolvedores front-end.
O termo espelhada vem exatamente do princípio de seguir as mesmas regras de estrutura, nomenclaturas, variáveis, etc. Tenho pregado esse conceito há algum tempo, mas a verdade é que aplicá-lo é bem mais difícil do que eu pensava quando ele me veio a cabeça…
O caminho que tenho seguido:
ABERTURA
Entenda a estrutura do código e do design
Converse com seu amigo front e peça para ele expor o modo como trabalha ou como poderia trabalhar (caso já não o faça) em um cenário ideal (e atômico).
Entenda na prática o que seriam quarks, bósons, átomos, moléculas, templates, páginas e seja lá qual outra estrutura poderiam criar para resolver um problema real.
Escute de coração aberto os problemas que um dev encontra quando recebe um layout mal feito e as sugestões de como esse processo poderia melhorar.
INTELIGIBILIDADE
Fale a mesma língua
A partir de agora, quando você desenhar um retângulo novo que seja, é preciso saber que o nome do layer fará mais diferença que nunca! Um botão que já era um símbolo em seu arquivo de Sketch, agora precisa ser nomeado seguindo a mesma nomenclatura de classes (ou equivalente) de seu código.
Então, se você chamava um botão de “button”, mas a classe dele era “btn” trate de ajustar isso.
ADEQUAÇÃO
Estruture seu arquivo
Eu uso o Sketch para desenhar interfaces, o que não significa nada. Tem uma geração de novas ferramentas despontando por aí e qual delas será a sua escolha realmente é o que menos importa. O papo aqui é conceitual.
Dito isso, acredito que o Sketch é aquela dentre todas que está mais preparada para suportar a lógica da atomicidade espelhada. Isso porque tem um mix de plugins e funções nativas que ajudam no processo de montar um arquivo gráfico que se assemelha o máximo possível a um código.
No meu caso, foi preciso criar um novo design system e estudar novas formas de desenhar elementos de forma a se manter o mais perto possível do que rola no código. Foi difícil pra caramba… No fim, isso representou um salto técnico entre os designers e isso por si só já valeria o esforço todo :)
Obs.: Menção honrosa ao Subform que tem um esquema bem legal de armazenar estados de um elemento no próprio e que também utiliza explicitamente controles de estilo em cascata (CSS).
EVOLUÇÃO
Compartilhe o conhecimento
Uma vez terminado o trabalho hercúleo de criar arquivos alinhados em nível atômico, não deixe essa metodologia morrer com você!
Documente tudo, exponha o case dentro do seu time e empresa, fale em meetups sobre seus fracassos e sucessos durante esse processo. Só assim poderemos amadurecer o conceito juntos!
UPDATE: O Macgyver acrescentou uma vantagem nesse processo e achei um ótimo ponto de vista:
PREVISIBILIDADE
Quando o designer consegue estar me mesma realidade que o desenvolvedor front-end, e vice-versa, é mais fácil para ambos terem uma noção melhor da task e assim quebrá-las para que fiquem no mesmo “tamanho”. Com task mais padronizadas em termos de complexidade/dificuldade, é mais fácil estipular metas com expectativas de entregas.
Aplicando atomicidade no design
Pra ser sincero, tenho evoluído esse pensamento diariamente conforme encontramos problemas técnicos.
De novo: isso é uma ideia em desenvolvimento.
Se quiser contribuir com sugestões, comenta aqui no artigo! :)
Pessoalmente utilizo o Sketch e alguns plugins mão na roda como o Auto Layout e Sketch Runner.
Por padrão, utilizo a primeira letra de cada camada atômica na nomenclatura dos elementos dentro do sketch. Isso é apenas uma convenção minha. B para Bóson, A para Átomo, M para Molécula e assim por diante.
Bósons
Em geral, bósons refletem modificações em outros elementos, por exemplo:
- uma cor de um texto;
- um border radius em um botão;
- o tamanho ou alinhamento em um texto…
Por isso, a presença dos bósons no arquivo gráfico se dá especialmente nos painéis de ajustes.
Tendo chegado em uma especificação de comportamento (se o símbolo é fluído, se o texto é alinhado ao centro e em negrito, etc.) salve isso em estilos que reflitam estas especificações. Não se esqueça de ser fiel as mesmas nomenclaturas utilizadas no nível do código.
Exemplos de bósons modificando textos:
- parágrafo/bold (onde “bold” é o bóson e se refere ao negrito do estilo de texto parágrafo)
- link/secundário (onde “secundário” é o bóson e se refere a cor e underline aplicados ao estilo de texto para links no rodapé do site)
- H2/center (onde “center” é o bóson e se refere ao alinhamento do texto)
Exemplos de bósons modificando símbolos:
- A/btn/small (onde small é o bóson e se refere as dimensões estáticas do botão, em pixels)
- M/card/danger (onde danger é o bóson e se refere a cor vermelha na caixa de alerta)
Quando pensamos em cores, o Sketch ainda não suporta o uso de cores como variáveis que afetam vários aspectos do arquivo.
Para modificar a cor em símbolos, costumo criar símbolos de cores que são apenas quadrados com uma cor aplicada. A partir daí, aplico overrides de símbolos para alterar cores específicas em elementos.
Exemplo 1: Bósons como cores
Que utilizo para modificar um botão (que é um átomo):
Exemplo 2: Bósons que controlam tamanho, margem e alinhamento de um botão
Neste caso, não existe um bóson em forma de símbolo. Ele está contido nos ajustes do átomo e poderia estar refletido na nomenclatura do mesmo símbolo.
Quarks
São os elementos mais simples do contexto. Não existem “sozinhos” em um layout.
- um ícone;
- famílias tipográficas…
Exemplo: Quark como ícone
Que aplico em um botão (que é um átomo):
Átomos
- um botão
- uma foto do usuário em uma máscara redonda
- inputs de texto…
Moléculas
- um card
- uma barra de busca…
Isso é uma molécula (tabela dummy):
Essa é a mesma tabela depois de trocar símbolos e texto:
Organismos
- o topo de um site;
- um rodapé;
- uma sidebar…
Templates
- uma tela de resultados de busca;
- home page;
- telas do fluxo de compra…
Página
É um template com conteúdo real, incluindo imagens, estilos, textos, etc.
Mão na massa!
A teoria é linda, né? Colocar em prática ainda é meio difícil por conta da lógica sobre a qual os softwares disponíveis foram construídos.
O Photoshop mesmo nasceu com um propósito, abraçou o mundo, inchou, ficou pesado pra caramba, lançou artboards, etc… O Adobe XD é incrível e tem potencial, mas ainda não está com tudo que eu preciso para trabalhar, por exemplo.
Sketch é ótimo por ser aberto a modificações na camada de plugins. Isso é poderoso. Além disso já divulgaram que na versão 43 vão meio que abrir o código do arquivo que será um JSON exportável (resumi a ideia).
Tem Figma, Subform e mais uma galera vindo por aí. Todo mundo atacando mais ou menos o mesmo nicho. No que vai dar eu não sei!
Se você for tentar implementar a atomicidade espelhada, fala pra mim o que aconteceu! Estou bastante interessado em saber dos fracassos e sucessos de outros times.
Última coisinha…
O que me motiva a escrever é saber que alguém gostou do que leu. Então dá um ♥ se você viu alguma coisa que te fez refletir um pouco sobre algo novo :)
