Onboarding, registro y activación: cuántos campos, y por qué los tours casi nunca sirven

Hallazgos

1. El coste de cada campo de registro

La cifra más citada y mejor sustentada viene de HubSpot, que estudió formularios de contacto de 40.000 clientes: la conversión subió casi la mitad al reducir de 4 campos a 3 [1]. Un estudio de benchmarks de 2026 traza la curva completa y es la fuente más útil para presupuestar campos [5]:

Campos	Conversión
3	23,1 %
5	17,0 %
7	11,4 %
10+	6,9 %

Lo importante no es la pendiente media sino dónde está el quiebre: entre 5 y 7 campos cada campo adicional cuesta ~2,8 puntos porcentuales, contra ~1,5 puntos por campo antes de ese rango [5]. Es decir, el sexto y séptimo campo son mucho más caros que el cuarto.

La advertencia que hay que conservar. La correlación no es perfecta ni universal: hay casos documentados donde reducir campos produjo una caída del 14 % en conversión, y al menos un análisis donde diez campos convirtieron mejor que tres [3][5]. La explicación habitual es la calidad de intención — un formulario largo filtra curiosos —, lo cual importa poco para un producto gratuito donde el objetivo es que el papá llegue a ver a su hijo resolviendo una suma. Para Math Challenge la regla de «menos campos» aplica con fuerza, pero se registra como hipótesis a medir, no como hecho establecido.

2. La posición de Nielsen Norman Group sobre onboarding

Esta es la parte incómoda y la más valiosa. La recomendación principal de NN/g es que el onboarding se evite: «avoid creating app onboarding whenever possible and instead spend your resources making the UI more usable» [2]. El razonamiento tiene tres patas: aumenta el coste de interacción, carga la memoria de trabajo, y la investigación muestra que frecuentemente no mejora el rendimiento real en la tarea [2].

NN/g reconoce exactamente tres escenarios que justifican pantallas de onboarding [2]:

1. Recolectar información indispensable (el ejemplo que dan: crear cuenta en una app bancaria).
2. Adaptar la experiencia al contexto o las preferencias del usuario.
3. Introducir flujos genuinamente novedosos o desconocidos que se apartan de los patrones estándar.

Y una recomendación de método que vale más que cualquier patrón: probar la app sin onboarding primero, para identificar las dificultades reales de los usuarios antes de invertir en resolverlas con pantallas [2].

3. Qué formato funciona y cuál no

Carrusel de tarjetas («deck-of-cards tutorial»): desaconsejado por nombre. NN/g señala que hace que la interfaz parezca más compleja de lo que es y carga la memoria de trabajo; su investigación sobre este formato específico encontró que no mejoró el rendimiento en la tarea [2]. Es, con diferencia, el formato más popular en la industria y el peor sustentado.

Marcas de guía y superposiciones instructivas: útiles con condiciones. Funcionan cuando son oportunas y discretas, y cuando van acompañadas de la ejecución real de la tarea [2]. NN/g las califica como «nice-to-have» más que esenciales [2]. La regla visual concreta: el estilo de una pista debe dejar inequívocamente claro que es una anotación, no un elemento interactivo [2].

Promoción de funciones al lanzamiento: evitar. Los usuarios rara vez necesitan que se les repita dentro de la app lo que ya leyeron en la tienda. El patrón sirve mejor para usuarios existentes descubriendo funciones nuevas, y no debe usarse para insistir con funciones viejas poco usadas [2].

Ayuda contextual: el patrón que NN/g defiende. Prefiere la ayuda en contexto sobre la instrucción por adelantado, con las pistas apareciendo cuando la función se vuelve accionable para el usuario [2].

4. Sobre las cifras de «engagement» que circulan

Varias fuentes secundarias de la industria citan cifras llamativas atribuidas a NN/g — por ejemplo, que la guía disparada por comportamiento tendría un 68 % más de engagement y un 54 % mejor adopción que las alternativas por tiempo o ubicación. Esa cifra no se pudo verificar contra una publicación de NN/g en esta sesión, y proviene de blogs de proveedores de herramientas de onboarding, que tienen un interés comercial directo en que el onboarding parezca eficaz. Se registra aquí como no verificada y no se usa como base de ninguna decisión. La posición documentada de NN/g apunta, si acaso, en dirección contraria: menos onboarding, más interfaz usable.

5. Qué es genuinamente novedoso en Math Challenge

Aplicando el criterio 3 de NN/g — solo lo que se aparta de los patrones estándar merece explicación — el producto tiene exactamente cinco conceptos que un usuario no puede inferir de la interfaz:

1. La edad y la dificultad son ejes separados (D-002, D-017). Contraintuitivo y central; sin esto un papá no entiende por qué su hijo de 7 años ve un tema de primaria pero contenido de Educación Infantil.
2. El niño es un perfil, no un usuario (D-013). Se aparta del modelo mental de «crear una cuenta para mi hijo» que traen de otros productos.
3. La ubicación no es un examen, y en Educación Infantil ni siquiera lo parece (D-002, mc-44).
4. Los clubs y salones no tienen chat, y nunca lo van a tener (D-011, D-027). Es una ausencia deliberada, y una ausencia no se explica sola.
5. Las prendas no tienen perdedor (D-028). Se aparta de lo que «apuesta» significa para cualquiera que llegue.

Todo lo demás — tocar la respuesta correcta, ver tus puntos, cambiar de perfil — debe explicarse solo o es un defecto de interfaz, no un hueco de onboarding.

Design implications

1. Ningún registro pasa de 3 campos, y ninguno de los nuestros necesita más de 2. Correo y contraseña para las tres puertas de entrada (adulto, padre, maestro). Todo lo demás es configuración posterior.
2. Registrarse no es configurarse. El perfil del hijo, la franja de edad, el límite de pantalla y el aula se piden después del registro, en pasos separados y saltables con defaults sanos — el rango de 5-7 campos es justo donde está el despeñadero [5].
3. Cero carrusel de bienvenida, en ninguna de las cinco entradas. Es el formato que NN/g desaconseja por nombre y cuya investigación específica no encontró mejora en el rendimiento [2].
4. Exactamente cinco marcas contextuales, una por cada concepto genuinamente novedoso (§5), cada una disparada en el momento en que su función se vuelve accionable, no al abrir la app [2].
5. Cada marca contextual se ve como anotación, nunca como control. Estilo visual inequívocamente distinto de cualquier elemento tocable [2].
6. El adulto llega a su primera pregunta de matemáticas sin pasar por un formulario más allá del registro. Es la prueba de fuego de “probar la app sin onboarding” [2] aplicada al caso de uso principal.
7. La verificación del maestro va antes de crear un aula, no antes de registrarse. Mover fricción de identidad al registro castiga a todos por un requisito que solo aplica a quien va a tener niños ajenos a la vista.
8. Toda marca contextual es descartable permanentemente y no se vuelve a mostrar. Reaparecer es la versión de onboarding del patrón de “nagging” que la FTC nombra explícitamente (mc-17).
9. Instrumentar el embudo por paso desde el primer día, para poder medir la hipótesis de §1 en nuestros propios datos en vez de heredar el benchmark: registro iniciado → registro completo → primer perfil creado → primer reto terminado.
10. En educación infantil no hay onboarding para el niño, en absoluto. El primer paseo por la Sabana es la ubicación (mc-44), y el niño no lee — cualquier pantalla explicativa dirigida a él es, por definición, inútil.

Open questions for the project owner

1. ¿El registro del adulto usa contraseña, enlace mágico o passkey? El enlace mágico baja a un campo pero agrega un salto al correo a media activación.
2. ¿Se mide el embudo con Web Analytics (sin cookies, muestreado al 10 % tras 7 días) o hace falta algo con retención más larga para poder comparar cohortes de registro?
3. ¿Las cinco marcas contextuales se autoran por idioma o se traducen? El tono de una explicación breve es justo donde la traducción literal suena condescendiente (mc-37).
4. ¿Vale la pena una prueba A/B de 2 vs. 3 campos en el registro del padre, dado que la evidencia externa no es unánime (§1)?