Success / confirmation pages

Lo primero que el usuario debe ver en una página de confirmación es una declaración inequivoca de que su acción específica se completo: que paso y que sigue. Un escueto "Gracias" no basta, porque deja al usuario sin saber si el sistema recibio su petición. El GOV.UK Design System formula la confirmation page como un requisito explicito: debe "tranquilizar al usuario de que completo la transacción y ayudarle a entender que esperar después". Encabeza con un título de exito prominente, acompanado de un icono y un color de estado verde.

Todo flujo de confirmación (compra, registro, solicitud, formulario) debe generar y mostrar un identificador único: número de orden, folio o ticket ID. Ese número es el ancla que permite al usuario contactar soporte, verificar su estatus y cerrar la incertidumbre. El GOV.UK Design System lo lista como elemento requerido: "incluye un número de referencia (si aplica)". Ponlo en texto seleccionable (no dentro de una imagen) y agrega un botón de "Copiar"; enterrarlo en un párrafo de 12px obliga al usuario a buscarlo en el email.

El usuario necesita confirmar que se compro, registro o envio. Un resumen de orden (productos, cantidades, precios, dirección de envio) o de los datos del formulario cumple dos funciones: permite detectar errores de inmediato y alivia la ansiedad cognitiva al cerrar el loop. Baymard documenta como "commonly observed issue" que los usuarios "luchan por verificar su compra" en páginas sin resumen; su benchmark abarca 874 ejemplos de pantallas de recibo y confirmación de pedido en 327 sitios. Omitir el resumen fuerza a esperar el email para verificar el pedido.

Una confirmation page sin acciones es un dead-end que abandona al usuario justo cuando su engagement es máximo. Como mínimo incluye: enlace para ver el estado del pedido, acceso a soporte y ruta de regreso al sitio. El GOV.UK Design System requiere de forma explicita "enlaces relevantes a información o servicios que el usuario pueda necesitar" y una "opción de registro de la transacción" (descarga de PDF). Las acciones secundarias de bajo riesgo (descargar recibo, crear cuenta) anaden valor, pero siempre después de la información esencial y con jerarquía clara.

El usuario que no sabe cuando llegara su pedido, cuando recibira el email o que pasa en las proximas horas se queda con ansiedad activa. La confirmation page debe incluir fecha o rango de entrega estimada, tiempo esperado para el email de confirmación y los proximos pasos del proceso. Baymard observa que los usuarios "se quedan esperando en la página durante minutos hasta confirmar que recibieron el email de confirmación", comportamiento de ansiedad por falta de tiempos. La vaguedad ("en breve recibiras un correo") genera más contactos de soporte que la precisión.

Cuando la confirmación aparece en la misma página sin recargar (SPA, AJAX, modal), los usuarios de lector de pantalla no perciben el cambio si el contenido nuevo no tiene un rol ARIA correcto. role="status" con aria-live="polite" garantiza que el lector anuncie el mensaje sin robar el foco ni interrumpir agresivamente. WCAG 2.2 SC 4.1.3 (AA) exige que los mensajes de estado sean determinables programaticamente; la técnica suficiente es ARIA22. Clave: el contenedor con role="status" debe estar en el DOM vacio desde la carga inicial e inyectar solo el texto después; agregar el rol junto con el texto falla en VoiceOver y NVDA.

La confirmation page es el único momento post-transacción con atención garantizada, y es tentador saturarla con ofertas. Pero anteponer cross-sells, banners de descuento o popups al resumen de la compra viola la expectativa del usuario y genera desconfianza. La regla: primero el bloque de confirmación completo (encabezado, número, resumen, tiempos) y solo después las acciones auxiliares de bajo riesgo. Baymard lo establece de forma explicita: las mejoras "sirven como adiciones suplementarias, no como reemplazos"; sitios como Overstock posicionan los cross-sells al fondo, no arriba.

El usuario no solo consume la confirmation page en el momento; la usa como recibo días después. Dos mecanismos son obligatorios: enviar un email de confirmación con todos los datos relevantes y mantener la página accesible si el usuario vuelve con el enlace guardado. El GOV.UK Design System documenta que "algunos usuarios marcaran la confirmation page como un recibo" y que la respuesta preferida es "permitirles volver a la página siempre que sea posible". Si la sesión expiro, ofrece un fallback útil (tracking, nuevo inicio, contacto); nunca un 404 o un redirect silencioso al home. NN/g califica los correos de confirmación con 5.9/7 de satisfacción promedio, prueba de que el email es parte integral de la experiencia.