1.1 O que o movimento faz por uma interface

1.2 O custo do movimento

• Tempo: toda animação adiciona latência percebida. Uma transição de 500ms repetida 40 vezes ao dia é 20 segundos de espera imposta.
• Distração: movimento na periferia rouba atenção involuntariamente — bom para alertar, péssimo para deixar ligado.
• Enjoo: parallax, zoom e movimento grande podem causar desconforto vestibular em parte real da população (Módulo 9).
• Custo técnico: animação mal feita causa jank (queda de frames) e gasta bateria.

1.3 Os quatro tempos do motion em produto

• Micro-interações (Módulo 6): resposta imediata a um toque — 100–200ms.
• Transições de estado: um elemento muda (abre, expande, some) — 200–300ms.
• Transições de tela/rota (Módulo 4): navegação — 250–400ms.
• Momentos expressivos: onboarding, sucesso, estado vazio — podem durar mais, porque a espera é a experiência.

2.1 De Disney para o produto

Os "12 princípios" (Johnston & Thomas, The Illusion of Life) foram escritos para personagens desenhados. Alguns são a base do motion de UI; outros quase não se aplicam.

2.2 Os princípios de UI (Material Motion e afins)

• Informativo: o movimento diz de onde algo vem, para onde vai, e o que se relaciona com o quê.
• Focado: dirige a atenção sem distrair; um elemento em movimento por vez.
• Expressivo: reforça a marca e o "toque" do produto — mas por último, depois de informativo e focado.
• Consistente: a mesma classe de mudança usa a mesma duração e easing em todo o produto (motion tokens, Módulo 9).
• Rápido: a animação nunca deve fazer o usuário esperar por algo que já poderia estar pronto.

3.1 Duração

• Maior/mais distante = mais tempo. Um elemento que atravessa a tela leva mais que um que se move 8px.
• Saídas mais rápidas que entradas — o usuário já decidiu; não o faça esperar para "ir embora".
• Acima de ~400ms para interação comum, a UI começa a parecer lenta.

3.2 Easing (curvas de aceleração)

/* os quatro casos que resolvem quase tudo */
--ease-out:     cubic-bezier(0.0, 0.0, 0.2, 1);   /* entra: rápido → desacelera. O default. */
--ease-in:      cubic-bezier(0.4, 0.0, 1, 1);      /* sai: acelera → some */
--ease-in-out:  cubic-bezier(0.4, 0.0, 0.2, 1);    /* move de A para B, na tela o tempo todo */
--ease-standard: cubic-bezier(0.2, 0.0, 0, 1);     /* "emphasized" — mais caráter */

• linear é quase sempre errado para movimento (ok para opacidade pura e para progресso contínuo/spinner).
• Entrada → ease-out ("fast out, slow in"): o elemento chega com energia e assenta suave. É o mais natural e o mais usado.
• Saída → ease-in: acelera para fora.
• Mover algo que permanece visível → ease-in-out.
• Overshoot / "back" (passar do ponto e voltar): use com muita parcimônia, só em momentos lúdicos.

3.3 Springs (molas)

• Em vez de duração + curva, uma spring é definida por stiffness (rigidez), damping (amortecimento) e mass — e a duração emerge da física.
• Vantagens: naturalidade, interrompibilidade (o usuário arrasta de novo no meio e a mola responde sem "pular"), continuidade de velocidade em gestos.
• Padrão em iOS, no Framer Motion, no React Spring. Para a maioria dos casos de UI, uma spring "sem bounce" (damping alto) parece um bom ease-out — a diferença aparece em gestos e interrupções.

3.4 A relação duração × distância × easing

Não existe "300ms é o certo". Um menu que desce 200px com ease-out em 250ms parece ágil; o mesmo menu em linear parece mecânico; em 500ms parece preguiçoso; movendo 600px em 250ms parece um borrão. Ajuste os três juntos, testando no device.

4.1 Enter / exit

• Fade: a mais neutra — "isto apareceu/sumiu". Boa para elementos sem posição forte (overlays, mensagens).
• Slide: carrega direção e origem — o menu vem da borda, a tela vem da direita. Diz "de onde".
• Scale: "isto cresceu a partir daqui" — bom para popovers e menus que emanam de um gatilho (ancorar a origem da escala no gatilho).
• Fade + move curto (8–16px): o combo mais usado para listas e cards — presença sem drama.

4.2 Shared element / hero transition

Um elemento que existe nas duas telas (a miniatura na lista → a imagem grande no detalhe) persiste e se transforma em vez de sumir e reaparecer. É a transição mais poderosa para continuidade: o usuário nunca "perde" o objeto de vista. Na web, a View Transitions API faz isso nativamente (Módulo 7).

4.3 Container transform

Um contêiner (um card, um FAB, uma barra de busca) cresce e vira a próxima superfície (a tela de detalhe, o formulário, a lista de resultados). O conteúdo antigo dá fade-out e o novo fade-in dentro do contêiner que se expande. Comunica "isto abriu daqui".

4.4 Stagger (cascata)

• Itens de uma lista/grade entram com um atraso incremental pequeno (20–50ms entre itens), não todos juntos.
• Dá ritmo e ajuda o olho a perceber que são itens separados.
• Limite o total: acima de ~8–10 itens, o stagger acumula e a última linha demora demais — corte o delay a partir de um ponto, ou anime só o que está na viewport.

4.5 Reveal, morph e parallax

• Reveal: um clip/máscara que "abre" o conteúdo (accordion, "ler mais") — anime a altura/clip, com o conteúdo em fade.
• Morph: uma forma vira outra (ícone hambúrguer → X; play → pause) — Módulo 6 da apostila Iconografia.
• Parallax: camadas em velocidades diferentes no scroll → profundidade. Efeito caro em atenção e em conforto — sutil, e desligado em prefers-reduced-motion.

4.6 Escolher pela mensagem

5.1 Um assunto por vez

Quando muitas coisas mudam ao mesmo tempo, o olho não sabe onde pousar. Coreografia é sequenciar: o que se move primeiro, o que espera, o que se move junto. A regra: em cada instante, deve haver um foco de movimento — o resto ou está parado, ou se move de forma discreta e subordinada.

5.2 Hierarquia de movimento

• Primário: o elemento sobre o qual a ação é (o card que você tocou, o painel que abre).
• Secundário: o que reage ao primário (o conteúdo ao redor que dá espaço, o backdrop que escurece).
• Terciário / ambiente: detalhes (um ícone que gira, uma sombra que cresce) — quase imperceptíveis.
• Dê ao primário mais deslocamento e mais "presença"; ao resto, menos.

5.3 Continuidade: o que persiste vs o que troca

• Identifique os elementos que existem antes e depois da transição (o header, a foto, o título) e faça-os persistir e se mover, nunca sumir e reaparecer.
• O que é novo entra; o que sai de cena sai — e idealmente na direção que faz sentido espacial.
• Isso é o "shared element" pensado no nível da tela inteira: um modelo espacial consistente (o app como um lugar por onde você se move).

5.4 Stagger e delays com intenção

• Stagger na ordem de leitura (de cima para baixo, do gatilho para fora), não aleatório.
• Delays para encadear: o painel abre (0ms) → o conteúdo dele entra (120ms depois, quando já há espaço) → o CTA pulsa (no fim).
• Cuidado com o tempo total: a soma de todos os delays não pode fazer a cena demorar > ~500–600ms para o essencial estar utilizável.

5.5 Interrupção e reversibilidade

• O usuário pode tocar de novo no meio da animação. A transição precisa ser interrompível e reversível — voltar do ponto atual, não "terminar e então reverter" (springs ajudam; Módulo 3).
• Nunca bloqueie a interface durante uma transição não essencial.

6.1 A anatomia (Dan Saffer)

• Trigger (gatilho): o que inicia — um toque, um hover, um evento do sistema (chegou mensagem), um limite atingido.
• Rules (regras): o que acontece e sob que condições.
• Feedback: o que o usuário vê/sente/ouve — a parte visível, e onde o motion entra.
• Loops & modes: a duração e o que muda ao longo do tempo (o botão "curtido" fica curtido; o "não perturbe" persiste).

6.2 Feedback imediato

• A resposta ao toque deve começar em < 100ms — abaixo disso é "instantâneo"; acima, parece travado.
• Estados de um controle: repouso → hover (ponteiro) → pressed (afunda, escurece, ripple) → foco (:focus-visible) → disabled → loading. Cada um com sua micro-transição (100–150ms).
• O pressed deve responder ao pointerdown, não ao click — feedback antes da confirmação.

6.3 Padrões comuns

6.4 O que uma boa micro-interação faz

• Confirma que a ação foi registrada (sobretudo antes de o resultado chegar).
• Comunica o estado resultante (ligado/desligado, curtido, enviado).
• Previne erro (o rubber band diz "chegou no limite"; o swipe pela metade volta).
• Dá um pequeno prazer — mas esse é o quarto objetivo, nunca o primeiro.

7.1 O que é barato animar

• Barato (compositor, sem recalcular layout): transform (translate, scale, rotate) e opacity. Anime só isso sempre que possível.
• Caro (dispara layout e/ou paint a cada frame): width, height, top/left, margin, box-shadow, filter pesado, background-position.
• Truques: para "animar largura", anime transform: scaleX() e contra-escale o conteúdo; para sombra, faça cross-fade entre duas camadas de sombra; para posição, translate, não top/left.
• will-change: transform avisa o navegador — use com moderação (cada camada custa memória) e remova depois.

7.2 CSS: transition, animation, @keyframes

.card{
  transition: transform 200ms var(--ease-out), opacity 200ms linear;
}
.card:hover{ transform: translateY(-4px); }

@keyframes slide-up{
  from{ opacity: 0; transform: translateY(12px); }
  to  { opacity: 1; transform: none; }
}
.enter{ animation: slide-up 240ms var(--ease-out) both; }

• CSS resolve a maioria das entradas/saídas, hovers e loops simples — sem JS.
• @starting-style e transition-behavior: allow-discrete permitem animar a entrada de elementos que aparecem (de display:none) e o popover/<dialog>.

7.3 FLIP

FLIP (First, Last, Invert, Play): para animar uma mudança de layout de forma barata — meça a posição First, aplique o estado Last, calcule a diferença e aplique um transform que Inverte (parece que nada mudou), depois Play removendo o transform com transição. Anima reordenações, "expandir para tela cheia", trocas de grid — usando só transform.

7.4 Web Animations API e bibliotecas

• WAAPI (element.animate(keyframes, options)): controle no JS (play/pause/reverse/seek, onfinish), performático, sem dependência. Bom para coreografia dinâmica.
• Motion One / GSAP: timelines, sequenciamento, easing avançado, plugins (morph, scroll). GSAP é o padrão para motion complexo.
• Framer Motion (Motion for React) / React Spring: springs, gestos, layout animations (FLIP embutido em layout), AnimatePresence para exit. Ótima DX em React.

7.5 APIs modernas do navegador

• View Transitions API: document.startViewTransition(() => updateDOM()) — o navegador tira um "antes" e "depois" e faz o crossfade/morph, inclusive shared elements via view-transition-name. Funciona para SPA e, cada vez mais, para navegação entre páginas (MPA).
• Scroll-driven animations: animation-timeline: scroll() / view() — animações ligadas ao scroll sem JS e sem jank (reveal ao entrar na viewport, barra de progresso, parallax). Ver CSS Avançado: Animações & SVG.
• Sempre com fallback: navegadores sem suporte simplesmente pulam para o estado final.

7.6 Medir

• 60fps = ~16.7ms por frame. Use o painel Performance/Rendering do DevTools: procure long tasks, layout thrashing e frames vermelhos.
• Teste em device intermediário real e com CPU throttling — não no seu desktop.
• Ative "Paint flashing" e "Layer borders" para ver o que está sendo repintado.

8.1 Ferramentas de prototipagem

8.2 A spec de motion

Um protótipo bonito não é uma especificação. Para cada animação, documente:

• Gatilho: o evento (tap, hover, aparição, sucesso do request…).
• Propriedades: o que muda (transform: translateY, opacity, scale…), com valores de/para.
• Duração e easing (a curva exata: cubic-bezier(...) ou os parâmetros da spring).
• Delay e, em coreografias, o stagger e a ordem.
• Estado inicial e final (e o que acontece se interrompido).
• Comportamento com prefers-reduced-motion (Módulo 9).
• Referência aos motion tokens quando existirem ("usa --duration-md + --ease-emphasized").

8.3 Handoff

• Entregue a spec + um vídeo em câmera lenta (ou o protótipo) + os tokens. Palavras como "suave" e "rápido" não são spec.
• Alinhe cedo com engenharia o que é viável na plataforma (o que a web/o iOS/o Android fazem bem e mal) — evita projetar o impossível.
• Revise no build real, no device real: o que parece ótimo no Figma frequentemente precisa de ajuste de 50ms no código.
• Para Lottie/Rive: entregue o arquivo + os nomes das state machines/markers + em que evento cada um dispara.

8.4 Performance budget

• Alvo: 60fps (ou 120 onde houver), sem frames perdidos durante a animação.
• Orçamento de peso para Lottie/vídeo (ex.: < 50KB para um ícone animado; um Lottie de onboarding maior, mas lazy-loaded).
• Nada de animação bloqueando o first input ou competindo com o carregamento crítico.

9.1 Motion tokens

:root{
  /* durações */
  --duration-instant: 50ms;
  --duration-fast:    100ms;   /* micro: hover, ripple */
  --duration-sm:      150ms;
  --duration-md:      250ms;   /* transições de elemento */
  --duration-lg:      350ms;   /* painéis, telas */
  --duration-xl:      500ms;   /* momentos expressivos */

  /* curvas — nomeadas por papel, não por valor */
  --ease-standard:            cubic-bezier(0.2, 0, 0, 1);
  --ease-decelerate:          cubic-bezier(0, 0, 0, 1);    /* entradas */
  --ease-accelerate:          cubic-bezier(0.3, 0, 1, 1);  /* saídas */
  --ease-emphasized:          cubic-bezier(0.2, 0, 0, 1);  /* momentos de destaque */

  /* springs (para libs que aceitam) */
  --spring-default: 300, 30, 1;   /* stiffness, damping, mass */
}

• Papéis, não números soltos: um componente pede --duration-md + --ease-decelerate, não 237ms.
• Productive vs expressive (modelo da IBM): motion productive (rápido, sóbrio, para tarefas repetidas) e expressive (mais longo, com caráter, para momentos-chave) — dois conjuntos de tokens.
• Integra com os outros tokens do design system (ver Design Systems & Design Tokens).

9.2 Padrões documentados

O design system não documenta só tokens — documenta quando usar cada transição: "menus e popovers usam scale a partir da origem + --duration-sm + --ease-decelerate"; "navegação entre telas usa slide horizontal + --duration-lg"; "listas usam fade + move de 8px com stagger de 30ms, máximo 8 itens". Assim o motion sai consistente entre times.

9.3 prefers-reduced-motion — de primeira classe

• Parte real da população tem desordens vestibulares; movimento (sobretudo grande, com parallax, zoom, rotação) causa tontura, náusea, dor de cabeça. Não é preferência estética.
• "Reduce" não é "remove tudo". A recomendação: troque animações de movimento (translate, scale grande, parallax) por animações de opacidade (fades) e transições instantâneas; mantenha feedback essencial (um spinner ainda gira; um estado ainda muda — só sem o "voo").
• Implementação: um utilitário/token que, sob a media query, zera durações de movimento ou substitui os keyframes.

@media (prefers-reduced-motion: reduce){
  :root{ --duration-lg: 1ms; --duration-md: 1ms; }
  .parallax{ transform: none !important; }
  .slide-in{ animation-name: fade-in; }   /* troca "voar" por "aparecer" */
}

9.4 WCAG e motion

• 2.2.2 Pause, Stop, Hide: qualquer movimento automático que dure > 5s e comece junto com outro conteúdo precisa de controle para pausar/parar (carrosséis, fundos animados).
• 2.3.1 Three Flashes: nada pisca mais de 3×/s em área significativa.
• 2.3.3 Animation from Interactions (AAA): movimento disparado por interação deve poder ser desativado — o que prefers-reduced-motion atende.
• Ver a apostila Acessibilidade Digital & WCAG.

9.5 Governança

• Lint: proibir durações/easings literais no código de componente (só tokens).
• Um "motion spec" por padrão no site do design system, com exemplos ao vivo e o comportamento reduced-motion lado a lado.
• Revisão de motion no checklist de PR de componente (tokens? reduced-motion? 60fps? interrompível?).
• Consistência cross-plataforma: as curvas e durações conceituais são as mesmas; a implementação usa o idioma de cada plataforma (Core Animation, Compose, CSS).

10.1 Onde motion de interface pesa

• Motion designer / UX motion: foca em animação de produto — transições, micro-interações, o sistema de motion.
• Interaction designer: o comportamento da UI, incluindo o tempo e a resposta.
• Design engineer / design technologist: implementa o motion com performance e o mantém no design system.
• Product designer: espera-se cada vez mais que especifique motion, não só telas estáticas.
• Design systems: os motion tokens, os padrões, a governança, o reduced-motion.

10.2 Roadmap de estudo (6–8 semanas)

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Sistema de motion (âncora): motion tokens (durações, curvas, productive/expressive), padrões de transição documentados, reduced-motion, e 3–4 componentes usando tudo — como uma página de design system.
2. Redesign de transições de um app real: escolha um app com motion fraco ou ausente, refaça as 4–5 transições principais, publique vídeos antes/depois com o raciocínio (função, timing, coreografia).
3. Set de micro-interações: 6–8 micro-interações projetadas e implementadas em código, com a anatomia (trigger/rules/feedback/modes) e o caminho de erro documentados.
4. Estudo de performance: a mesma animação implementada de forma ingênua (jank) e otimizada (compositor/FLIP), com as gravações do DevTools mostrando os frames.
5. Estudo de reduced-motion: as mesmas transições com a variante acessível lado a lado, e uma nota sobre as decisões.

10.5 Fontes para continuar

• Livros: The Illusion of Life (Johnston & Thomas — os 12 princípios); Designing Interface Animation (Val Head); Microinteractions (Dan Saffer); Animation at Work (Rachel Nabors).
• Guidelines: Material Design — Motion; Apple HIG — Motion; IBM Design Language — Motion (productive/expressive); Fluent e Carbon motion.
• Web: web.dev e MDN sobre animações, View Transitions e scroll-driven; animations.dev (Emil Kowalski); a documentação do Framer Motion / Motion One / GSAP; cubic-bezier.com, easings.net.
• Referência de estudo: as seções de motion dos design systems públicos; coleções como UI Movement, Mobbin (para observar padrões reais).
• Nesta trilha: CSS Avançado: Animações & SVG (implementação), Design Systems & Design Tokens, Iconografia, Cor, Layout, Grade & Espaçamento, Acessibilidade Digital & WCAG, Figma, 3D em Tempo Real & Motion Graphics para Web.