Vuelvo a uno de los temas más clásicos del blog: el rol de UX Engineer. Ya os he hablado de qué hace un UX Engineer y de cómo es su día a día, pero hoy me apetece profundizar un poco más comparándolo con el UX Designer. Porque la pregunta sigue apareciendo, y merece una respuesta honesta.
¿Son realmente roles distintos o solo otra etiqueta para lo mismo?
La respuesta corta es: depende🙃 Pero la respuesta larga es mucho más interesante.
Qué hace un UX Designer (de verdad)
Un UX Designer no es alguien que hace pantallas bonitas. Es alguien que toma decisiones sobre cómo debería funcionar algo antes de que exista.
Trabajamos con incertidumbre. Con información incompleta. Definimos estructura, flujos, jerarquías, comportamientos. Nos hacemos preguntas como: ¿qué necesita el usuario en este momento? ¿Qué pasa si no hay datos? ¿Qué pasa si hay demasiados? ¿Por dónde entra, por dónde sale, dónde se puede perder?
La herramienta principal no es Figma. Es el criterio. Figma es donde aterriza ese criterio, no donde nace.
Qué hace un UX Engineer (y por qué no es solo «el diseñador que sabe código»)
Aquí es donde mucha gente falla al describir este rol.
Un UX Engineer no es un diseñador al que le gusta programar en su tiempo libre. Es alguien que trabaja en la frontera entre el diseño y la implementación → y que entiende los dos lados lo suficientemente bien como para tomar decisiones en ese espacio intermedio.
Convertimos decisiones de diseño en comportamiento real. Sabemos qué es fácil de implementar y qué no, y eso cambia cómo diseñamos. Entendemos que una animación que parece simple en Figma puede costar mucho tiempo de desarrollo. Que un componente mal especificado va a generar preguntas en el handoff, y que esas preguntas cuestan tiempo y fricción.
La diferencia real
Si tuviera que resumirlo en una sola frase:
El UX Designer decide qué debería pasar. El UX Engineer se asegura de cómo pasa realmente.
Y eso, en la práctica, se nota en los detalles que más se suelen olvidar. ¿Cómo se ve un botón cuando está deshabilitado? ¿Qué muestra la interfaz mientras carga? ¿Qué mensaje aparece cuando algo falla? ¿Cómo se reorganiza el layout en móvil cuando el texto es el doble de largo de lo esperado?
Estos son los momentos donde el diseño se rompe o se sostiene. Y son exactamente los momentos donde el UX Engineer vive.
Dónde se rompe todo
El problema más frecuente que vemos en equipos — y que hemos vivido en primera persona — no es la falta de talento. Es la distancia entre lo que se diseña y lo que se implementa.
Diseños que no contemplan los edge cases. Handoffs que especifican el happy path y dejan el resto a criterio del desarrollo. Decisiones de diseño que cambian en el proceso de implementación porque nadie había pensado en la restricción técnica que aparece a mitad del sprint.
El resultado es una interfaz que funciona, pero que ha perdido la intención original por el camino. Y muchas veces nadie sabe exactamente dónde se perdió.
¿Y hay que saber programar para evitar esto?
No necesariamente. Los diseñadores UI/UX no tienen la obligación de saber programar → pero entender aunque sea las bases del front-end cambia completamente la conversación con el equipo de desarrollo. Reduce los malentendidos, acelera las decisiones y hace que el diseño llegue a producción más parecido a lo que se imaginó.
Entonces, ¿son roles distintos?
A veces sí. En empresas grandes con equipos especializados, el UX Designer y el UX Engineer son perfiles diferentes con responsabilidades claras y complementarias. A veces no. En equipos pequeños o medianos, una sola persona cubre ese espacio intermedio (como en mi caso). Y a veces el UX Engineer es simplemente un UX Designer que ha decidido entender el lado técnico de su trabajo → no porque le obliguen, sino porque no tiene mucho sentido diseñar sin saber qué pasa después.
El problema no es el nombre del rol
Los títulos cambian. Lo que no cambia es la pregunta que debería hacerse cualquier persona que diseña interfaces: ¿sabemos lo que pasa después de que entregamos esto?
No hace falta saber programar para ser buen diseñador. Pero sí hace falta entender, aunque sea a grandes rasgos, cómo funciona lo que diseñamos, qué es técnicamente sencillo y qué no, y cómo nos comunicamos con el equipo que lo va a construir.