Wizards y steppers: tareas largas en pasos sin perder al usuario

¿Qué son y en qué se diferencian?

Un wizard es el flujo completo: una secuencia de pantallas que guían al usuario de principio a fin, a veces dentro de un modal. Un stepper es solo el indicador de progreso que acompaña ese flujo, con los pasos completados, el actual y los pendientes. Un wizard puede tener stepper o no; y un stepper puede aparecer en flujos que no son wizards, como un proceso de compra.

Nielsen Norman Group (NN/g) define el wizard como un proceso paso a paso que permite introducir información en un orden prescrito, y recomienda impedir que el usuario salte pasos. Eso lo distingue de un formulario largo, donde casi siempre se puede volver a cualquier campo.

¿Por qué le importa a un diseñador junior?

Porque casi todos los productos tienen una tarea larga que alguien tiene que completar: abrir una cuenta, configurar una tienda, reservar un viaje con varias opciones. Un formulario de cuarenta campos en una sola pantalla intimida; dividido en cinco pasos con un orden claro, la tarea resulta más manejable.

Pero el patrón también se usa mal. Un wizard para una tarea que se repite todos los días se vuelve un estorbo. Saber cuándo sí y cuándo no es la diferencia entre una tarea guiada y un camino de obstáculos.

¿Qué recomienda NN/g?

NN/g (Raluca Budiu, 2017) recomienda los wizards para usuarios novatos o para procesos poco frecuentes, como la configuración inicial. Si el usuario repite el proceso, conviene ofrecer una alternativa más rápida. Estas son algunas recomendaciones de su artículo:

• Muestra la secuencia completa y resalta el paso actual, para que el usuario sepa dónde está y cuánto falta.
• Nombra con precisión los botones. En vez de «Siguiente» y «Anterior» genéricos, indica cuál es el paso al que se va.
• Permite salir a mitad de camino y guardar el avance para retomarlo después, sin volver a escribir todo.
• Haz que cada paso sea autosuficiente, sin depender de información guardada en otra parte de la app.
• Pon la ayuda al lado del wizard, no encima, y reutiliza las selecciones anteriores como valores por defecto la próxima vez.

NN/g también señala las desventajas: más clics y mayor costo de interacción si se repite, dificultad para comparar información entre pasos, poca tolerancia a las interrupciones, bloqueo del resto de la aplicación cuando el wizard es modal y menos control para los usuarios expertos. Para el concepto de costo, el artículo sobre costo de interacción explica por qué cada paso suma.

¿Cuántos pasos conviene tener?

No hay un número universal, pero algunas pautas ayudan. Carbon, el sistema de diseño de IBM, recomienda su indicador de progreso para procesos lineales de tres o más pasos. No lo recomienda con menos de tres pasos, cuando los pasos pueden completarse en cualquier orden ni cuando el número de pasos cambia por lógica condicional.

Ninguna de las fuentes citadas fija un máximo. La regla práctica es que cada paso tenga una razón para existir. Si dos pasos se pueden juntar sin que el usuario se pierda, conviene juntarlos. Si un paso es tan largo que el usuario abandona a mitad, conviene dividirlo.

¿Cómo se muestra el progreso?

Carbon define estados visibles para cada paso: completado, actual, sin empezar, con error y deshabilitado. En el estado de error se debe explicar qué falló y cómo resolverlo, y cuando es posible conviene validar que el paso está completo antes de dejar avanzar.

Para las etiquetas, Carbon recomienda una o dos palabras que indiquen qué hará el usuario en ese paso, por ejemplo verbo más sustantivo, como «Definir endpoints», o una sola palabra universalmente entendida, como «Carrito» o «Pago». Evita etiquetas vagas como «Procesando».

Carbon también señala que, por defecto, el indicador no es interactivo y solo muestra el progreso; una versión interactiva deja navegar a cualquier paso. Y advierte sobre la accesibilidad de los pasos deshabilitados: no reciben foco ni los leen los lectores de pantalla, así que no conviene guardar ahí información que el usuario necesite. Decide también si el usuario puede volver atrás sin perder lo que ya escribió.

¿Cómo se revisa todo antes de confirmar?

GOV.UK recomienda mostrar una sola página de «Revisar respuestas» justo antes de la pantalla de confirmación en transacciones pequeñas o medianas. Para transacciones grandes con varias secciones, se puede añadir una página de revisión al final de cada sección, algo útil cuando distintas personas completan cada sección. GOV.UK pide probar este enfoque con usuarios antes de adoptarlo.

Cada sección lleva un enlace «Cambiar» que lleva a la pregunta correspondiente, con las respuestas ya rellenadas. Al pulsar «Continuar», GOV.UK recomienda devolver al usuario a la página de revisión sin repetir el resto del proceso. Si el cambio exige preguntas nuevas, esas preguntas se hacen antes de volver. Las preguntas opcionales sin respuesta se muestran como «No proporcionado».

Para validar cada paso sin interrumpir, el artículo sobre timing de validación de formularios explica cuándo conviene avisar del error.

¿Cuándo NO conviene un wizard?

• Con menos de tres pasos. Un indicador de dos pasos añade ruido. Un formulario corto funciona mejor.
• Cuando el orden es libre. Si el usuario puede completar la información en cualquier orden, un wizard le quita control sin necesidad.
• Con usuarios expertos o procesos frecuentes. El costo de pasar por cada pantalla se vuelve una molestia diaria.
• Cuando el número de pasos depende de lógica condicional. Según Carbon, el indicador no es adecuado en ese caso. Si cada respuesta cambia cuántas pantallas siguen, una página con secciones suele ser mejor.

Si el flujo solo tiene secciones y no es lineal, el artículo sobre chunking de flujos de UI describe cómo organizar la información en bloques sin imponer un orden.

Ejemplo

Ejemplo ilustrativo: alta de un negocio en una plataforma de pagos. Son cuatro pasos: datos del titular, datos del negocio, cuenta bancaria y verificación.

• Stepper: cuatro estados, con etiquetas «Titular», «Negocio», «Cuenta» y «Verificación». El paso actual se resalta.
• Salida: el usuario puede guardar y volver. Si cierra el navegador en el paso dos, retoma en ese punto.
• Revisión: antes de enviar, una página resume las cuatro secciones, con el enlace «Cambiar» junto a cada una. Al cambiar el IBAN, la app vuelve a la revisión sin repetir los demás pasos.
• Error: si la cuenta bancaria es inválida, el paso explica el problema y cómo resolverlo en lugar de solo marcar el error.

Un formulario de una sola página habría sido más corto en apariencia, pero habría mezclado cuatro tareas distintas y el usuario no sabría cuándo termina.

Para el caso de pagos, el artículo sobre UX de checkout amplía las decisiones de confianza y de fricción en esa parte del recorrido.

Errores comunes

• Usar un wizard para una tarea que el usuario repite a diario.
• Poner etiquetas genéricas como «Siguiente» y «Anterior» sin contexto.
• No permitir guardar ni retomar un proceso largo.
• Hacer pasos que dependen de información de otra parte de la app.
• Mostrar un stepper con pasos que cambian según las respuestas, sin avisar.
• Olvidar la página de revisión antes de confirmar.

Fuentes

• Nielsen Norman Group, Wizards: Definition and Design Recommendations
• Carbon Design System (IBM), Progress indicator: usage
• GOV.UK Design System, Check answers pattern