Hay una escena que se repite. Abres dos ofertas de trabajo el mismo día. Una busca Product Designer: Figma, sistemas de diseño, prototipado, trabajo con desarrollo. La otra busca diseñador UX/UI: Figma, sistemas de diseño, prototipado, trabajo con desarrollo.

Mismo trabajo, dos nombres. Y sin embargo los salarios no coinciden, los procesos de selección tampoco, y a menudo ni siquiera el departamento que contrata.

La confusión no es un problema de vocabulario. Es un problema de expectativas: hay empresas que llaman Product Designer a quien maqueta pantallas y empresas que llaman UX/UI a quien decide qué se construye. El que sale perdiendo es siempre el mismo — el que entra en un puesto que no era lo que ponía en el título.

Este artículo no va de defender una etiqueta sobre otra. Va de la diferencia que sí cambia el trabajo del día a día, y de cómo saber si ya la estás haciendo.

Qué dice el mercado y por qué se contradice

Si lees veinte ofertas seguidas encuentras dos patrones, y son opuestos.

El primero: empresas que han cambiado el título sin cambiar el puesto. Buscan Product Designer porque suena mejor, atrae más candidatos y justifica pedir más. Pero el trabajo real empieza cuando el roadmap ya está cerrado: llega un requisito, lo conviertes en pantallas, lo pasas a desarrollo. Es un puesto legítimo de diseño de interfaz con un nombre inflado.

El segundo: empresas que buscan UX/UI y describen otra cosa. Piden participación en el descubrimiento, conversación con negocio, decisiones sobre alcance, seguimiento de métricas. Es trabajo de producto pagado como trabajo de interfaz, normalmente en equipos pequeños donde una sola persona cubre todo.

Los dos desajustes son reales y los dos hacen daño. El primero decepciona a quien entra esperando decidir. El segundo agota a quien entra esperando diseñar y acaba haciendo de product manager sin el título ni el sueldo.

Por eso el título de la oferta no sirve para orientarse. Lo que sirve es otra pregunta.

La diferencia que sí importa: dónde empieza tu trabajo

La distinción útil no está en las herramientas, ni en si haces research, ni en si dominas los sistemas de diseño. Todo eso lo hacen los dos perfiles.

Está en el momento en que entras.

El trabajo de UX/UI suele empezar cuando ya está decidido qué se va a construir. La pregunta que tienes delante es cómo: cómo se organiza esta información, cómo se navega, cómo se entiende a la primera, cómo se resuelve para quien tiene prisa. Es un trabajo difícil, con criterio propio y con consecuencias reales sobre si el producto se usa o no.

El trabajo de producto empieza antes. La pregunta que tienes delante es qué y para quién: qué problema merece la pena resolver, qué se queda fuera, qué es lo mínimo que hay que construir para saber si funciona, qué pasa con el negocio si sale bien o si sale mal.

No es una jerarquía. No es que uno sea la versión avanzada del otro. Son puntos de entrada distintos, y hay diseñadores excelentes que no quieren el segundo — porque implica reuniones, negociación y renunciar a parte del tiempo de diseño.

Lo que sí es cierto es que las dos preguntas se responden mejor juntas. Cuando quien decide qué se construye no ha visto nunca cómo se usa, sale un producto que se defiende bien en una presentación y se cae en la primera semana de uso real.

Tres señales de que ya estás haciendo trabajo de producto

Sin autoevaluaciones ni test. Tres cosas concretas:

Discutes el qué, no solo el cómo. Cuando llega un requisito que no encaja, no diseñas la mejor versión posible de una mala idea: preguntas qué problema venía a resolver. A veces se hace igualmente y a veces no. Pero la conversación existe.

Sabes qué métrica mueve tu decisión. No «mejorar la experiencia». Algo que se cuenta: cuánta gente termina el proceso, cuánto tarda, cuántos errores comete, cuántas veces tiene que volver atrás. Si no puedes nombrar la cifra que debería moverse, estás diseñando a ciegas y confiando en el gusto.

Puedes explicar qué pierdes con la opción que elegiste. Esta es la que más separa. Toda decisión de producto cierra puertas. Quien solo puede contar las ventajas de su solución todavía no ha decidido nada: ha ejecutado. Quien puede decir «elegí esto y a cambio renuncié a aquello, y aquí está por qué me compensó» ha hecho trabajo de producto, se llame como se llame en su contrato.

Lo que no cambia

Conviene decir la parte antipática.

Nada de lo anterior sustituye al oficio. Investigación, arquitectura de la información, prototipado, interfaz y sistemas de diseño siguen siendo el trabajo. No son la parte junior que se deja atrás al ascender a las decisiones importantes.

Un Product Designer que no sabe diseñar una interfaz es un product manager con Figma abierto. Puede tener buen criterio sobre el problema y ser incapaz de resolverlo en pantalla, que es exactamente donde el usuario se lo va a encontrar.

Y al revés: el criterio de producto sin capacidad de ejecución no se nota en ningún sitio. Las decisiones sobre qué construir se validan construyendo. Si no puedes llevar tu decisión hasta una pantalla que alguien use, no vas a saber si era buena.

La diferencia entre los dos perfiles es de alcance, no de nivel. Y el alcance más amplio no vale de nada sin el oficio debajo.

Cuándo me empecé a llamar Product Designer

Llevo años trabajando como diseñador UX/UI y tardé en cambiar la etiqueta. No por modestia: porque no me parecía defendible hasta que pude señalar una decisión concreta que no era de interfaz.

La decisión fue en Nexo Clinical, una historia clínica electrónica para transporte sanitario urgente. Al diseñar el flujo de un servicio, la opción evidente era permitir que varios miembros del equipo editaran el mismo registro desde distintos dispositivos. Es lo que espera cualquiera y es lo que hace casi todo el software.

Decidí lo contrario: un solo dispositivo por servicio. No por simplificar la interfaz, sino porque en una ambulancia en movimiento, con cobertura intermitente, la sincronización entre dispositivos falla — y cuando falla, el conflicto lo resuelve alguien que tiene un paciente delante. El coste de un dato mal fusionado no es una mala experiencia: es un dato clínico incorrecto.

Esa decisión cerró puertas. Elimina el trabajo simultáneo, obliga a un traspaso explícito y complica algunos escenarios. La tomé sabiendo lo que perdía.

Ahí entendí que ya no estaba decidiendo cómo se veía algo. Estaba decidiendo qué no se podía hacer, y por qué compensaba. Cuando tuve esa frase, cambié la etiqueta.

Entonces, ¿cuál pongo en mi perfil?

La respuesta honesta: la que puedas defender en una conversación de veinte minutos.

Si te llamas Product Designer, alguien te va a preguntar por una decisión de producto que hayas tomado. No por un proyecto bonito: por una decisión, con sus alternativas y su coste. Si tienes una, la etiqueta es tuya. Si no la tienes todavía, no pasa nada — pero cambiarla antes solo adelanta el momento incómodo.

Y si eres diseñador UX/UI y te gusta serlo, tampoco hay nada que arreglar. El problema no es la etiqueta. Es entrar en un sitio donde esperaban otra cosa.