Um guia para revisões de viabilidade antes que os pixels estejam finalizados - como engenheiros e designers do Expo SDK 57 se alinham em movimento, gestos e restrições de layout sem sacrificar o artesanato ou perder datas de sprint.
Cartão de sessão de viabilidade pré-hi-fi - 30 minutos, três participantes.
## Viabilidade de movimento - <nome da tela>**Participantes:** Designer, engenheiro, PM (opcional)**Entradas:** Wireframe ou lo-fi + notas de interação (não pixels finais)**Dispositivos:** Simulador de iPhone 16 + Pixel 6a ou 8 (Android de baixo custo obrigatório para movimento)### Agenda (30 min)1. Percorrer o caminho do usuário - 5 min2. Listar interações - scroll, swipe, elemento compartilhado, teclado - 5 min3. Classificar cada uma: Estático | API Animated | Reanimated | Nativo - 10 min4. Sinalizar spikes + fallbacks - 5 min5. Escrever notas de ticket + gravar clipe de dispositivo de 20s - 5 min
# Preparação do engenheiro - ter o starter do Reanimated em execuçãonpx expo install react-native-reanimated react-native-gesture-handlernpx expo start# Abrir o monitor de desempenho no Android: agitar → Mostrar Monitor de Desempenho
Quando usar isso:
Novo onboarding com transições escalonadas
Ações de linha de lista (swipe, arrastar para reordenar)
Transições de herói / elemento compartilhado
Bottom sheet com scroll aninhado
Pedidos de marketing por interações "como Instagram"
## Especificação de movimento: Sucesso do checkout**Gatilho:** API de pagamento retorna 200**Entrada:** Escala de checkmark de 0→1, mola (amortecimento 15, rigidez 150), percebido em 400ms**Saída:** Avanço automático para recibo em 1200ms ou toque em Continuar**Interrupção:** Gesto de voltar cancela a animação → mostrar recibo imediatamente**Movimento reduzido:** Pular escala; mostrar checkmark estático + apenas haptic**Haptic:** notificação de sucesso (iOS); vibração curta (Android)**Referência:** Não Lottie - desenho vetorial em SVG ou ícone
Engenheiros mapeiam valores de mola para Reanimated withSpring - armazene predefinições no sistema de design:
## Porta de bloqueio de hi-fi- [ ] Áreas seguras no menor quadro de telefone- [ ] Estados do teclado documentados- [ ] Especificação de movimento por transição não estática- [ ] Variante de movimento reduzido aprovada- [ ] Quadros de carregamento / vazio / erro existem- [ ] Tokens usados - sem valores hex órfãos ([Sistemas de Design](../design-systems/design-systems-basics.md))- [ ] Comentário do engenheiro: nenhum risco ALTO não resolvido sem ticket de spike- [ ] Clipe de dispositivo de 20s ou QR de pré-visualização anexado
O PM não aceita o bloqueio de hi-fi sem a lista de verificação - evita estimativas "surpresa".
## Plano de movimento em fases**v1 (sprint N):** Transições estáticas, layout correto, haptics no sucesso**v1.1 (sprint N+1):** Ações de swipe se o spike for GO**v2:** Elemento compartilhado - depende da atualização do Router
Os stakeholders aceitam deleite em fases quando rotulados como estratégia de produto - não vergonha de "cortar escopo".
Quem é o proprietário da especificação de movimento - design ou engenharia?
O design é proprietário da intenção (timing, sensação, interrupção); a engenharia é proprietária do mapa de implementação e dos fallbacks. Aprovação conjunta do documento de viabilidade.
Quanto tempo devem levar os spikes?
30 minutos a 0,5 dia para questões de movimento/gesto. Pare com o veredito escrito GO/NO-GO - sem polimento infinito em código descartável.
Podemos usar Lottie para tudo?
Lottie se encaixa em carregadores ilustrados e momentos de marca. UI com muitas interações (arrastar, vinculados ao scroll) precisa de Reanimated - Lottie não é um motor de gestos.
E se o design insistir em animação não performática?
Mostre a gravação de FPS no Pixel 6a. Memorando de troca: enviar animação vs. enviar recurso no prazo vs. simplificar. O PM decide com dados.
Precisamos de movimento no sistema de design?
Sim para padrões repetidos (pressionamento de botão, entrada de sheet, esqueleto de lista). One-offs de campanha ficam fora dos tokens principais.