Gramática do movimento: quando a animação merece seus quadros

A maior parte da animação de interface é decoração usando o crachá de uma função. O teste que eu aplico é direto: se você não consegue explicar o que uma animação diz ao usuário, ela não merece seus quadros; apague. O que sobrevive a esse teste acaba sendo uma gramática enxuta: quatro faixas de duração, duas regras de easing e um punhado de tarefas que o movimento realmente faz melhor do que uma mudança estática. Todo o resto é um designer se divertindo às custas do usuário, dezesseis milissegundos por vez. {.answer-block}

Em resumo

• Ou o movimento é informação, ou é ruído. As tarefas legítimas: mostrar de onde algo veio ou para onde foi, confirmar que uma ação foi registrada, dirigir a atenção durante uma mudança e mascarar a latência inevitável. Qualquer outra coisa, corte.
• Quatro faixas de duração cobrem a interface inteira: ~100ms para toques e chaves, 150-200ms para hovers e fades, 250-300ms para expandir e recolher, 300-400ms para transições de página e modais.
• Duas regras de easing cobrem as entradas e as saídas: ease-out para tudo que entra, ease-in para tudo que sai. Elementos que se deslocam sem sair da tela usam ease-in-out; linear fica para barras de progresso e fades puros.
• O teste de exclusão vale mais que o teste do gosto. “Fica agradável?” mantém a má animação viva; “o que isso diz ao usuário?” a mata.
• Trate prefers-reduced-motion como um requisito de primeira classe, não como algo pensado no fim: a gramática precisa degradar para mudanças de estado instantâneas e continuar fazendo sentido.

Movimento é uma frase, não um clima

Uma animação de interface é uma afirmação sobre causalidade: este painel veio daquele botão; este item saiu para aquela lista; esta mudança aconteceu porque você agiu. Quando o movimento carrega uma dessas afirmações, o modelo mental do usuário se atualiza de graça, sem leitura e sem raciocínio. Quando não carrega nada, o usuário espera a coreografia terminar antes de poder seguir em frente, e cada espera é um pequeno imposto sobre a confiança.

Esse enquadramento produz a lista prática de tarefas que o movimento de fato tem:

1. Continuidade espacial: de onde isto veio, para onde foi. O card que se expande, a folha que sobe a partir do seu gatilho, a linha excluída que se recolhe em direção ao ícone de arquivo.
2. Confirmação: seu toque foi registrado. O afundamento do botão em 100ms, o giro da chave, o tique da caixa de seleção.
3. Condução da atenção: durante uma mudança de estado, a única coisa que se moveu é a única coisa que mudou. O movimento está entre os sinais de atenção mais fortes que uma interface consegue emitir, e é exatamente por isso que o movimento imerecido sai tão caro.
4. Máscara de latência: o brilho do esqueleto de carregamento, a troca otimista, a revelação progressiva que faz 400ms de requisição parecerem intencionais em vez de quebrados.

Se uma animação na sua tela não está fazendo uma dessas quatro tarefas, está fazendo a quinta: se exibir.

As quatro faixas de duração

Durações não são gosto; são física ajustada à atenção. Estas são as faixas às quais submeto toda interface:

O padrão por baixo disso: a duração acompanha o tamanho da mudança. Um controle que confirma um toque precisa ser quase instantâneo; passados uns ~150ms, a confirmação é lida como lentidão. Uma transição em tela cheia ganha mais tempo porque o usuário precisa dele para se reorientar. A falha mais comum é a inversão: botões quicando por 400ms (lentidão disfarçada de encanto) e modais que estalam em 100ms (desorientação disfarçada de velocidade).

Passados os 400ms, o movimento de interface precisa de uma razão excepcional para existir. Momentos de onboarding e estados de comemoração merecem eventualmente 500-600ms; a navegação na escala do celular quase nunca, embora as transformações de contêiner em telas grandes sejam a exceção honesta: superfícies de tablet e de desktop legitimamente se esticam rumo aos 500ms porque o olho tem mais caminho a percorrer. O usuário executa a sua transição milhares de vezes, e a coreografia que encantou na demonstração é o atrito que ele xinga na terceira semana.

Sistemas baseados em molas (SwiftUI, Framer Motion) expressam o tempo como rigidez e amortecimento em vez de durações fixas, mas as faixas continuam valendo: elas descrevem o tempo de acomodação percebido para o qual você ajusta. A gramática sobrevive à troca de notação.

Duas regras de easing

O easing é onde a animação adquire física, e duas regras cobrem quase tudo:

Ease-out para o que entra. Elementos que chegam à tela começam rápido e desaceleram até o lugar: eles pousam. O ease-out concentra o movimento no início, então o olho pega o destino cedo e o elemento parece responsivo.

Ease-in para o que sai. Elementos que partem aceleram ao se afastar: saem com intenção. O começo lento dá ao olho um instante para registrar que algo está indo embora antes que suma.

O easing linear é lido como mecânico porque nada no mundo físico se move assim; reserve-o para indicadores de progresso, onde a taxa constante é a informação, e para fades puros de opacidade ou cor, onde nada percorre distância e não há movimento para uma curva moldar. Já o ease-in-out simétrico pertence ao terceiro caso que as duas regras deixam de fora de propósito: elementos que se deslocam sem sair da tela, como uma linha que muda de posição ou um painel que muda de tamanho. Eles não pousam nem saem, então aceleram a partir do repouso e voltam a se acomodar nele. Onde o ease-in-out conquista sua má fama é como padrão nunca questionado em entradas e saídas, porque ali ele deixa as chegadas arrastadas e as partidas abruptas ao mesmo tempo.

O teste de exclusão na prática

O procedimento de revisão que mantém um sistema de movimento honesto:

1. Faça o inventário de cada animação da superfície, incluindo os padrões do framework que ninguém escolheu deliberadamente.
2. Para cada uma, complete a frase: “Este movimento diz ao usuário ___”. Origem espacial, confirmação, atenção, latência: uma das quatro, em palavras simples.
3. Tudo que ficar em branco continua em branco depois da discussão. “Dá um acabamento” e “parece premium” são lacunas com vocabulário melhor. Apague o movimento e olhe para a superfície por um dia; o acabamento que só existia no movimento nunca foi acabamento.
4. Cronometre o que sobreviveu contra as faixas, corrija os easings e teste o caminho de movimento reduzido. prefers-reduced-motion precisa produzir uma interface plenamente coerente feita de mudanças de estado instantâneas; se remover uma animação quebra a compreensão, essa animação carregava informação que deveria existir também de forma estática, o que já é uma constatação por si só.

Rode isso em um produto maduro e normalmente metade do inventário morre. Uma lista de baixas representativa de uma única passada: a elevação no hover de 400ms nos cards (não diz ao usuário nada que uma mudança de cursor já não dissesse), a entrada escalonada da lista repetida a cada navegação (600ms para anunciar “temos linhas”), o ícone de salvar que pulsa (atenção reivindicada, nada mudou para ser observado). Ninguém sente falta delas. O que resta fica mais rápido, mais consistente e, paradoxalmente, mais perceptível, porque o movimento recupera seu valor de sinal no instante em que deixa de ser ambiente.

A visão de sistema

Em um design system, o movimento mora em tokens exatamente como o espaçamento e a cor: durações nomeadas (--motion-press: 100ms, --motion-surface: 300ms), easings nomeados (--ease-enter, --ease-exit) e componentes que consomem tokens em vez de inventar tempos na marra. O modo de falha do movimento não sistematizado não é a feiura, é a deriva: cinco modais com cinco durações, cada uma defensável, incoerentes em conjunto. A mesma disciplina que governa uma escala de espaçamento governa uma escala de movimento: todo valor vem do sistema ou carrega uma razão documentada.

O movimento é também a camada mais perecível de um design system, aquela em que os colaboradores improvisam por conta primeiro, porque um tween avulso de 250ms parece inofensivo. E é inofensivo, onze vezes, e então o produto pisca com onze sotaques de movimento desmotivado. A gramática só se sustenta enquanto o teste de exclusão continuar rodando.

Perguntas frequentes

Quanto devem durar as animações de interface?

Ajuste a duração ao tamanho da mudança: ~100ms para a confirmação de um controle (toques, chaves), 150-200ms para hovers e fades, 250-300ms para expandir e recolher, 300-400ms para transições de página e modais. Acima de 400ms é preciso uma justificativa excepcional: os usuários repetem as transições de interface milhares de vezes.

Que easing as animações de interface devem usar?

Ease-out para elementos que entram (início rápido, desaceleração até o lugar), ease-in para elementos que saem (aceleram ao se afastar) e ease-in-out para elementos que se deslocam sem sair da tela. Reserve linear para indicadores de progresso e fades puros de opacidade ou cor. Nas entradas, linear soa mecânico e ease-in-out deixa as chegadas arrastadas: ease-out é a regra.

Quando uma interface deve usar animação?

Quando o movimento carrega informação que uma mudança estática não consegue carregar: continuidade espacial (de onde algo veio ou para onde foi), confirmação de uma entrada, condução da atenção para o que mudou ou máscara de uma latência inevitável. Se você não consegue dizer qual dessas tarefas uma animação cumpre, remova: movimento decorativo tributa cada interação que toca.

Como prefers-reduced-motion se encaixa em um sistema de movimento?

Como um requisito de primeira classe: o caminho reduzido troca o movimento por mudanças de estado instantâneas, e a interface precisa continuar plenamente compreensível. Se remover uma animação quebra o entendimento, o movimento carregava informação que precisa de um equivalente estático: uma constatação de acessibilidade e uma constatação de design ao mesmo tempo.