3 hábitos diários que me ajudam a expandir minha visão como design engineer

eu passava horas olhando pra interfaces bonitas e pensava “como esse cara chegou nesse nível?”

achava que era talento. que era dom. que tinha gente que nasceu sabendo compor layout e eu nasci sabendo centralizar div com margin auto.

não. é treino. é repertório. é fazer as coisas certas com consistência.

nos últimos anos eu desenvolvi 3 hábitos que mudaram completamente a forma como eu enxergo frontend. não são hacks. não são atalhos. são exercícios que expandiram minha visão como design engineer de um jeito que nenhum curso ou tutorial conseguiu.

e o melhor: qualquer dev pode começar hoje.

consumir referência com intenção

eu costumo começar o dia 1h antes do trabalho. preparo meu chá (sim, eu sou o cara do chá. já aceitei esse destino) e fico navegando por X/Twitter, Layers, Design Spells, Dribbble.

basicamente qualquer lugar onde tem gente boa postando UI.

mas não é scroll aleatório. é um exercício. parece scroll aleatório pro meu chefe se ele me vir, mas é um exercício.

vou te dar um exemplo: digamos que eu parei em uma tela que tem um avatar group. em vez de só pensar “bonito” e dar like, eu paro e tento destrinchar aquilo.

como esse layout funciona? como os avatares se sobrepõem? se eu fosse codar isso agora, como eu estruturaria?

no começo você talvez vai pensar em position: absolute com margin negativa pra tudo. e tá tudo bem. todos nós já passamos por essa fase. alguns nunca saíram. sem julgamento.

o ponto é que com o tempo esse exercício fica automático. você começa a olhar pra qualquer interface e já entende a lógica por trás. inclusive quando não deveria, tipo quando você tá no app do banco e em vez de pagar o boleto fica analisando o border-radius dos cards.

o objetivo não é copiar nada. é treinar seu olho pra ler interface do mesmo jeito que você lê código. entender o porquê aquilo faz sentido visualmente.

a diferença entre um dev que implementa layout e um design engineer que cria interface começa exatamente aqui. na intenção com que você consome o que vê todo dia.

praticar animação fora do código

eu sei que isso soa sem sentido. “po eu sou dev, se eu não to codando a animação por que eu iria pro After Effects?”

era exatamente o que eu pensava. até eu entender que o problema nunca foi o código. era eu não saber como uma boa animação deveria parecer. eu ficava botando transition: all 0.3s ease em tudo e achava que tava abafando.

o exercício é simples: instala o After Effects ou abre o LottieLab, pega qualquer componente do Figma que você tem guardado, exporta e começa a brincar. keyframes, curvas de easing, momento, timing.

sem tutorial. sem querer finalizar nada. só experimenta.

você começa a entender por que um ease-in-out funciona aqui mas não ali. por que 200ms é melhor que 400ms naquele contexto.

e aí quando você volta pro código, você para de chutar valores. para de botar 400ms de ease-out num hover de dropdown menu. eu fazia muito isso. ficava um dropdown descendo em câmera lenta como se fosse uma cena dramática de novela. ninguém merece.

parece besta. mas é o tipo de coisa que faz alguém usar teu produto e sentir que tem algo diferente ali. sem saber explicar o quê.

aquela sensação de “isso aqui é polido” nunca vem do código. vem de alguém que entende timing.

ler código de quem você admira

por muito tempo eu ficava olhando pra interface de certos projetos e pensava “como esse cara chegou nesse nível de componente?”

comecei a perguntar pra gente que eu acho muito boa em frontend. “como você pegou esses patterns de construção, essa forma de organizar componente?”

e a resposta da maioria foi basicamente a mesma: lendo código da galera que eles achavam fora da curva.

nada de curso secreto. nada de bootcamp mágico. literalmente abrindo GitHub e lendo código como quem lê livro antes de dormir. sim, a gente é esse tipo de pessoa.

o João por exemplo me disse que aprendeu muito sobre criação de componentes e melhores práticas pra React estudando o código do Radix. no meu caso a virada veio olhando o cmdk do Paco Coursey e o repo do Supabase.

você abre o código, começa a navegar, e de repente dá aquele clique: “ah é assim que resolve isso.” é tipo descobrir que a tampa do pote abre pro outro lado. muda tudo.

você não precisa inventar tudo do zero. as melhores decisões de código que eu já tomei vieram de estudar como alguém que eu admiro resolveu o mesmo problema.

algumas pessoas que eu admiro e que já aprendi muito acompanhando: pqoqubbw, Diego Haz, John Phamous, entre outros.

o que muda depois de 3 meses

esses 3 hábitos não são revolucionários. não são segredo. a maioria das pessoas que eu admiro em frontend faz alguma versão disso.

a diferença é consistência.

faz essas 3 coisas por 3 meses e a forma como você olha pra interface muda. você para de ser o dev que implementa tela e vira o dev que entende interface.

e essa diferença, no mercado de hoje, vale mais do que qualquer framework novo. inclusive aquele que lançou semana passada que você já tá querendo migrar tudo pra ele.