El onboarding que decidimos no construir

Si abres una nueva aplicación en 2026, es muy probable que te encuentres con un carrusel de diez diapositivas en el que se explican cosas que una interfaz bien diseñada no necesitaría explicar.

“Desliza el dedo para ver más”. Sí, ya lo sabemos. “Toca aquí para empezar”. Ya lo estábamos haciendo. “Las notificaciones te ayudan a mantenerte involucrado”. Tenemos nuestras opiniones sobre esa frase.

El patrón que evitamos

El extenso tutorial previo a la instalación. El estado inicial que da por hecho que el usuario nunca ha visto una aplicación antes. La pantalla que explica “cómo se utiliza un botón”. Todo esto no forma parte de la incorporación del usuario, sino que son tácticas para retrasar el momento en que el usuario pueda hacer lo que ha venido a hacer.

Si tu interfaz de usuario necesita diez pantallas de explicación antes de poder utilizarse, el problema es de la interfaz. No el usuario.

El carrusel es también síntoma de otra cosa: es el lugar más fácil donde colocar las explicaciones que un equipo no ha podido incluir en el diseño. Cada diapositiva es una pequeña admisión de que una pantalla no era lo suficientemente clara por sí sola. Eliminar el carrusel nos obliga, en cambio, a corregir esas pantallas.

Lo que construimos

Una primera pantalla que resulte útil desde el primer momento —aunque esté un poco vacía— para que el usuario pueda empezar a explorar y aprender sobre la marcha. Sugerencias de ayuda solo cuando algo no resulte realmente obvio (y solo la primera vez). Estados vacíos que indiquen al usuario qué va ahí (“Tu primera nota aparecerá aquí”) en lugar de mostrar una ilustración.

En la práctica, esto varía según cada aplicación. Una aplicación para aprender a escribir a máquina debería permitirte empezar a teclear nada más abrirla, ya que escribir es la lección en sí. Una aplicación para llevar un seguimiento de hábitos debería permitirte añadir tu primer hábito desde la primera pantalla. Una aplicación para organizar bodas necesita realmente cierta información antes de poder ayudarte, por lo que puede pedirte datos —pero solo los que necesite en ese momento— y debería mostrarte algo útil en cuanto hayas respondido.

Pedimos permisos cuando realmente los necesitamos, no en el lanzamiento. Pedimos una cuenta cuando una cuenta ayudaría al usuario, no porque queramos el correo electrónico.

En lo que respecta a los permisos, el momento en que se solicitan es lo más importante. Una solicitud de ubicación tiene sentido la primera vez que alguien consulta una previsión de pesca sobre las condiciones de la zona; en la pantalla de inicio, no es más que una ventana emergente que bloquea la pantalla. Si se solicita en contexto, el motivo es obvio y los usuarios pueden tomar una decisión informada. Si se solicita desde el principio, la mayoría pulsará lo que sea para que desaparezca el cuadro de diálogo.

Las ventajas y desventajas

Saltarse el tutorial tiene un coste. Algunas funciones realmente no son evidentes, y hay personas que nunca las descubrirán sin un pequeño empujón. Aceptamos que algunas funciones avanzadas se descubrirán más tarde que pronto, y nos esforzamos por hacer que sean fáciles de encontrar en su contexto —una pista la primera vez que sea relevante, una etiqueta clara, un valor predeterminado lógico— en lugar de presentarlas todas al principio en una presentación que nadie recuerda.

En qué nos equivocamos

Ya nos hemos pasado de la raya otras veces. Una primera pantalla vacía y sin indicaciones no es “minimalista”, sino que resulta confusa. Un estado vacío en el que solo se lee «No hay elementos» deja a los usuarios sin saber qué hacer a continuación. Ahora, cada estado vacío responde a una pregunta —¿qué debo hacer primero?— con una única acción clara.

El camino más corto desde la instalación hasta el primer momento en que resulta útil: eso es la incorporación. Todo lo demás es una simple tarjeta de felicitación.