A Arte do 'Push': Replicando a Física de Navegação do iOS no Figma

Abra o aplicativo da Nubank ou do iFood no seu iPhone agora. Toque em um cartão ou em um item do menu. Preste atenção no movimento. A nova tela não simplesmente aparece ou desliza por cima de forma linear. Existe uma aceleração inicial, um peso e uma sensação física de que a tela anterior foi "empurrada" para o fundo enquanto a nova ocupa o espaço visual. O chamamos de efeito "push". É essa sutil diferença de física que separa um webview responsivo de um aplicativo nativo de alto polimento.

No Figma, o erro mais comum é selecionar a transição "Slide Left" (ou "Deslizar para a esquerda") no painel de prototipagem e achar que o trabalho está feito. O resultado? Um movimento robótico, constante, sem inércia, que não engaja o cérebro do usuário da mesma forma. Para sair do amadorismo e entregar algo que testei inúmeras vezes em testes de usabilidade e viu o tempo de conclusão de tarefas melhorar, precisamos abandonar as transições presetadas e mergulhar no Smart Anate aliado a uma arquitetura de camadas rigorosa.

Abaixo, detalho o processo exato que utilizo no Appgeous para replicar essa navegação nativa, focando na correspondência de camadas e curvas de movimento.

A anatomia do movimento iOS antes de abrir o software

Antes de tocar no Figma, precisamos internalizar o que acontece no sistema operacional da Apple. O iOS utiliza uma curva de easing específica que é rápida no início e desacelera suavemente no final. O tempo padrão para uma transição de navegação "push" no iOS é, geralmente, fixado em torno de 400ms a 500ms.

O grande segredo visual não está apenas no movimento horizontal. A tela anterior fica parada, mas frequentemente sofre um pequeno "scale down" (diminuição de escala) ou um desfoque (blur), e uma barra de navegação desliza por cima dela com um fundo semitransparente. Se você tentar fazer isso movendo o frame inteiro, vai falhar. O Figma precisa entender quais elementos são "estáticos" (como o status bar ou o fundo do app) e quais são "entrantes". É aí que a maioria dos designers juniores se perde.

Passo 1: A preparação das camadas e a regra dos nomes idênticos

O Smart Animate funciona baseando-se em correspondência de nomes (matching layers). Se na Tela A você tem um retângulo chamado Header e na Tela B ele se chama Cabeçalho, o Figma não vai fazer a conexão; ele vai dissolver (dissolve) um e fazer o outro aparecer, matando a fluidez.

1. Crie seu Artboard inicial (Tela A) usando a dimensão do iPhone 15 Pro (393 x 852px). Construa sua interface normally.
2. Para a Tela de Destino (Tela B), não crie um novo artboard do zero. Selecione a Tela A e pressione Cmd + D (Ctrl + D no Windows) para duplicá-la. Isso garante que 100% dos nomes das camadas sejam idênticos desde o início.
3. Renomeie a Tela B para algo como Home — Detalhes do Produto.
4. Agora, na Tela B, mova os elementos que devem "sair" da tela para a direita ou esquerda, ou altere seu conteúdo para o estado final. Ajuste os elementos que compõem a nova visualização.

Ao duplicar, preservamos a estrutura DOM visual. Se você tiver um componente de Navbar na Tela A e mantiver o mesmo componente Navbar na Tela B, mas apenas mudar o título dentro dele, o Figma irá animar apenas o texto, mantendo a barra fixa ou deslizando conforme sua preferência, sem precisar de configurar nada extra.

Passo 2: Isolando os elementos "Shared" vs "Unique"

Para o efeito de "push" realista, precisamos que a Tela B cubra a Tela A, mas que elementos como o Status Bar (hora, bateria, sinal) permaneçam fixos no topo.

1. Na Tela A (Home), identifique sua camada de Status Bar.
2. Na Tela B (Detalhes), certifique-se de que a camada Status Bar está exatamente na mesma posição (x: 0, y: 0).
3. O restante do conteúdo da Tela B (o "corpo" da nova página) deve estar inicialmente posicionado fora da tela à direita (ex: x: 393), pronto para entrar.

Aqui ocorre um erro clássico de interface: misturar o Status Bar dentro de um frame de cabeçalho que vai se mover. Isso faz a hora e a bateria deslizarem junto com o conteúdo, o que não acontece em apps nativos. Mantenha o Status Bar solto no nível superior ou, se estiver dentro de um frame, assegure-se de que o frame de fundo se mova, mas o texto do relógio permaneça parado via correspondência de nomes (o que é complexo; melhor separar as camadas).

Passo 3: Configurando o Smart Animate com curvas físicas

Com as duas telas prontas, vamos para a aba de Prototipagem.

1. Selecione o elemento de gatilho na Tela A (por exemplo, o card do produto). Clique no ícone de "Protótipo" no inspetor à direita.
2. Arraste a linha azul (conneciton) até a Tela B.
3. Na lista de animações, ignore "Move in" ou "Push". Selecione Smart Animate.
4. Na configuração da animação (o pequeno ícone de engrenagem ou a área de detalhes):
   • Easing: O Figma oferece uma curva chamada "Ease Out" ou "Ease In-Out". Para o iOS, a curva que melhor se aproxima da física nativa da Apple é a Ease In Out (cúbico), mas com ênfase na saída. Na prática, o preset "iOS" (se disponível no seu plugin ou versão atual) ou um Cubic-bezier(0.42, 0, 0.58, 1) manual costuma funcionar. Eu utilizo o padrão Ease Out com duração de 300ms para interações rápidas e 500ms para navegações completas.
   • Duration: Defina para 400ms. Este é o número mágico. Qualquer coisa abaixo de 300ms passa desapercebida; acima de 600ms o usuário sente que o app travou.

O ajuste fino da profundidade e sombra

Para elevar o nível de polimento (o que eu chamo de "micro-polimento de UX"), a Tela A não deve simplesmente sumir. Ela precisa parecer que foi empurrada para trás.

Isso é difícil de fazer apenas com Smart Animate puro em uma única conexão sem componentes complexos, mas existe um truque visual simples que uso: na Tela B, adicione uma camada de fundo preto ou escuro com opacidade reduzida (ex: 20%) que não existe na Tela A. Quando a transição ocorrer, o Smart Animate fará esse fundo escuro aparecer gradualmente (fade in) sobre a Tela A enquanto o conteúdo da Tela B desliza por cima.

Isso cria a ilusão de profundidade. O olho do usuário entende que a Tela A está ficando mais escura porque está "no fundo", e a Tela B está "na frente". É um truque psicológico visual que pesa menos no processamento do protótipo do que tentar animar escala (scale) e posição simultaneamente, que muitas vezes causa jitters (tremidas) no preview do navegador.

Validando a consistência visual no Modo Escuro

Eu vejo muitos designers testando suas transições apenas no fundo branco e claro. O problema surge quando o app está em modo escuro. Durante a animação de 400ms, elementos brancos deslizando sobre elementos pretos podem criar um rastro visual desagradável ou um contraste excessivo que cansa a vista.

Ao configurar o matching layers, certifique-se de que o fundo do artboard seja uma cor sólida e não uma imagem opaca que cause moiré (padrões de interferência) ao se mover. Se você comete erros de contraste que citamos em análises anteriores, como usar cinzas muito claros sobre pretos puros, a animação vai destacar essa falha ainda mais. A transição é o momento onde o usuário foca na tela inteira em movimento; qualquer falha de acessibilidade aqui é exacerbada.

Se o seu app depende do modo escuro, teste o protótipo trocando o tema do sistema operacional (macOS ou Windows) enquanto o preview do Figma está aberto. Veja se a animação mantém a elegância.

Ergonomia da interação: Onde colocar o gatilho?

Onde o usuário vai tocar para iniciar essa transição? Em 2026, estamos vendo uma tendência de afastar as ações principais das bordas inferiores (a thumb zone clássica) apenas para acomodar bordas arredondadas mais agressivas em telas maiores. No entanto, o botão de voltar ou o gesture de navegação ainda residem no canto ou na borda inferior.

Se o seu gatilho for um botão flutuante (FAB) ou um card no centro da tela, a animação de "Push" funciona perfeitamente. Se o botão estiver no topo, onde o polegar tem dificuldade de alcançar, você já está lutando contra a ergonomia antes mesmo da animação começar. O design da interface e o protótipo devem andar juntos. Se você precisa de um botão de ação que dispare essa tela, considere sua localização, já que o comportamento nativo do Android, por exemplo, modificou a zona de toque para voltar.

A regra é simples: a transição deve ser a cereja do bolo, não o ingrediente que esconde um layout ruim.

Testando no dispositivo real

O preview do navegador do Figma é útil, mas mente. O navegador renderiza a 60fps ou mais dependendo da sua placa de vídeo, escondendo pequenos problemas de timing. A prova real é o app do Figma no seu iPhone.

Abra o arquivo no celular e toque na interação. Sinta o atraso de toque (touch latency). Se a animação parecer "solta" ou "lenta", reduza a duração de 400ms para 350ms. O contexto de uso muda a percepção de tempo. No desktop, 400ms pode parecer lento porque usamos mouse com precisão milimétrica. No celular, com o dedo cobrindo parte da tela e o movimento natural do braço, 400ms são muitas vezes necessários para o cérebro processar a mudança de contexto.

Se ao testar no dispositivo a transição parecer "travada", verifique se você tem imagens pesadas (PNGs de 4MB) dentro dos frames que estão se movendo. O Figma no mobile lida melhor com vetores e imagens WebP otimizadas para animação.

Conclusão: O perigo do over-engineering

Dominar o Smart Animate e o efeito push abre portas para protótipos de alta fidelidade que vendem a ideia para o cliente ou o time de desenvolvimento. Existe, porém, uma linha tênue entre uma navegação fluida e um show de pirotecnia inútil. Se você passar três horas configurando transições complexas para um fluxo que o usuário vai usar uma vez por ano (como a tela de "Excluir conta"), você investiu o tempo errado.

Use essa técnica de "push" para fluxos principais: navegação entre abas, entrada em detalhes de produtos, abertura de carrinho. Onde o usuário passa 90% do tempo, a polidez deve ser total. O próximo passo lógico após dominar a navegação entre telas é estudar as microinterações dentro de uma mesma tela (como animação de inputs e feedback de toques), onde o princípio de matching layers se aplica da mesma forma, mas em escala menor. Comece a aplicar isso no seu próximo app e observe como a "sensação" de qualidade do produto sobe imediatamente, sem que o usuário consiga explicar exatamente o porquê.