Lógica condicional: ramificar por causa da resposta

Lógica condicional é a regra que decide para onde o formulário manda a pessoa com base no que ela respondeu. Ativar leva um minuto em qualquer ferramenta. Desenhar bem é outra coisa, e é onde a maioria dos funis quebra sem ninguém perceber.

Procure "lógica condicional" e você vai achar instruções de clique: onde apertar, qual botão ativar no seu construtor. Nenhuma dessas páginas fala do que dá errado depois, quando duas regras se sobrepõem ou quando um sinal de maior-que escolhido por descuido derruba metade dos respondentes.

Este guia é sobre o desenho. Como uma regra é montada, qual comparação usar em cada situação, os quatro erros que aparecem em funil de verdade, uma regra de acessibilidade que quase ninguém cumpre, e como conferir que a ramificação faz o que você imaginou.

O que é lógica condicional em formulário?

Lógica condicional é um conjunto de regras que compara uma resposta com um valor e muda o caminho do formulário conforme o resultado. Sem ela, todo mundo vê as mesmas perguntas na mesma ordem. Com ela, o formulário se adapta a cada pessoa.

Os três nomes que você vai encontrar significam praticamente a mesma coisa em contextos diferentes. Skip logic costuma descrever pular perguntas irrelevantes. Branching logic (lógica de ramificação) descreve mandar a pessoa para caminhos diferentes. Exibição condicional é mostrar ou esconder um bloco dentro da mesma tela. Na prática, os três são o mesmo motor aplicado a decisões distintas.

A ideia não é nova nem de marketing: ela vem do design de interface. Jakob Nielsen batizou o padrão de divulgação progressiva em 2006, e a definição dele é a mais curta que existe: "mostre ao usuário apenas algumas das opções mais importantes, e ofereça o conjunto maior de opções especializadas quando ele pedir" (Nielsen Norman Group, 2006). Um formulário com lógica condicional é isso aplicado a perguntas.

Reduzir perguntas importa mais que dividir em etapas

Essa é a parte que muda a prioridade do seu trabalho. A pesquisa do Baymard Institute sobre checkout de e-commerce é direta: "o número de campos de formulário afeta a usabilidade geral muito mais do que o número de etapas". O fluxo médio que eles mediram em 2024 tem 11,3 campos, quando 8 bastariam para a maioria dos sites (Baymard Institute, 2024).

É pesquisa de checkout, não de captação de lead, então não vale esticar a conclusão. Mas a direção é útil: quebrar o mesmo formulário em cinco telas não resolve nada por si. O que resolve é a pessoa responder menos coisa, e é exatamente isso que a lógica condicional entrega quando bem desenhada.

Como uma regra de ramificação é montada?

Toda regra tem três partes: o lado esquerdo (o que você está checando), a comparação (como está checando) e o lado direito (contra o que está comparando). O lado esquerdo pode ser uma resposta guardada, uma pontuação acumulada ou até uma conta feita na hora.

Uma regra isolada resolve pouco. O que resolve é agrupar. Várias condições dentro de um mesmo grupo funcionam com E: todas precisam ser verdadeiras. Vários grupos funcionam com OU: basta um casar. O primeiro grupo que casa é o que vale, e os outros nem são avaliados.

Essa estrutura é o que permite escrever uma regra como "manda para a tela de proposta se o orçamento for acima de dez mil e o prazo for este mês, ou se a empresa tiver mais de quinhentos funcionários, independente do resto".

Qual comparação usar em cada situação?

Escolher a comparação errada é o erro mais comum e o mais silencioso, porque o formulário continua funcionando. As sete disponíveis cobrem todos os casos, e cada uma tem uma armadilha:

A regra prática: sempre que você pensar "acima de X", pergunte se quem marcou exatamente X entra ou não. Na dúvida, use a versão que inclui. Um corte exclusivo em 100 descarta silenciosamente todo mundo que somou exatamente 100 pontos, e esse grupo costuma ser grande justamente porque 100 é um número redondo que você escolheu.

Os quatro erros que quebram a ramificação

Grupos que se sobrepõem. Se duas regras podem ser verdadeiras ao mesmo tempo, a ordem decide o desfecho. O formulário não avisa. Você só descobre quando um lead cai na tela errada e ninguém entende por quê. A correção é tornar as condições mutuamente exclusivas ou colocar a mais específica primeiro, de propósito.

Ramo órfão. Uma tela que nenhuma regra alcança. Ela existe, foi escrita, revisada, e nunca aparece para ninguém. Acontece sempre que você reescreve o funil e esquece de atualizar as regras antigas.

Condição em pergunta que pode ficar sem resposta. Se a pergunta é opcional e a regra compara a resposta dela, quem pulou cai num estado que você não previu. Ou torne a pergunta obrigatória, ou escreva uma regra para o caso vazio.

Comparar texto quando você queria comparar número. "10" e "9" comparados como texto dão resultado diferente de 10 e 9 comparados como número. Se o campo aceita digitação livre, a chance de sujeira é alta. Use campos numéricos com tipo declarado quando o valor for numérico.

A regra de acessibilidade que quase ninguém cumpre

Se o seu formulário avança de tela sozinho quando a pessoa marca uma opção, você está fazendo o que as diretrizes de acessibilidade chamam de mudança de contexto automática. E existe um critério explícito sobre isso.

O WCAG 2.2, no critério 3.2.2, diz: "alterar a configuração de qualquer componente de interface não deve causar automaticamente uma mudança de contexto, a menos que o usuário tenha sido avisado do comportamento antes de usar o componente" (W3C). É nível A, o mais básico dos três, e a intenção declarada é garantir que preencher um campo tenha efeito previsível.

Na prática significa duas coisas simples. Se você usa avanço automático, avise antes, com uma linha do tipo "ao escolher, você vai para a próxima pergunta". E se o seu construtor permite atrasar esse avanço em alguns segundos, use: dá tempo de a pessoa perceber o que marcou.

Como conferir que a ramificação está certa?

Teste por caminho, não por tela. Liste os desfechos possíveis do funil, que normalmente são três ou quatro, e percorra um caminho completo para cada um. É mais rápido do que parece e pega quase tudo.

Depois teste as bordas de propósito. Responda exatamente o valor de cada corte que você escreveu. É ali que a comparação errada aparece. Um funil com três cortes tem três bordas, e testar as três leva menos de cinco minutos.

Por último, olhe a distribuição depois de alguns dias. Se um dos desfechos ficou com quase zero, provavelmente a regra dele nunca casa, ou casa depois de outra que a engole.

Quando lógica condicional não vale a pena

Formulário curto não precisa. Se são três campos e todo mundo responde os mesmos três, ramificar adiciona trabalho de manutenção e não devolve nada. Lógica condicional paga quando existe mais de um tipo de respondente e você trata cada um de forma diferente depois.

Também não vale quando você não vai usar a informação. Ramificar para mostrar uma mensagem levemente diferente no fim é enfeite. Ramificar para mudar quem recebe o lead, qual oferta aparece ou qual acompanhamento é disparado é o que justifica.

Desenhe a regra antes de configurar

Lógica condicional é barata de ativar e cara de consertar depois que o tráfego já está passando. Antes de abrir o construtor, escreva em uma linha cada desfecho que o funil precisa ter, e só depois monte as regras que levam a eles. Confira as comparações nas bordas e percorra um caminho completo por desfecho.

O FoxForm, que é um construtor de quiz e funis de captação de lead, trata essa camada como o produto em si, e não como recurso de plano superior: as condições se agrupam com E dentro do grupo e OU entre grupos, e a mesma engrenagem controla tanto a navegação quanto a exibição de blocos dentro de uma tela.

Conferimos a lista de comparações direto no contrato público da interface de programação do produto antes de escrever este texto, e ela é exatamente a da tabela acima.

Comece de graça no FoxForm, sem cartão, e monte a ramificação inteira antes de mandar tráfego.