Onboarding, registo e ativação: quantos campos, e porque é que os tours quase nunca servem

Constatações

1. O custo de cada campo de registo

A cifra mais citada e melhor sustentada provém da HubSpot, que estudou formulários de contacto de 40.000 clientes: a conversão subiu quase a metade ao reduzir de 4 campos para 3 [1]. Um estudo de benchmarks de 2026 traça a curva completa e é a fonte mais útil para orçamentar campos [5]:

Campos	Conversão
3	23,1%
5	17,0%
7	11,4%
10+	6,9%

O importante não é a inclinação média, mas onde está a ruptura: entre 5 e 7 campos cada campo adicional custa ~2,8 pontos percentuais, contra ~1,5 pontos por campo antes desse intervalo [5]. Ou seja, o sexto e o sétimo campo são muito mais caros que o quarto.

A advertência que há que conservar. A correlação não é perfeita nem universal: há casos documentados em que reduzir campos produziu uma queda de 14 % na conversão, e pelo menos uma análise onde dez campos converteram melhor que três [3][5]. A explicação habitual é a qualidade da intenção — um formulário longo filtra curiosos —, o que importa pouco para um produto gratuito onde o objetivo é que o pai veja o filho a resolver uma soma. Para o Math Challenge a regra de “menos campos” aplica‑se com força, mas regista‑se como hipótese a medir, não como facto estabelecido.

2. A posição do Nielsen Norman Group sobre onboarding

Esta é a parte incómoda e a mais valiosa. A recomendação principal da NN/g é que o onboarding se evite: “avoid creating app onboarding whenever possible and instead spend your resources making the UI more usable” [2]. O raciocínio tem três pernas: aumenta o custo de interação, carrega a memória de trabalho, e a investigação mostra que frequentemente não melhora o desempenho real na tarefa [2].

A NN/g reconhece exatamente três cenários que justificam ecrãs de onboarding [2]:

1. Recolher informação indispensável (o exemplo que dão: criar conta numa app bancária).
2. Adaptar a experiência ao contexto ou às preferências do utilizador.
3. Introduzir fluxos genuinamente novos ou desconhecidos que se afastam dos padrões habituais.

E uma recomendação de método que vale mais que qualquer padrão: testar a app sem onboarding primeiro, para identificar as dificuldades reais dos utilizadores antes de investir em resolvê‑las com ecrãs [2].

3. Que formato funciona e qual não

Carrossel de cartões (“deck-of-cards tutorial”): desaconselhado por nome. A NN/g assinala que faz a interface parecer mais complexa do que é e carrega a memória de trabalho; a sua investigação sobre este formato específico encontrou que não melhorou o desempenho na tarefa [2]. É, de longe, o formato mais popular na indústria e o pior sustentado.

Marcas de guia e sobreposições instrutivas: úteis com condições. Funcionam quando são oportunas e discretas, e quando vão acompanhadas da execução real da tarefa [2]. A NN/g classifica‑as como “nice‑to‑have” mais que essenciais [2]. A regra visual concreta: o estilo de uma pista deve deixar inequivocamente claro que é uma anotação, não um elemento interativo [2].

Promoção de funcionalidades ao lançamento: evitar. Os utilizadores raramente precisam que se lhes repita dentro da app o que já leram na loja. O padrão serve melhor para utilizadores existentes que descobrem funcionalidades novas, e não deve ser usado para insistir com funcionalidades antigas pouco usadas [2].

Ajuda contextual: o padrão que a NN/g defende. Prefere a ajuda em contexto sobre a instrução antecipada, com as pistas a aparecerem quando a funcionalidade se torna acionável para o utilizador [2].

4. Sobre as cifras de “engagement” que circulam

Várias fontes secundárias da indústria citam cifras chamativas atribuídas à NN/g — por exemplo, que a guia disparada por comportamento teria 68 % mais engagement e 54 % melhor adoção que as alternativas por tempo ou localização. Essa cifra não se pôde verificar contra uma publicação da NN/g nesta sessão, e provém de blogs de fornecedores de ferramentas de onboarding, que têm um interesse comercial direto em que o onboarding pareça eficaz. Regista‑se aqui como não verificada e não se usa como base de nenhuma decisão. A posição documentada da NN/g aponta, se acaso, em direção contrária: menos onboarding, mais interface utilizável.

5. O que é genuinamente inovador no Math Challenge

Aplicando o critério 3 da NN/g — só o que se afasta dos padrões habituais merece explicação — o produto tem exatamente cinco conceitos que um utilizador não pode inferir da interface:

1. A idade e a dificuldade são eixos separados (D-002, D-017). Contra‑intuitivo e central; sem isto um pai não entende por que o filho de 7 anos vê um tema de ensino básico mas conteúdo de jardim de infância.
2. A criança é um perfil, não um utilizador (D-013). Afasta‑se do modelo mental de “criar uma conta para o meu filho” que trazem de outros produtos.
3. A localização não é um exame, e no jardim de infância nem sequer parece (D-002, mc-44).
4. Os clubes e salas não têm chat, e nunca o terão (D-011, D-027). É uma ausência deliberada, e uma ausência não se explica sozinha.
5. As vestes não têm perdedor (D-028). Afasta‑se do que “apostar” significa para quem chega.

Todo o resto — tocar a resposta correta, ver os pontos, mudar de perfil — deve ser explicado por si só ou é um defeito de interface, não um vazio de onboarding.

Implicações de design

1. Nenhum registo passa de 3 campos, e nenhum dos nossos necessita de mais de 2. Email e palavra‑passe para as três portas de entrada (adulto, pai, professor). Todo o resto é configuração posterior.
2. Registar‑se não é configurar‑se. O perfil da criança, a faixa etária, o limite de ecrã e a sala pedem‑se depois do registo, em passos separados e saltáveis com valores por defeito saudáveis — o intervalo de 5‑7 campos é exatamente onde está o despenhadeiro [5].
3. Zero carrossel de boas‑vindas, em nenhuma das cinco entradas. É o formato que a NN/g desaconselha por nome e cuja investigação específica não encontrou melhoria no desempenho [2].
4. Exatamente cinco marcas contextuais, uma por cada conceito genuinamente inovador (§5), cada uma disparada no momento em que a sua funcionalidade se torna acionável, não ao abrir a app [2].
5. Cada marca contextual apresenta‑se como anotação, nunca como controlo. Estilo visual inequivocamente distinto de qualquer elemento tocável [2].
6. O adulto chega à sua primeira questão de matemática sem passar por um formulário além do registo. É a prova de fogo de “testar a app sem onboarding” [2] aplicada ao caso de uso principal.
7. A verificação do professor ocorre antes de criar uma sala, não antes de registar‑se. Mover a fricção de identidade para o registo penaliza todos por um requisito que só se aplica a quem vai ter crianças alheias à vista.
8. Toda marca contextual é descartável permanentemente e não se volta a mostrar. Reaparecer é a versão de onboarding do padrão de “nagging” que a FTC nomeia explicitamente (mc-17).
9. Instrumentar o funil por passo desde o primeiro dia, para poder medir a hipótese do §1 nos nossos próprios dados em vez de herdar o benchmark: registo iniciado → registo completo → primeiro perfil criado → primeiro desafio concluído.
10. No jardim de infância não há onboarding para a criança, de forma alguma. O primeiro passeio pela Savana é a localização (mc-44), e a criança não lê — qualquer ecrã explicativo dirigido a ela é, por definição, inútil.

Questões abertas para o proprietário do projeto

1. O registo do adulto usa palavra‑passe, link mágico ou passkey? O link mágico reduz a um campo mas adiciona um salto ao email a meio da ativação.
2. O funil é medido com Web Analytics (sem cookies, amostrado a 10 % após 7 dias) ou é preciso algo com retenção mais longa para poder comparar coortes de registo?
3. As cinco marcas contextuais são autorreferidas por idioma ou são traduzidas? O tom de uma explicação breve é justo onde a tradução literal soa condescendente (mc-37).
4. Vale a pena um teste A/B de 2 vs. 3 campos no registo do pai, dado que a evidência externa não é unânime (§1)?