El diseño que funciona incluso cuando algo falla: los estados de error, los flujos de recuperación y la experiencia de usuario en los momentos de mayor fricción que define la percepción de la marca.
Cuándo usarlo: Diseñar los estados de error, los flujos de recuperación y la experiencia en los momentos de fallo que definen la percepción de calidad del producto.
Herramienta recomendada: Claude
Eres un experto en diseño de experiencias de usuario con un enfoque especial en los estados de error, los flujos de recuperación y la resiliencia de los sistemas digitales. Necesito diseñar una experiencia que funcione bien incluso cuando algo falla, porque esos son los momentos que más definen la percepción del producto. **Mi producto:** [DESCRIBE TU PRODUCTO: tipo de aplicación, flujos críticos para el usuario, tipos de errores más frecuentes que ya conoces —errores de red, timeouts, validación, permisos, datos no disponibles—, estado actual del diseño de errores] --- Ayúdame a diseñar la experiencia de usuario en los momentos de fallo: **1. La filosofía del diseño resiliente** El cambio de mentalidad antes de los componentes: - Por qué los estados de error son los más importantes del diseño: el usuario que experimenta un error frustrado y tiene una buena experiencia es más fiel que el usuario que nunca ha tenido problemas - El diseño para la realidad: los flujos de usuario feliz son el caso ideal, pero el diseño real es el que anticipa todos los momentos donde las cosas van mal - La empatía en el error: el usuario que ve un mensaje de error está frustrado, confundido o preocupado — el tono, el lenguaje y la acción ofrecida deben responder a ese estado emocional - Los errores como oportunidad de marca: cómo las páginas 404, los mensajes de error y los estados vacíos pueden ser momentos de expresión de la personalidad del producto **2. La taxonomía de los estados de error** Diseñar de forma diferente según el tipo de fallo: - **Errores de usuario**: cuando el usuario ha hecho algo mal — validación de formularios, inputs inválidos, acciones no permitidas — cómo guiarle a la solución sin hacerle sentir estúpido - **Errores del sistema**: cuando el fallo es de la aplicación — 500 errors, timeouts, servicios caídos — cómo comunicarlo con honestidad sin perder la confianza - **Errores de conectividad**: cuando el problema es la red del usuario — los offline states, los estados de carga parcial y cómo mantener la funcionalidad cuando no hay internet - **Estados vacíos**: cuando no hay datos que mostrar — el primer uso, las búsquedas sin resultados, las listas vacías — que son errores de diseño disfrazados de funcionalidad - **Errores de permisos**: cuando el usuario intenta acceder a algo que no puede — los upgrade prompts, los permission gates y cómo convertir un bloqueo en una oportunidad **3. Los principios de diseño de mensajes de error** El copy que transforma la frustración en acción: - Las cuatro partes de un buen mensaje de error: qué pasó, por qué pasó —cuando es útil—, qué puede hacer el usuario ahora mismo y cómo prevenir que vuelva a ocurrir - El lenguaje humano: cómo eliminar los códigos de error técnicos, las frases en voz pasiva y el lenguaje que culpa al usuario — los ejemplos de antes y después que mejoran el tono - La especificidad vs. la genericidad: cuándo vale la pena dar un mensaje específico sobre el error y cuándo el mensaje genérico es suficiente — el coste de mantener mensajes muy específicos - Error prevention: el diseño que evita el error antes de que ocurra — las validaciones inline, las confirmaciones antes de acciones destructivas y los constraints visuales **4. Los patrones de UI para estados de error** Los componentes que el equipo de diseño necesita: - Toast notifications vs. inline errors vs. full-page errors: cuándo usar cada uno y los criterios de decisión - El diseño de los empty states: los componentes visuales, el copy y la llamada a la acción que convierten una lista vacía en una oportunidad de engagement - Loading states y skeleton screens: cómo gestionar la espera percibida y por qué el skeleton screen reduce la frustración del usuario incluso si el tiempo de carga es el mismo - Error boundaries en la interfaz: cómo contener el error para que no afecte a todo el interfaz — el diseño modular que mantiene funcional lo que no está roto **5. Los flujos de recuperación** El camino de vuelta cuando algo sale mal: - El flujo de recuperación de sesión: cuando el usuario pierde la sesión a mitad de un flujo crítico, cómo recuperar su contexto y no hacerle empezar desde cero - La recuperación de formularios: cómo preservar el input del usuario cuando ocurre un error para que no tenga que reescribir todo - Los retry automáticos y manuales: cuándo el sistema debe intentar la operación de nuevo automáticamente y cuándo debe pedir al usuario que lo haga él con un botón claro - El diseño para la degradación graciosa: cuando una parte del sistema falla, cómo mostrar la experiencia reducida que sigue siendo útil **6. El testing de los estados de error** Validar que la experiencia de error funciona antes de que ocurra en producción: - Cómo incluir los estados de error en el design review: el checklist que asegura que todos los estados posibles están diseñados antes del handoff - User testing de errores: cómo evaluar si los mensajes de error son comprensibles y las acciones propuestas son seguidas por usuarios reales - Error analytics: cómo rastrear qué errores están viendo los usuarios, cuántos abandonan el flujo en cada estado de error y cuáles generan más contactos de soporte **7. El sistema de diseño de errores** La infraestructura para escalar: - Los componentes de error en el design system: cómo documentar los patterns de error para que el equipo los use de forma consistente - Las guías de copy de error: el tono, el vocabulario prohibido y los templates para los mensajes más frecuentes - Cómo actualizar el sistema de errores cuando el producto evoluciona Termina con el diseño de los 5 estados de error más críticos de mi producto: el mockup conceptual, el copy exacto y el flujo de recuperación para cada uno.