Checklist Onboarding

Cuando el usuario abre el checklist por primera vez, uno o dos pasos triviales que ya cumplio ("Crear cuenta", "Verificar email") deben aparecer marcados, con la barra de progreso arrancando en 30-40% en lugar de cero. Esto activa el endowed progress effect: las personas persisten más hacia una meta cuando perciben que ya avanzaron hacia ella. Nunes y Dreze (2006) dieron a un grupo una tarjeta de 8 sellos vacia y a otro una de 10 sellos con 2 ya estampados (el esfuerzo real era identico): completaron 19% del primer grupo vs. 34% del segundo. Un checklist que parte de cero desperdicia ese empuje gratuito.

El orden de los pasos decide si el usuario entra en momentum o choca y abandona. Los primeros deben resolverse en segundos (nombrar el workspace, subir un avatar) para regalar un quick win inmediato; el aha moment, la acción que correlaciona con la retención real, se reserva para el final, cuando ya hay impulso emocional. Ghost.org midio la conversión trial→paid por acción: 0.9% sin acciones, 5% tras publicar el primer post, y más de 10% entre quienes subieron un tema personalizado (su aha moment). Estructurar el checklist alrededor de esa acción elevo la adopción del tema de 7% a 26%.

Un checklist largo abruma antes de empezar y ese abrumamiento cancela el efecto Zeigarnik: si el usuario no puede ver el final, no siente la tensión productiva hacia la meta sino ansiedad de evasión. El rango comodo es 3-5 pasos, 7 como tope; todo el conjunto debe caber visible en un panel compacto sin scroll. Si el producto exige más configuración, agrupa en fases o expande progresivamente (revela el siguiente bloque al cerrar el anterior) en lugar de volcar 14 items que obliguen a desplazarse. Ver "1 de 14" empuja a cerrar el panel.

El checklist pierde toda su fuerza psicologica si el usuario regresa al día siguiente y ve el progreso borrado. La tensión Zeigarnik, la incomodidad cognitiva que mantiene la meta activa en la mente, solo funciona si el sistema recuerda donde se quedo el usuario tanto como el lo recuerda; ver "0/5, empieza tu configuración" tras haber hecho dos pasos rompe la confianza al instante. Para productos autenticados la persistencia server-side es obligatoria (sobrevive a cambios de dispositivo y navegador); localStorage es aceptable solo como fallback o para flujos anonimos de un dispositivo.

Forzar al usuario a interactuar con el checklist antes de usar el producto convierte la ayuda en fricción: NN/g advierte que el onboarding instructivo que bloquea el acceso reduce la usabilidad. El panel debe poder ocultarse con un clic en una "X" o "Ocultar por ahora", pero debe ser igual de fácil de recuperar, un chip persistente en la barra ("Configuración 2/5"), un icono en la sidebar o una burbuja flotante, para no generar la ansiedad de "donde fue". Un modal full-screen sin cierre, o con un "Saltar" casi invisible en gris claro, es exactamente el antipatron.

Terminar el checklist es un hito emocional; desaparecerlo sin más desperdicia la oportunidad de anclar un recuerdo positivo al producto. Cuando el usuario marca el último paso, la barra debe llenarse y disparar una micro-celebración, confetti, un mensaje personalizado ("Listo, tu workspace esta configurado") o una transición fluida hacia la vista principal, que refuerza la percepción de competencia y cierra el ciclo de tensión Zeigarnik con satisfacción. El timing importa: la animación no debe pasar de 1-2 segundos para no estorbar. Es un patrón consistente en Notion, Asana y Freshdesk.

Un checklist empodera (el usuario elige que y cuando completar); un tour guiado de coach marks secuenciales y spotlights bloqueantes impone control sobre el flujo. Mezclar ambos, que cada clic en un paso lance un walkthrough modal obligatorio con "Siguiente" forzado, convierte la ayuda en una secuencia de instrucciones impuesta. NN/g cataloga los walkthroughs como "dramaticamente sobreutilizados" y documenta que los tutoriales push no mejoran el desempeño en tareas, por la paradoja del usuario activo: la gente prefiere explorar antes que recibir instrucciones. Al clicar un paso, lleva al usuario al lugar del producto donde se hace la acción, sin overlay que bloquee.

Un checklist de onboarding es, semanticamente, una lista de casillas de verificación. Implementarlo con <div onclick> y un palomita pintada deja a los usuarios de lector de pantalla sin saber el estado de cada paso (completado / pendiente) ni poder navegarlos con teclado, violando WCAG 2.2 SC 4.1.2 (Name, Role, Value) y SC 2.1.1 (Keyboard), ambos AA obligatorios. Usa <input type="checkbox"> nativo cuando puedas (el navegador gestiona el estado solo) o role="checkbox" con aria-checked actualizado por JS. El conteo total vive en una region aria-live="polite" para anunciarse al completar cada paso sin interrumpir la lectura.

<li>
  <input type="checkbox" id="s1" checked>
  <label for="s1">Crear workspace</label>
</li>

<div aria-live="polite" aria-atomic="true">
  Paso 2 de 5 completado
</div>

<div class="step done"
  onclick="complete()">
  Crear workspace <span>✓</span>
</div>

<!-- lector: "Crear workspace", sin estado,
     no operable por teclado -->