Gran parte del diseño de una experiencia digital se construye alrededor de un escenario en el que todo funciona como esperamos: la persona entiende qué debe hacer, el sistema responde correctamente y la tarea se completa sin interrupciones. Es el conocido happy path, una referencia útil para definir y optimizar cualquier flujo, aunque los customer journeys reales suelen incorporar muchas más variables: interrupciones, cambios de contexto, transiciones entre canales o situaciones en las que el sistema no responde como esperábamos.
Una conexión puede desaparecer durante una operación, una sesión puede caducar, una persona puede equivocarse o abandonar un proceso para retomarlo más tarde. También puede fallar un servicio externo o un sistema basado en IA generar un resultado que no responde adecuadamente a la intención del usuario.
En esos momentos aparece otra dimensión de la experiencia: la capacidad del producto para ayudar a entender qué ha ocurrido, preservar lo conseguido y permitir continuar.
❓Esto abre una pregunta interesante para UX: ¿cómo podemos diseñar productos que sigan siendo útiles cuando la realidad se sale del happy path?
Cuando el recorrido no sale como esperábamos
Diseñar el recorrido ideal permite estructurar una tarea, reducir fricción y establecer qué debería ocurrir en condiciones normales. A esta perspectiva podemos añadir el análisis de aquello que sucede cuando las condiciones cambian, porque las interrupciones, los cambios de contexto y los errores también forman parte de muchas experiencias reales.
Además, un fallo no siempre adopta la forma de un error técnico, sino que puede aparecer como:
- incertidumbre, cuando una persona no sabe si una operación se ha completado;
- ambigüedad, cuando el comportamiento del sistema no coincide con lo esperado;
- una interrupción que obliga a abandonar temporalmente la tarea.
Pensemos en una transferencia bancaria que falla en el último paso. Saber que se ha producido un error puede no ser suficiente si la persona no puede determinar si el dinero ha salido de su cuenta, si es seguro repetir la operación o si tendrá que introducir de nuevo toda la información. En ese momento, la forma en que el producto facilita la recuperación pasa a ser una parte relevante de la experiencia.
Esta misma lógica puede extenderse más allá de un flujo concreto. Dentro de un customer journey, una incidencia puede comenzar en un touchpoint y necesitar resolverse en otro: una operación iniciada en una app puede continuar en la web, mediante una notificación o a través de soporte. En estos casos, la recuperación depende también de cómo se preservan el contexto, el progreso y la continuidad entre diferentes momentos y canales de la experiencia.
Recovery UX: diseñar para poder continuar
Entender la recuperación como una capacidad de UX permite ampliar la conversación más allá del mensaje de error. Además de preguntarnos qué comunicamos cuando algo falla, podemos analizar qué información y mecanismos necesita una persona para interpretar la situación, recuperar el control y decidir cómo continuar.
Una primera dimensión es la incertidumbre. Dependiendo del contexto, puede ser importante comunicar qué ha ocurrido, qué consecuencias tiene, qué parte de la operación se ha completado y qué opciones existen a continuación. La utilidad de un mensaje de error no depende únicamente de describir correctamente el problema, sino también de cuánto ayuda a tomar la siguiente decisión.
Otra dimensión es el progreso ya realizado. Mantener los datos introducidos, guardar estados intermedios, permitir reintentar únicamente el paso que ha fallado o incorporar acciones como undo son diferentes estrategias que pueden reducir el coste de una incidencia. Si un formulario falla al enviarse, por ejemplo, la percepción del problema puede ser muy distinta dependiendo de si la información permanece disponible o es necesario introducirla de nuevo.
La recuperación también puede analizarse más allá de los errores explícitos. Conceptos como graceful degradation ayudan a plantear qué capacidades del producto resulta prioritario conservar cuando las condiciones dejan de ser óptimas. Ante una conexión limitada o la indisponibilidad temporal de un servicio externo, quizá no todas las funcionalidades puedan mantenerse, pero sí aquellas necesarias para conservar el valor principal de la experiencia.
❓Esto nos lleva a una pregunta útil durante el diseño: si algo deja de funcionar como estaba previsto, ¿qué necesita mantenerse para que el producto siga siendo útil?
Medir la recuperación, no solo el éxito
La task completion rate permite saber cuántas personas alcanzan un objetivo, pero no siempre refleja cómo ha sido el recorrido hasta conseguirlo.
Dos usuarios pueden completar una compra: uno sin incidencias y otro después de varios intentos, un error de pago y la repetición de parte del proceso. Ambos cuentan como éxito desde la métrica de finalización, aunque hayan necesitado niveles de esfuerzo muy diferentes.
En determinados flujos puede resultar interesante complementar las métricas de éxito con indicadores como recovery rate, time to recovery, esfuerzo percibido, confianza después del fallo o porcentaje de progreso preservado. La selección dependerá del producto y del tipo de tarea, pero permite incorporar otra perspectiva: no solo si la persona consiguió completar la tarea, sino qué ocurrió cuando encontró una dificultad y qué necesitó para continuar.
Los recorridos que no terminan con éxito pueden aportar también información relevante: abandonos, reintentos, retrocesos o contactos con soporte pueden ayudar a localizar momentos en los que recuperarse resulta especialmente difícil. Analizados junto con investigación cualitativa y otras señales de producto, pueden ayudar a entender qué situaciones generan mayor fricción y dónde tendría más sentido intervenir.
Esta perspectiva conecta además Recovery UX con cuestiones que van más allá de la interfaz, como la finalización de tareas, la conversión, las necesidades de soporte o la confianza en el servicio.
Cuando quien falla también puede ser la IA
Los productos basados en IA añaden nuevas situaciones a esta conversación. En una interacción generativa, el sistema puede producir resultados variables, interpretar una intención de forma diferente a la esperada o generar una respuesta que, aun siendo técnicamente válida, no resulte adecuada para ese contexto.
Esto amplía también el significado de recuperación. Ante un output poco útil, algunas experiencias pueden resolver la situación permitiendo generar una nueva respuesta. En otras puede tener más sentido corregir la interpretación, reformular instrucciones, deshacer una acción, comparar alternativas o recurrir a intervención humana.
Pensemos en un asistente de IA que ayuda a gestionar una incidencia con un pedido. La persona solicita cambiar la dirección de entrega, pero el sistema interpreta que quiere cancelar el envío. En este caso, generar una nueva respuesta puede no resolver el problema: la recuperación pasa por hacer visible qué ha entendido el sistema, permitir corregir la intención antes de ejecutar la acción y ofrecer una vía para deshacerla o recurrir a una persona si ya se ha realizado.
Este tipo de situaciones adquieren otra dimensión cuando la IA no solo genera contenido, sino que puede ejecutar acciones en nombre de la persona. A medida que aumenta ese grado de autonomía, aparecen preguntas de diseño relacionadas con la trazabilidad y la reversibilidad:
- ¿puede la persona entender qué ha hecho el sistema?
- ¿puede intervenir?
- ¿puede corregir una decisión o recuperar un estado anterior?
También resulta interesante observar desde esta perspectiva el human-in-the-loop. Además de cumplir una función de supervisión, la intervención humana puede actuar como uno de los posibles mecanismos de recuperación cuando la automatización no consigue resolver adecuadamente una situación, especialmente en tareas con mayor impacto.
Diseñar productos que sepan fallar
Pensar en recuperación no implica anticipar todas las situaciones posibles ni asumir que cualquier fricción puede eliminarse mediante diseño. Supone incorporar al análisis una realidad sencilla: las experiencias digitales también ocurren bajo condiciones imperfectas.
Esto permite ampliar el foco desde la prevención del error hacia lo que ocurre después: qué entiende la persona, cuánto progreso conserva, qué alternativas encuentra y qué esfuerzo necesita para volver a avanzar.
El happy path sigue siendo una referencia fundamental para diseñar una buena experiencia. Analizar la recuperación añade otra perspectiva: qué sucede cuando las condiciones sobre las que construimos ese recorrido dejan de cumplirse.
Quizá por eso, además de preguntarnos con qué frecuencia funciona correctamente un producto, resulte útil plantear otra cuestión: ¿hasta qué punto sigue siendo útil cuando algo no sale como esperábamos?
En GammaUX trabajamos junto a equipos de producto para diseñar y mejorar experiencias digitales a lo largo de todo su ciclo de vida, combinando investigación, diseño y evaluación para entender no solo cómo funcionan los recorridos previstos, sino también qué ocurre cuando aparecen errores, interrupciones o situaciones inesperadas. El objetivo es ayudar a construir productos más comprensibles, recuperables y resilientes ante las condiciones reales de uso.
