Product Designer · Orange España · 2022
Cuando pedir ayuda cuesta más que resolver el problema
Rediseño del centro de ayuda de Orange España, el primer punto de contacto de soporte para millones de clientes cada mes.
Product Designer
10 semanas
1 Product Designer · 2 Product Owners · equipo de desarrollo
Figma · FigJam · Analítica web · Tickets de soporte
Reducir los contactos de soporte evitables mejorando la autonomía del usuario dentro del centro de ayuda.
Disciplinas — UX Research · Information Architecture · UI Design · Design System
De un contenido desordenado a una estructura que se sostiene sola
El centro de ayuda había crecido sin arquitectura definida: categorías duplicadas, navegación distinta en cada pantalla y un volumen alto de contactos por dudas que ya estaban respondidas en el propio contenido.
Analizar la investigación disponible junto a Product Owners, definir la nueva arquitectura de información y liderar el diseño UX/UI de las pantallas de home, categoría y desglose.
Una plantilla única para las tres pantallas, con buscador prioritario, categorías agrupadas por intención, top de preguntas frecuentes y acceso directo a soporte por varios canales.
Una navegación coherente de principio a fin, menos pasos hasta la respuesta correcta y una base de contenido preparada para crecer sin repetir la misma desorganización.
Un centro de ayuda que creció más rápido que su propia estructura
Durante años, distintos equipos fueron añadiendo contenido al centro de ayuda sin un criterio compartido de arquitectura de información. El resultado era una cascada de secciones que se repetían con nombres distintos, categorías solapadas y un menú que cambiaba de formato entre pantallas: cuadrícula en la home, lateral en las páginas de categoría, y sin relación visible entre unas y otras.
Para el usuario, esto se traducía en una búsqueda de respuestas que rara vez terminaba donde debía. Encontrar una duda ya resuelta costaba varios clics de más, y cuando la respuesta no aparecía con claridad, la salida natural era llamar o escribir a soporte — incluso cuando el contenido para resolverlo ya existía en la propia web.
Entender el problema antes de tocar una pantalla
Antes de plantear cualquier solución visual, revisamos las búsquedas más frecuentes en el buscador interno, los tickets de soporte para identificar los motivos de contacto recurrentes, los flujos de navegación y puntos de abandono, la taxonomía completa de categorías y las incidencias reportadas por el equipo de atención al cliente.
Insights
• Buena parte de los tickets correspondía a preguntas ya resueltas en el centro de ayuda, mal categorizadas o difíciles de localizar.
• El buscador interno era la herramienta más usada, pero devolvía resultados poco relevantes.
• La mayoría de usuarios abandonaba la navegación tras dos o tres clics sin encontrar respuesta.
• Existían categorías duplicadas o con nombres poco claros para alguien ajeno a la estructura interna.
• La estructura de navegación cambiaba de una pantalla a otra, obligando a reaprenderla en cada nivel.
Qué patrones se repiten en los centros de ayuda de referencia
Analizamos centros de ayuda de compañías de telecomunicaciones, banca y servicios digitales con alto volumen de usuarios, buscando patrones comunes más allá del sector, no solo soluciones estéticas.
Patrones comunes y cómo influyeron en el diseño
• El buscador ocupa un lugar prioritario, visible sin necesidad de hacer scroll — pasó a ser el primer elemento de la home.
• Las categorías se agrupan por intención del usuario, no por la estructura interna de la compañía — reorganizamos las categorías según motivos de contacto reales.
• Las preguntas más frecuentes se muestran antes de navegar — dio lugar al bloque de top de preguntas en la propia home.
• El acceso a soporte humano permanece siempre visible, incluso cuando el objetivo es la autoresolución — confirmó mantener el contacto directo como salida disponible en todo momento.
De tres pantallas independientes a un modelo único
Cada pantalla del centro de ayuda seguía su propia lógica de navegación. El primer paso no fue diseñar, sino definir una estructura común que se repitiera de forma predecible en home, categoría y desglose.
Antes
↓
↓
Después
↓
↓
Cuatro prioridades, no una lista de funcionalidades
Buscador como entrada principal
Era la vía más rápida hacia la respuesta correcta y la que más usaban los clientes con una necesidad concreta, según el análisis de tickets y búsquedas.
Categorías por intención
Reducir duplicidades agrupando por motivo de contacto real, no por la estructura interna de Orange.
Preguntas frecuentes visibles
Resolver antes de navegar: muchas dudas se repetían y no justificaban explorar todo el árbol de categorías.
Acceso directo a soporte
Ninguna decisión de autoservicio debía cerrar la puerta a hablar con una persona cuando fuera necesario.
Mismo contenido, otra jerarquía
Antes — Home
Tres columnas de texto sin jerarquía clara y un menú en cuadrícula que no anticipaba lo que había detrás de cada categoría.
Después — Home
Buscador como primer elemento, menú de secciones unificado y top de preguntas por categoría: menos lectura, más decisión.
Antes — Categoría
Menú lateral distinto al de la home, obligando a reaprender la navegación al pasar de pantalla.
Después — Categoría
Misma cabecera y misma lógica que en la home: la navegación se reconoce en lugar de reaprenderse.
Antes — Desglose
Pantalla final desconectada visualmente de las dos anteriores, sin una salida clara hacia soporte.
Después — Desglose
Misma plantilla visual y cierre siempre con contacto directo por varios canales.
Una plantilla, tres pantallas resueltas
Categoría: agrupación por intención de contacto y top de preguntas antes de seguir navegando.
Home: buscador prioritario y menú de secciones unificado como puerta de entrada única.
Desglose: pestañas de categoría que despliegan el listado completo de preguntas frecuentes de ese tema, sin salir de la pantalla.
Lo que me llevo
Una arquitectura de información débil no se corrige con estilos: hay que rehacerla desde la lógica de navegación, no desde la pantalla que se ve peor.
Los datos reales — tickets, búsquedas, analítica de navegación — revelan patrones de fricción a una escala que ninguna entrevista aislada permite ver.
Trabajar codo a codo con negocio y Product Owners exige traducir cada decisión de diseño en impacto medible: menos contactos evitables, no solo una interfaz más cuidada.
Muchas gracias.
← Volver a proyectos