Resumen del proyecto
El reto
Mediante un análisis asistido por IA de todos los tickets de soporte de 2025, detecté un notable potencial de optimización en los mensajes de error. Esta conclusión basada en datos, combinada con el feedback de clientes existente y otros problemas relacionados con los mensajes de error, confirmó la alta prioridad de la mejora y contó con un fuerte respaldo del equipo directivo.
Como diseñador UX iniciador, mi reto fue desarrollar una solución sistemática que fuera más allá de correcciones superficiales. El objetivo era crear un marco escalable y centrado en el usuario que contribuyera de forma medible a la reducción de los costes de soporte, aumentando la autonomía del usuario.
Objectivos
-
Reducción gradual del volumen de tickets de soporte
-
Aumento de la tasa de auto-resolución
-
Establecimiento de un marco coherente, escalable y comprensible para todos los mensajes de error
-
Implementación de ayuda asistida por IA en los mensajes de error
Problemas
-
Hasta el 45 % de todos los tickets de soporte están relacionados con mensajes de error poco claros, lo que ocupa valiosos recursos de desarrollo en tareas de soporte.
-
Los mensajes vagos sin una guía de solución generaron callejones sin salida que detuvieron la productividad de los usuarios y provocaron frustración.
-
La falta de contexto en los mensajes de error obligaba a consultas que consumían tiempo y retrasaban significativamente la resolución de los problemas durante el soporte.
Alcance del proyecto
-
UX Research
-
UX Strategy & Systems Thinking
-
Product Design
Duración
-
Noviembre 2025 - Diciembre 2025
Función
-
Lead UX
Instrumentos
-
Figma
-
Mural
-
ServiceNow
-
Confluence/Jira
Proceder
01.
Descubrimiento del problema y encuadre estratégico
02.
Diseño del framework y prototipado
03.
Validación multi-pista con usuarios y desarrolladores
04.
Síntesis y hoja de ruta estratégica
01. Descubrimiento del problema y encuadre estratégico
Mediante un análisis transversal de los tickets de soporte identifiqué un problema crítico con alto valor de negocio. Cuantifiqué el impacto en el negocio para elevar la iniciativa de una simple mejora de interfaz a un proyecto estratégico.
Proactivamente incorporé la mejora de los mensajes de error en la planificación trimestral. Un análisis de los tickets de ServiceNow (T1–T4 2025) mostró que de forma constante entre el 35 % y el 45 % de todas las solicitudes de soporte estaban relacionadas con mensajes de error poco claros. Esta métrica proporcionó una base de datos incuestionable para priorizar el tema. El análisis también identificó las cuatro áreas más críticas donde estas deficiencias generaban los mayores costes de soporte y la mayor frustración.
1
Projekt-Deployment & -Release
3
Ai Services & DOX
.png)
2
Externe Konnectivität
(Destinations, Actions, and Mail Server)
4
In-Studio Authoring Experience (Saving & Editing)
Del análisis cualitativo posterior surgió una imagen clara de la experiencia actual:
-
Opacos e inoperables: Mensajes genéricos como “Something went wrong” no ofrecían vía de resolución.
-
Poca detectabilidad: La información crítica estaba tan oculta que 5 de cada 6 usuarios abrían inmediatamente las herramientas de desarrollo (F12) para diagnosticar.
-
Contenido engañoso: Los detalles disponibles eran a menudo imprecisos y enviaban a los usuarios a búsquedas prolongadas.
A partir de estos hallazgos identifiqué tres necesidades claras de los usuarios que sirvieron de base para la solución:
-
Contenido claro y accionable: Una explicación comprensible del problema y los pasos para resolverlo.
-
Información contextual: El paso exacto y los datos que desencadenaron el error.
-
Navegación directa: Mensajes de error clicables que llevan directamente a la fuente del problema
La síntesis completa de esta fase inicial del proyecto está disponible aquí como documento.
02. Diseño del framework y prototipado
A partir de los hallazgos del discovery, desarrollé un marco de diseño escalable en lugar de soluciones aisladas. Prototipos dirigidos para cuatro "Niveles de Asistencia" sirvieron de base para probar sistemáticamente hipótesis sobre la ayuda al usuario.
Apoyándome en la síntesis de la Fase 1, primero mapeé todo el espacio de soluciones para la asistencia dentro de los mensajes de error. La anatomía de un mensaje de error eficaz es sencilla:
-
nombra el problema,
-
explica la causa,
-
y guía al usuario hacia la solución.
Aunque las directrices de diseño SAP Fiori definían la apariencia visual, no especificaban los niveles de asistencia escalonados ni su interacción —condiciones necesarias para un marco de diseño escalable. Por eso visualicé todas las variaciones de contenido posibles para los mensajes de error como wireframes. Estos se analizaron luego en función de las áreas problemáticas identificadas en la Fase 1 para resaltar las combinaciones más efectivas.
De esta exploración surgieron cuatro patrones centrales, que transformé en hipótesis testables. Desarrollé prototipos en Figma para cuatro "Niveles de Asistencia" que representan distintas etapas de escalado en la ayuda al usuario:
-
Nivel 1: Mensaje de texto preciso para errores simples.
-
Nivel 2: Enlace contextual a la documentación de ayuda.
-
Nivel 3: Enlace profundo directo que navega a la fuente del error.
-
Nivel 4: Sugerencias de solución asistidas por IA mediante Joule.
Estos cuatro conceptos se agruparon en un prototipo interactivo para validar su eficacia en las pruebas de usuario posteriores.
03. Validación multi-pista con usuarios y desarrolladores
En un enfoque de validación dual probé los conceptos tanto con usuarios como en cuanto a viabilidad con desarrolladores. Este proceso no solo reveló las necesidades de los usuarios, sino también las causas raíz y las posibles soluciones a los problemas actuales con los mensajes de error.
3.1 Validación cualitativa con usuarios
Validé los prototipos y los niveles de asistencia con usuarios de distintas experiencias y conocimientos técnicos en sesiones remotas moderadas aplicando la metodología think-aloud. El foco estuvo en los casos críticos identificados en la Fase 1. Los hallazgos fueron esclarecedores y aportaron directrices claras de diseño:
Level | User Perception | Impact on Actionability | Representative Quote |
|---|---|---|---|
📄 Level 1: Text Only | Effective, but only for simple issues. Seen as sufficient and straightforward for specific errors (Use Case C) but frustrating for undefined problems (Use Case B). | High. Users knew exactly what to do next: either fix the simple error or follow the procedural steps (retry/contact support). | "This is pretty straightforward because it tells exactly what’s the issue like duplicate name." |
🔗 Level 2: Help Portal Link | Helpful. Universally seen as a positive, low-effort addition that saves users from having to search for documentation manually. | High. Provided a clear next step for users who needed more context to understand the syntax or rules. | "What I really like is the help link because… normally I would then like type in build help process automation and just of course it’s one step easier." |
➡️ Level 3: Actionable Link | Extremely Positive. The "Go to artifact" link was a standout feature, perceived as a highly efficient and direct way to resolve issues. | Very High. Provided the clearest and fastest path to resolution by eliminating the need for users to manually search for the problematic component. | "With my experience… it’s five, especially also with the point. I can now just jump to it." |
🤖 Level 4: AI Fix / Create | Mixed & Skeptical. While the idea of AI help was exciting, users were skeptical of a generic "Ask Joule" prompt, assuming it would provide a non-specific answer. | Low to Moderate. Most experienced users stated they would ignore the AI for complex errors and investigate manually due to a lack of trust. New users were more curious to try. | "I would now currently assume that I would get a generic answer on the type of AH, OK Yeah, all of your projects must be valid before releasing the project." |
El análisis muestra una jerarquía clara en la eficacia de los cuatro niveles de asistencia: un enlace de navegación directo (Nivel 3) obtuvo la mayor eficiencia y aceptación, mientras que la asistencia por IA (Nivel 4) fue recibida con escepticismo marcado, especialmente entre usuarios experimentados. Los expertos buscan principalmente acelerar su flujo de trabajo mediante contexto profundo; los usuarios con menos experiencia priorizan instrucciones sencillas y paso a paso.
3.2 Descubrimiento técnico y alineación arquitectónica
En la segunda parte de la validación realicé entrevistas con desarrolladores y arquitectos para evaluar la viabilidad técnica y explorar enfoques de solución. Esto reveló causas fundamentales y sistémicas de los mensajes de error deficientes y fue clave para definir una estrategia aplicable.
Las cuatro conclusiones centrales fueron:
-
Pérdida de información a través de los límites del sistema: la información detallada de errores no se propaga a lo largo de la cadena de microservicios. Solo un "Error Contract" arquitectónico y entre equipos puede garantizar que los datos de error estructurados lleguen consistentemente a la interfaz de usuario.
-
Viabilidad de los deep links: el deep link preferido por los usuarios es técnicamente viable para la mayoría de los errores de proceso en tiempo de diseño, siempre que se suministren las IDs de contexto necesarias. Esto confirmó nuestros resultados de validación con usuarios.
-
Potencial de un flujo "Easy Bug Report": los desarrolladores confirmaron que un proceso interno simple para reportar mensajes de error deficientes podría mejorar la calidad de forma continua con un esfuerzo moderado.
-
Bases para la asistencia por IA: para que la IA sea realmente útil es esencial transmitir datos de error estructurados (Log ID, Error Code, Model ID). Una función genérica de "pregúntame" sin ese contexto será percibida de forma crítica. Solo una introducción gradual de la ayuda por IA en casos donde se pueda ofrecer una solución generará confianza.
Mi experimento examinó una variable independiente de dos niveles relacionada con la diferenciación de diseños de formularios. La variación sistemática y la salida aleatoria a los participantes permitieron un análisis y evaluación de los efectos de los diferentes enfoques de diseño.
04. Síntesis y hoja de ruta estratégica
Integré los hallazgos de la validación con usuarios y del descubrimiento técnico en una hoja de ruta estratégica. Esta prioriza medidas concretas en mejoras rápidas a corto plazo y correcciones fundamentales a largo plazo.
A partir de la síntesis de las necesidades de usuarios y los hallazgos técnicos, desarrollé una hoja de ruta pragmática y orientada al impacto. Prioriza soluciones según esfuerzo e impacto, equilibrando mejoras inmediatas con correcciones arquitectónicas duraderas.
.jpg)
Recomendaciones estratégicas en tres horizontes:
-
Acciones inmediatas: Implementar deep links y mejoras de UX para los 4 escenarios de error principales, e introducir un bloque estándar de "Technical Details" con Log ID copiables para acelerar el soporte.
-
Iniciativas tácticas: Establecer un flujo "Easy Bug Report" para fomentar la mejora continua. Paralelamente, desplegar Joule con datos de error estructurados en casos de uso iniciales y específicos para generar confianza.
-
Medidas arquitectónicas fundamentales: Iniciar e implementar un "Error Contract" entre equipos para resolver la pérdida de información entre límites del sistema y sentar la base de una experiencia de error excelente.
Resultados y aprendizajes
Este proyecto creó una estrategia basada en datos, validada y con fundamento técnico, que ahora sirve como backlog priorizado para la implementación y cambiará de forma sostenible la percepción de los mensajes de error en SBPA.
Orientación estratégica mediante análisis proactivo
Mi principal aprendizaje fue que el mayor impacto no está en el diseño visual, sino en la preparación estratégica. Aprendí a usar los datos de soporte como recurso para cuantificar el valor de negocio de un problema latente y elevarlo de una molestia a una iniciativa reconocida y priorizada.
Eficiencia mediante validación dual
La validación paralela con usuarios y desarrolladores fue clave para maximizar el valor de esta investigación. Aseguró que la solución fuera tanto deseable como técnicamente factible y proporcionó una visión clara del esfuerzo, la factibilidad y la usabilidad de los elementos del espacio de soluciones.
UX como diagnóstico sistémico
Este proyecto me mostró que una mala experiencia de usuario suele ser síntoma de una causa sistémica más profunda. Demostré que el rol de UX va más allá del diseño superficial: actuamos como diagnosticadores del sistema, rastreando la cadena de causas hasta la arquitectura e iniciando y moderando las conversaciones necesarias entre disciplinas.
La confianza en la IA como resultado, no como requisito
El marcado escepticismo hacia la IA entre los expertos dejó claro que la confianza es un resultado, no un requisito: se debe ganar mediante casos de uso incrementales y demostrablemente útiles que den control al usuario y muestren con transparencia cómo la IA llegó a su recomendación.
