Caso de estudio · Enterprise · Pegasystems 2019–2025
Coherencia a escala.
Más de 20 proyectos enterprise en Europa para banca, seguros y sector público. Mi trabajo: convertir requisitos de negocio en interfaces coherentes y accesibles, y dejar un sistema y unos procesos que el equipo pudiera mantener sin mí.
- Mi papel
- Sistema de diseño, calidad de UX y procesos · Senior UI Solutions Developer
- Periodo
- Abril 2019 – julio 2025
- Equipos
- Scrum, internacionales y multidisciplinares
- Sectores
- Banca · Seguros · Sector público
Recreación de una página de component catalog de una marca ficticia. Muestra la ficha del componente Botón con sus cuatro estados (normal, hover, foco y deshabilitado), un campo de texto en estado normal, de error y deshabilitado, la guía de estilo con los colores y la tipografía de la marca, y dos buenas prácticas: «Hazlo» y «Evítalo».
El contexto
Muchos equipos, muchos países, una misma interfaz.
Durante más de seis años trabajé en proyectos de Pegasystems para bancos, aseguradoras y organismos públicos de media Europa. Eran aplicaciones grandes y críticas, construidas por equipos internacionales en los que convivían perfiles de negocio, arquitectura y desarrollo.
El reto no era solo diseñar bien una pantalla. Era que la pantalla número cien siguiera pareciéndose a la primera, aunque la hubiera construido otra persona, en otro país y meses después.
La UI llegaba tarde
Se pensaba al final del desarrollo, cuando cambiarla salía caro.
Cada uno a su manera
Sin criterios escritos, cada persona resolvía lo mismo de forma distinta.
El conocimiento se iba
Cuando alguien cambiaba de proyecto, sus decisiones se perdían.
Cómo trabajábamos
Dentro del equipo, no al final de la cadena.
- Planificación
- Sprint
- Demo
Scrum, sprint a sprint
Casi todos los proyectos funcionaban con Scrum. Estimaba historias y, según el proyecto, también definía historias y criterios de aceptación de la parte de UI.
De los requisitos a la interfaz
Trabajaba con business architects, UX designers y desarrollo para convertir los requisitos en interfaces coherentes y accesibles. A veces, también directamente con el cliente.
Auditorías y propuestas
En algunos proyectos mi trabajo era evaluar la interfaz existente, detectar problemas y presentar a stakeholders y equipos un análisis con propuestas de mejora.
Demos que enseñan
Presentaba el component catalog y las buenas prácticas a los equipos de desarrollo, y apoyaba en las demos del resto del equipo.
Qué hice
Aportar lo que le faltaba al equipo.
1 · Component catalog
En cada proyecto creaba un component catalog: una página de referencia con los componentes reutilizables, la guía de estilo adaptada a la marca del cliente y las buenas prácticas para crear piezas nuevas sin romper lo existente.
2 · Estándares a medida
Definía estándares y componentes según las necesidades de cada cliente: accesibilidad, diseño responsive y branding. El sistema crecía con el proyecto, no contra él.
3 · Formar y crear procesos
Formaba a compañeros de desarrollo y negocio en buenas prácticas de UI/UX y ayudaba a que la interfaz se tuviera en cuenta desde el primer día, no al final.
Antes
- Negocio
- Desarrollo
- UI al final
La interfaz se «maquillaba» cuando ya estaba casi todo construido. Corregir costaba tiempo y cada equipo acababa con su propia versión.
Después
- UI desde el día 1
- Componentes
- Guía viva
La UI entraba en la conversación desde el inicio, con piezas ya resueltas y criterios escritos que cualquiera del equipo podía consultar.
El resultado
Proyectos que seguían siendo coherentes sin mí.
- +20proyectos enterprise en Europa
- +20equipos Scrum internacionales
- 1component catalog por proyecto
- En más de 20 proyectos, los equipos podían crear pantallas nuevas consultando el component catalog, sin depender de mí.
- Menos idas y vueltas al final de cada entrega, porque la UI ya estaba resuelta desde el principio.
- Un lenguaje común entre diseño, desarrollo y negocio para hablar de la interfaz.
- Procesos que siguieron funcionando cuando el equipo cambiaba: incorporar a alguien nuevo era darle el catálogo, no repetir explicaciones.
Lo que de verdad la distingue es su capacidad para aprender y adaptarse más allá de los límites de su puesto, sin perder nunca de vista los objetivos del proyecto.
Lo que me llevo
Hoy lo aplico a producto.
Seis años en equipos Scrum me enseñaron que un buen producto depende tanto del proceso como de la pantalla: requisitos claros, criterios compartidos, auditorías honestas y documentación que viaja con el equipo. Es lo que aplico ahora en Hithabit y Lab Beauty, también para que la IA construya contigo y no contra tu sistema.