De motion designer a Tech Lead: o que o audiovisual me ensinou sobre código
Uma reflexão sobre como mais de 10 anos em motion design moldaram meu jeito de escrever software.
Entre 2008 e 2021, eu vivi de frame por frame.
Meu trabalho era animar logotipos, construir aberturas de vídeo, criar motion graphics para marcas que precisavam de movimento com intenção. Cada projeto começava na mesma pergunta: o que esse frame precisa comunicar antes do próximo?
Essa pergunta que parece ser sobre design, na verdade é sobre timing, prioridade e clareza. Coisas que ninguém te diz que são exatamente as mesmas que você precisa responder quando está projetando um sistema de software.
O olhar que o motion design desenvolve
Quando você trabalha com animação, aprende a perceber o intervalo entre dois estados. Não o estado inicial nem o final, o que acontece entre eles.
Em código, esse intervalo existe em todo lugar. É a transição de um estado de UI para outro. É o que acontece entre uma requisição e uma resposta. É o espaço entre o que o usuário clicou e o que o sistema processou.
Motion designers treinam o olho para esse espaço. E quando você entra no desenvolvimento com esse olhar, começa a construir software que sente melhor, mesmo sem saber explicar por quê tecnicamente.
Hierarquia visual virou hierarquia de dados
Na animação, hierarquia visual é tudo. O que aparece primeiro? O que tem mais peso? O que o olho deve seguir?
Quando comecei a desenhar APIs e estruturas de banco de dados, percebi que estava fazendo as mesmas perguntas. O que é mais importante nessa resposta? O que o cliente vai precisar primeiro? Como eu organizo esses dados para que o consumo seja óbvio?
Designers de motion aprendem a guiar atenção. Engenheiros de dados aprendem a guiar consumo. No fundo, o problema é o mesmo.
O que quebrou a transição
Não foi fácil. Durante quase um ano, me senti como alguém que aprendeu a falar uma língua nova mas ainda pensa na antiga.
Eu entendia os conceitos, conseguia resolver os problemas — mas era lento. O código que eu produzia era funcional, mas não tinha a fluidez que eu via nos devs mais experientes. Faltava o reflexo.
O que mudou foi quando parei de tentar aprender a programar e comecei a tentar construir coisas reais. Projetos com deadline. Projetos com usuários. Projetos onde importava se funcionava.
O ambiente real é o único professor que não dá pra substituir.
O que trouxe do outro lado
Hoje, quando olho para o código que escrevo, vejo claramente o que veio do motion design:
Atenção a estados intermediários. Loading states, transições de UI, feedback visual. Eu me importo muito com isso. Não é decoração, é comunicação.
Obsessão com timing. Quando uma animação demora 200ms ou 400ms importa. Da mesma forma, quando uma query leva 200ms ou 2s importa. O usuário sente a diferença, mesmo que não consiga nomear.
Narrativa no código. Toda função conta uma história. Começo, meio, fim. O que entra, o que transforma, o que sai. Quando o código não tem essa narrativa, ele é mais difícil de ler mesmo que funcione.
Por que estou escrevendo isso
Não escrevo isso pra romantizar uma trajetória não-linear. Trajetórias não-lineares têm custos reais, tempo, renda, credibilidade no mercado.
Escrevo porque acredito que o que você construiu antes importa mais do que parece. Não como currículo. Como forma de pensar.
Se você está migrando de área para desenvolvimento, a pergunta não é “o que eu sei que vai ajudar aqui?” — é “como eu vejo o mundo de um jeito que a maioria dos devs não vê?”
Essa resposta é o seu diferencial. E ela não fica desatualizada.