TL;DR
- Atualizações OTA pulam a App Store — e a revisão de design, a menos que você crie um processo para isso
- Cada atualização OTA toca em território de design: layout, tipo, cor, texto ou transições de estado
- Verifique todos os 5 estados da IU (carregando, vazio, erro, sucesso e limite) em dispositivos pequenos, tamanho máximo da fonte e ambos os temas
- Use lançamentos escalonados (5% → 25% → 100%) com uma apresentação de design de 20 minutos no estágio de 5%
- Mantenha um changelog OTA em seu sistema de design e exija capturas de tela nas solicitações de pull da IU
As atualizações OTA do React Native enviam alterações na IU sem passar pela App Store. Isso é ótimo para velocidade. Também é assim que uma inconsistência no sistema de design, um layout quebrado em um dispositivo mais antigo ou um estado vazio não revisado terminam nos 100% dos usuários em menos de uma hora.
Os designers devem ter uma lista de verificação para revisões OTA. Aqui está como a nossa é.
Por que os designers precisam revisar OTAs
O ciclo de vida de lançamento da OTA em muitas equipes é: engenheiro mescla para main → CI publica → pronto. A design entra quando algo quebra. Isso está errado.
Cada atualização OTA muda pelo menos uma das seguintes:
- Layout (espaçamento, alinhamento, alvos de toque)
- Tipo (tamanho da fonte, peso, altura da linha)
- Cores/tema (especialmente com qualquer lógica de tematização)
- Texto (edições de microtexto frequentemente escapam da revisão)
- Transições de estado (tela de carregamento, tela vazia, tela de erro, telas de sucesso)
Qualquer uma das cinco acima é território de design. O CI da engenharia não tem como saber se um ajuste de 4px de padding quebrou a intenção do design.
Os cinco estados da IU que uma OTA pode alterar
Para cada tela tocada pela OTA, verifique se cada estado renderiza corretamente:
- Carregando — estado esquelético ou de spinner antes que os dados cheguem
- Vazio — a tela 'você ainda não tem pedidos'; geralmente o estado menos testado
- Erro — falha na rede, permissão negada, backend 500
- Sucesso/normal — o caminho feliz
- Limite — conteúdo muito longo, telas pequenas (SE), texto muito grande (Dynamic Type no máximo)
Uma OTA que corrige um bug no estado de sucesso mas quebra o estado vazio é uma regressão enviada.
A lista de verificação visual pré-lançamento
Antes da publicação OTA, passe por:
- [ ] Cada tela alterada neste pacote renderizada no iPhone SE (2020) e Pixel 5 mínimo. Telas pequenas pegam bugs de layout primeiro.
- [ ] Dynamic Type no máximo (iOS) / Tamanho da fonte no máximo (Android) não corta ou transborda.
- [ ] Modo escuro + modo claro ambos parecem corretos. (A maioria das equipes desenha para um e espera que o outro funcione.)
- [ ] Qualquer novo texto passou pela revisão (revisão ortográfica + verificação do tom contra a guia de voz).
- [ ] Capturas de tela antes/depósitos na descrição da solicitação de pull, não apenas 'atualizei o modal'.
Trabalhando com engenheiros em lançamentos escalonados
A OTA suporta o lançamento para uma porcentagem de usuários primeiro:
eas update --branch production --rollout 5
A equipe de design deve estar ciente quando um lançamento está acontecendo e acompanhar os comentários da primeira turma. (Se você estiver prototipando as telas em si, ferramentas como RapidNative podem gerar UI React Native que você pode inserir nessas sessões de revisão.)
Protocolo simples:
- A engenharia posta 'OTA-XXXX rolando para 5% às 14h' no canal design/eng.
- O design atualiza a versão em seu dispositivo de teste, caminha pelos fluxos alterados por 20 minutos.
- Se nada parecer errado aos 5%, a engenharia escala para 25% → 100% nas próximas duas horas.
Isto é 20 minutos de tempo do design por publicação. Não custa nada e pega a maioria dos incidentes 'lançados e quebrados'.
Fazendo o log da atualização visível no sistema de design
Mantemos um registro em andamento no Figma de cada OTA que tocou no design:
- Data + ID da atualização
- Telas alteradas
- Capturas de tela antes/depósitos
- Link para o PR eng
Isto se torna a changelog do design. Seis meses depois quando você está perguntando 'quando mudamos o estilo do botão na tela de checkout?', você tem uma resposta em vez de uma sessão de arqueologia git-blame.
Prático: o que pedir aos engenheiros para adicionar ao fluxo de trabalho da OTA
Duas pequenas mudanças no processo que dão aos designers uma visibilidade real:
- PRs que enviam alterações na UI exigem um screenshot na descrição. Sem screenshot = engenharia bloqueada para fusão. Parece estrito; é realmente como você obtém uma verificação visual consistente.
- Um canal compartilhado #ota-releases onde cada publicação posta (via webhook) a ID da atualização, telas alteradas e estágio de lançamento. Os designers se inscrevem, caminham pelos fluxos, pegam coisas cedo.
A OTA é uma ótima característica. É também a maneira mais rápida para inconsistências visuais se espalharem pela sua base inteira de usuários. O lado da engenharia está bem documentado. O lado do design é com a gente construir.
Qual é o processo de revisão OTA da sua equipe? Deixe um comentário — especialmente se você pegou (ou enviou) um estado vazio quebrado.