👤 Para administradores do pipe
🔐 Disponível nos planos Business, Enterprise e Unlimited
🎯 Para quem já domina condicionais e quer aplicá-las em um formulário completo
Um formulário com quinze campos mostrados para todo mundo coleta quinze respostas, mas gera dados inconsistentes: campos em branco que não deveriam estar em branco, respostas genéricas onde precisaria de especificidade, e preenchedores que desistem no meio do caminho.
A diferença entre um formulário que funciona e um que apenas existe está em uma pergunta: quem preenche este campo e em qual situação? Responder isso antes de construir é o que transforma um questionário em uma entrada de dados estruturada para o processo.
📖 O que você vai aprender aqui:
O que torna um formulário inteligente
Inteligência em formulário não é quantidade de condicionais. É precisão: o preenchedor vê exatamente o que precisa preencher para o caso dele, sem ruído, sem ambiguidade.
Três indicadores de que um formulário precisa de revisão:
- O time recebe cards com campos obrigatórios em branco — alguém forçou o envio sem ter a informação
- Campos de texto livre contêm respostas que deveriam estar em campos de seleção — os dados não são filtrável nem acionáveis por automação
- Preenchedores pedem ajuda com o formulário com frequência — o formulário está mais complexo do que o contexto do preenchedor exige
Os dois primeiros são problemas de estrutura. O terceiro é problema de UX. Os dois têm solução antes da configuração: no momento em que você mapeia o fluxo.
Mapeando o fluxo antes de construir
Quatro perguntas definem a estrutura de qualquer formulário antes de abrir o editor:
| Pergunta de design | O que revela | Aplicação no onboarding |
| Quem preenche? | Define o vocabulário e o nível de detalhe esperado | RH preenche internamente. Linguagem técnica é aceitável. |
| Quem lê depois? | Define quais campos precisam ser autoexplicativos | Gestor lê para aprovar. Campos de status precisam ser claros sem contexto. |
| O que varia por perfil? | Mapeia onde as condicionais são necessárias | CLT, PJ e Estagiário têm documentações distintas. Cada perfil vê seu próprio conjunto de campos. |
| O que alimenta automações? | Identifica campos que precisam ser de seleção, não texto livre | "Tipo de contrato" precisa ser seleção única para disparar automação por tipo. |
A quarta pergunta é a mais ignorada e a que mais causa retrabalho. Campos de texto livre não disparam automações com segurança. Se o formulário vai alimentar uma regra do tipo "se tipo de contrato = PJ, enviar e-mail de instruções", o campo precisa ser seleção única, não texto onde alguém pode digitar "pj", "PJ", "pessoa jurídica" ou "p.j." indistintamente.
Decida o tipo de campo pensando em quem vai usar os dados, não em quem vai preencher. O preenchedor acha texto livre mais fácil. O processo funciona melhor com seleção. Na dúvida, priorize o processo.
Exemplo completo: onboarding de colaboradores
Aplicando o framework ao processo de onboarding, o formulário de entrada do processo tem três perfis distintos: CLT, PJ e Estagiário. Cada perfil gera uma cadeia de campos diferentes.
A estrutura de ramificação a partir de um único campo-gatilho:
Campo-gatilho: Tipo de contrato (seleção única: CLT / PJ / Estagiário)
Se CLT: exibir campos de carteira de trabalho, banco para depósito, benefícios.
Se PJ: exibir campos de CNPJ, razão social, dados bancários para pagamento de NF.
Se Estagiário: exibir campos de instituição de ensino, supervisor de estágio, data prevista de conclusão.
Campos comuns a todos os perfis (sem condicional): nome completo, cargo, data de início, gestor responsável, equipamentos necessários.
O resultado: o formulário tem todos os campos necessários para os três perfis, mas cada preenchedor vê apenas os seus. Um colaborador CLT nunca vê o campo de CNPJ. Um PJ nunca vê o campo de carteira de trabalho.
Mais importante: todos os campos de seleção que alimentam automações estão corretos por construção. "Tipo de contrato" sendo seleção única garante que a automação de envio de e-mail por tipo nunca encontre um valor inesperado.
Boas práticas de UX para formulários internos
Formulários internos têm uma armadilha específica: o time assume que todo mundo sabe o que preencher porque "todo mundo conhece o processo". Na prática, rotatividade, contexto parcial e pressa geram o mesmo problema que formulários externos: preenchimento incorreto ou incompleto.
Campos com texto de ajuda. Use o campo de descrição para explicar o que é esperado, não apenas o que é o campo. "Tipo de contrato" como label não ajuda quem tem dúvida sobre a diferença entre PJ e autônomo no contexto da empresa.
Ordem que reflete a sequência de raciocínio. O campo-gatilho sempre antes dos dependentes. Mas além disso: agrupe campos por tema. Dados pessoais juntos, dados contratuais juntos, equipamentos juntos. A sequência lógica reduz a carga cognitiva do preenchimento.
Campos obrigatórios com critério. Marcar tudo como obrigatório é o caminho mais rápido para formulários abandonados ou preenchidos com dados inválidos só para passar a validação. Obrigatório significa: o processo não avança sem essa informação. Se avança, o campo não é obrigatório.
Teste o formulário com alguém que não participou da construção antes de lançar. O que parece óbvio para quem construiu raramente é óbvio para quem preenche pela primeira vez. Uma rodada de teste com um colega do time revela a maioria dos problemas de UX antes de chegar ao processo real.
Antes de publicar o formulário, confirme:
☐ As quatro perguntas de design foram respondidas antes de abrir o editor
☐ Campos que alimentam automações são de seleção, não texto livre
☐ Campos obrigatórios são apenas os que realmente bloqueiam o processo
☐ A ordem dos campos reflete a sequência de raciocínio do preenchedor
☐ O formulário foi testado por alguém que não participou da construção
