Checkout — o fluxo inteiro e o motion do cartão

Contexto

A Braip é uma plataforma de vendas digitais, e o checkout é o lugar onde tudo que acontece antes dele é cobrado ou perdido. Não é uma tela de produto: é o último passo de toda venda que a plataforma processa, para milhares de lojas que não têm controle nenhum sobre como ele se parece.

Quando peguei o arquivo, existiam dois checkouts legados vivos ao mesmo tempo — uma versão de página única e uma versão multietapas. Nenhuma das duas usava o design system atual: eram telas da V1, montadas antes do sistema de variáveis existir.

O escopo real do trabalho está registrado no changelog do arquivo, e vale ser literal sobre ele: remodelar a V1 usando o design system da V2. Isso não é "redesenhar do zero com liberdade". É um trabalho de tradução com uma restrição dura — o fluxo de negócio já existia, os métodos de pagamento já existiam, e o que eu podia mudar era a forma, não o contrato.

O problema

A tensão de design aqui não é a tela cheia. É a tela cheia de coisa obrigatória.

Um checkout brasileiro não pede e-mail e cartão. Ele pede nome, e-mail, telefone, CEP, endereço, número, complemento, bairro, cidade, estado, forma de envio, forma de pagamento, número do cartão, titular, validade, CVC, parcelamento e CPF do titular — antes de qualquer confirmação. Some a isso cupom, order bump, frete calculado e desconto de Pix. É um formulário longo por lei e por regra de adquirência, não por descuido de quem desenhou.

Então a pergunta não podia ser "como reduzir campos". Tinha que ser: como fazer um formulário longo não parecer um obstáculo enquanto ele é preenchido.

E existia um segundo problema, mais silencioso. O checkout legado tinha telas para quando dá certo. Não tinha para quando dá errado. Cartão recusado, saldo insuficiente, falha na emissão do Pix, o segundo em que o pagamento está sendo processado — nada disso estava desenhado. Na prática significa que o pior momento da experiência era o único sem design.

Meu papel

• Remodelagem do checkout de página única sobre o design system V2
• Mapeamento e desenho do caminho infeliz — recusas, falhas e estados de erro
• Estados de carregamento (skeleton) para o processamento do pagamento
• Adaptação responsiva completa: desktop 1440 e mobile 390
• Motion de preenchimento do cartão de crédito
• Protótipo navegável por método de pagamento, com confirmação e recusa

O que não foi meu: as regras de negócio do checkout, os métodos de pagamento disponíveis e os textos legais do rodapé — todos herdados. E o design system V2, que é trabalho de time; eu atuo na trilha de tokens dele, mas os componentes que usei aqui vieram da biblioteca, não foram inventados para este case.

Processo

Comecei pelo inventário, não pelo desenho. O arquivo ganhou duas seções marcadas ⚠︎ OLD — a página única e a multietapas legadas — mantidas lado a lado com as novas. Isso parece burocracia de arquivo, mas foi a decisão de processo mais útil do trabalho: com o "antes" visível ao lado do "depois", toda divergência vira uma pergunta explícita em vez de uma mudança silenciosa.

Depois separei o trabalho em três frentes que andaram em paralelo, cada uma com sua própria seção no arquivo: o caminho feliz (página única moderna), o caminho infeliz (recusas e falhas) e os estados de carregamento. Tratar o erro como uma frente de trabalho própria, com orçamento de tempo próprio, foi o que impediu ele de virar a última hora de sexta-feira.

O motion do cartão nasceu num rascunho à parte antes de entrar no fluxo — uma seção motion draft card, isolada, onde dava para errar sem quebrar as telas boas.

Decisões-chave

O formulário longo mostra tudo, mas em dois pesos

Contexto: todos os campos são obrigatórios, e nenhum pode ser escondido atrás de um acordeão sem criar a sensação de que o formulário nunca acaba.

Alternativa descartada: o fluxo multietapas, que existia e continua existindo como variante. Ele resolve a percepção de tamanho quebrando em passos — mas troca um formulário longo por três telas com três chances de abandono e um botão "voltar" que não devolve o estado direito.

Por que esta: a página única mostra o custo inteiro de uma vez. É honesta, e é mais rápida para quem já sabe o que quer. O trabalho passa a ser de hierarquia: dois blocos lado a lado em desktop, com identidade e entrega à esquerda e pagamento à direita, e o total parcelado imediatamente acima do botão — o último número que a pessoa lê antes de decidir.

O cartão de crédito se preenche enquanto você digita

Esta é a decisão que dá nome ao case.

Contexto: o bloco do cartão é o ponto mais frágil do checkout inteiro. É onde a pessoa digita dezesseis dígitos que ela não sabe de cabeça, tirados de um retângulo de plástico que ela está segurando na outra mão, sob a suspeita permanente de estar digitando num site que talvez não devesse.

Alternativa descartada: validação silenciosa — aceitar os dados e só reagir no erro. É o padrão do checkout legado e é o mais barato de construir. Também é o que transforma um dígito trocado em uma recusa de adquirente três telas adiante, quando a pessoa já não tem mais o cartão na mão.

Por que esta: desenhei o cartão como uma representação visual que se preenche em tempo real. O número aparece no cartão conforme é digitado, agrupado de quatro em quatro; o nome do titular aparece embaixo; a bandeira é detectada e reconhecida antes do campo terminar. O cartão vira um espelho do que foi digitado.

O que isso resolve não é estético. É de conferência: a pessoa compara o cartão da tela com o cartão da mão, e vê o erro no momento em que ele acontece — não depois da recusa. E resolve um segundo problema, de confiança: uma interface que reage com precisão ao que você digita comunica que está processando aquilo com cuidado.

O motion tem uma regra que segurei durante todo o desenho: ele nunca atrasa a digitação. A animação acompanha o campo, não o contrário. Nenhuma transição bloqueia o próximo caractere, e o foco nunca é movido automaticamente entre campos — autoavanço de foco quebra a correção de quem errou o décimo primeiro dígito.

O caminho infeliz recebeu tanto arquivo quanto o feliz

Contexto: cartão recusado é o desfecho mais comum depois do sucesso, e era o único sem tela.

Por que esta: o protótipo cobre três recusas distintas — saldo insuficiente, recusa do emissor e falha na emissão de Pix ou boleto — porque as três exigem coisas diferentes da pessoa. Saldo insuficiente pede outro cartão. Recusa do emissor pede ligar para o banco. Falha de emissão pede só tentar de novo. Uma tela genérica de "pagamento não autorizado" empurra os três casos para o mesmo lugar: o abandono.

A espera é desenhada, não é ausência

Contexto: entre apertar "Comprar agora" e a resposta da adquirente existe um intervalo real, de segundos, em que a tela não tem nada para dizer.

Por que esta: desenhei o estado de processamento como skeleton, com o formato do conteúdo que está chegando, em vez de um spinner sobre a tela apagada. O skeleton diz "vem conteúdo aqui, deste tamanho"; o spinner diz "espere". No momento em que a pessoa acabou de autorizar um pagamento, a diferença entre essas duas mensagens é a diferença entre esperar e desconfiar.

Mobile não é a mesma página mais estreita

Contexto: em 390 px os dois blocos lado a lado viram uma coluna, e a ordem passa a importar mais do que o layout.

Por que esta: em mobile o resumo do produto sobe para o topo, logo abaixo do banner — antes de qualquer campo. Em desktop essa informação pode conviver na lateral; em mobile ela precisa vir antes, porque é o que ancora a pessoa no que ela está comprando durante os trinta campos seguintes. O bloco do cartão mantém o motion integral: é o único elemento do checkout que não foi simplificado no breakpoint menor.

Resultado

O que foi entregue:

• Checkout de página única remodelado sobre o design system V2, em desktop (1440) e mobile (390)
• Variante multietapas mantida e atualizada em paralelo
• Caminho infeliz desenhado: três tipos de recusa mais falha de emissão
• Estados de carregamento com skeleton para o processamento do pagamento
• Telas de pedido confirmado para cartão, Pix e boleto
• Motion de preenchimento do cartão, com especificação de comportamento
• Protótipo navegável cobrindo os quatro métodos de pagamento

Sobre números: não publico taxa de conversão deste trabalho. A métrica existe e fica com o time de produto da Braip; ela mede o checkout inteiro, incluindo mudanças de backend e de política de pagamento que não são minhas. Atribuir esse número ao design seria confortável e seria falso.

O que ficou pendente

• Os campos de apoio dos inputs ainda exibem strings padrão do design system (Message text, Title) nos slots de mensagem de ajuda e erro. É default de componente, não conteúdo — mas significa que o texto de erro real de cada campo ainda não foi escrito, e escrever isso é trabalho de UX writing que ficou fora desta rodada.
• As duas seções legadas continuam no arquivo, marcadas ⚠︎ OLD. Elas só saem quando a migração terminar de verdade em produção.

O que eu faria diferente

Desenhei o motion do cartão depois de fechar o layout do bloco de pagamento, e essa ordem foi um erro meu. Quando fui animar, o cartão já tinha posição, tamanho e distância dos campos definidos por composição estática — e a animação teve que caber naquilo. Se o motion tivesse entrado junto com o layout, o cartão provavelmente estaria mais perto do campo de número, e a relação entre o dígito digitado e o dígito que aparece seria mais curta de ler.

O segundo: passei tempo demais no caminho feliz antes de abrir o caminho infeliz. Sabia desde o inventário que os estados de erro estavam faltando, e mesmo assim deixei para depois — o que fez o caminho infeliz virar uma seção separada do arquivo em vez de nascer junto com cada tela. Estados de erro não são um capítulo. São uma propriedade de cada tela, e o arquivo teria ficado mais coerente se eu tivesse tratado assim desde o começo.