Day in the Life of a UI UX Designer
Te han contratado como diseñador UI UX y no sabes qué esperar del día a día real. Lo que te contaron en la carrera o en el bootcamp y lo que pasa en una empresa de producto no coinciden. Aquí va el retrato honesto de un día normal de alguien de nivel medio, con sus reuniones, su trabajo de fondo y sus puntos de presión.
La mañana empieza con ruido, no con diseño#
Tu primera hora casi nunca es diseñar. Es leer. Slack, Jira, comentarios en Figma, notificaciones de algún tablero de métricas. A veces hay un bug de producción que afecta a un flujo que diseñaste y te escriben para que mires si el problema es de diseño o de implementación.
Después suele haber una reunión corta. Daily de producto, revisión con la persona de producto, o una llamada rápida con quien desarrolla para desbloquear algo. Son reuniones de 15 a 30 minutos, pero rompen la concentración y te dejan con la cabeza en otro sitio.
Lo que funciona: revisar mensajes, contestar lo urgente y cerrar la pestaña de Slack antes de las 10. Si dejas el chat abierto, el diseño se va a un segundo plano.
Recibe la próxima guía por email
Guías nuevas y empleos recientes en un email corto. Gratis.
El bloque de trabajo profundo#
El trabajo de fondo ocurre en dos o tres horas seguidas, y tienes que defenderlas. Ahí es donde pasan las cosas de verdad: flujos, wireframes, sistemas de componentes, prototipos, ajustes tras un test con usuarios.
Herramientas reales, no la lista del anuncio de empleo:
- Figma para casi todo el diseño visual y la colaboración.
- FigJam o Miro para mapas de flujo y sesiones de descubrimiento.
- Jira o Linear para seguir el trabajo y las dependencias.
- Notion o Confluence para documentar decisiones.
- Alguna herramienta de investigación, tipo Maze, Dovetail o UserTesting, si la empresa la paga.
- Un cuaderno o un archivo de texto para pensar rápido.
El detalle que casi nadie menciona: gran parte de tu tiempo en Figma no es crear pantallas bonitas. Es ordenar capas, nombrar componentes, revisar variantes y dejar el archivo entendible para quien lo abra dentro de seis meses.
Ejemplo de cómo cambia tu trabajo real
Imagina que te piden mejorar el alta de usuarios porque la gente abandona en el paso de verificación.
Tu primer impulso es rediseñar la pantalla. Lo correcto es mirar dónde se caen, hablar con quien atiende soporte, revisar los errores del formulario y proponer un cambio pequeño que se pueda medir.
Un entregable típico de esa mañana:
- Mapa del flujo actual con los puntos de abandono marcados.
- Tres hipótesis escritas en frases simples, sin jerga.
- Un prototipo de una sola variante para validar la hipótesis más fuerte.
- Una nota breve para producto explicando qué medir después del cambio.
Las reuniones que sí importan#
A mediodía llega la reunión grande. Puede ser planning, revisión de diseño, retrospectiva o una sesión de descubrimiento con producto y negocio. Aquí se decide qué se construye, y tu opinión cuenta más de lo que crees.
Prepárate para defender decisiones con datos incompletos. Rara vez tendrás un estudio completo que respalde tu propuesta. Tendrás entrevistas de cinco personas, un par de métricas y tu criterio. Eso es normal.
Una frase que funciona en estas reuniones: "Todavía no lo sé, propongo validar con cinco usuarios antes de comprometernos con esta versión". Suena responsable y te da margen.
La presión que nadie te cuenta#
Los puntos de presión reales tienen nombres concretos. Fechas de lanzamiento que se mueven sin avisar. Cambios de alcance a mitad de sprint. Un stakeholder que pide "algo más moderno" sin decir qué quiere decir. Tres opiniones distintas sobre el mismo botón.
También está la presión interna. Verás diseños tuyos publicados con errores que no corrigiste a tiempo. Aprenderás a soltar. Perfeccionar una pantalla durante dos semanas mientras el equipo espera no es rigor, es un bloqueo.
Otra presión frecuente: la falta de investigación. Te pedirán decidir sin hablar con usuarios y tendrás que elegir entre esperar o avanzar con suposiciones. Con el tiempo aprendes a avanzar con suposiciones marcadas como tales.
Lo que sorprende a quien llega nuevo#
Lo primero: casi nadie diseña pantallas nuevas todo el día. Buena parte del trabajo es mantener, revisar, documentar y arreglar lo que ya existe. El sistema de diseño acumula deuda igual que el código.
Lo segundo: tu trabajo no termina cuando entregas el diseño. Sigues hasta que la implementación se parece a lo que acordaste. Eso implica revisar builds, comentar en pull requests y a veces ajustar el diseño a lo que el equipo puede construir en el tiempo disponible.
Lo tercero: las herramientas importan menos de lo que crees. Puedes ser muy bueno en Figma y seguir siendo un diseñador mediocre si no sabes qué problema estás resolviendo.
Un buen ejercicio al llegar: pide acceso al verificador de compatibilidad con sistemas de seguimiento y revisa cómo se lee tu propio currículum antes de la siguiente entrevista. También puedes usar el decodificador de ofertas de empleo para entender qué está pidiendo realmente una empresa cuando busca a alguien con tu perfil.
Cómo cambia el rol de junior a senior#
Como junior, te asignan tareas definidas. Diseñas una pantalla, un componente, un estado de error. Te revisan el trabajo y te dan feedback concreto. Tu foco es la ejecución y aprender el sistema de la empresa.
A nivel medio, ya decides el cómo. Tomas decisiones de flujo, negocias alcance con producto y mentorizas a quien llega. Tu trabajo se vuelve más político, en el buen sentido: aprender a que las cosas se muevan.
Como senior, decides el qué y el por qué. Planteas problemas antes de que existan tickets, defiendes prioridades frente a negocio y tu impacto se mide en resultados del producto, no en pantallas entregadas. Diseñas mucho menos y piensas mucho más.
El salto más difícil no es de habilidad técnica. Es dejar de buscar aprobación en cada decisión.
Un día concreto, hora por hora#
Para que te hagas una idea sin adornos:
- 9:00 a 9:30: revisar mensajes, comentarios en Figma y el tablero de bugs.
- 9:30 a 10:00: daily del equipo de producto.
- 10:00 a 12:30: trabajo profundo en un flujo nuevo, Slack cerrado.
- 12:30 a 13:00: responder dudas de quien desarrolla sobre un componente.
- 13:00 a 14:00: comida, de verdad, sin pantallas.
- 14:00 a 15:00: revisión de diseño con producto y negocio.
- 15:00 a 16:30: iterar según el feedback de la revisión.
- 16:30 a 17:00: documentar decisiones y actualizar el tablero.
- 17:00 a 17:30: revisar la implementación en curso y dejar notas.
No todos los días son así. Los días de lanzamiento son caos ordenado y los de investigación son casi todo llamadas.
Cómo prepararte si estás buscando este puesto#
Antes de tu próxima entrevista o tu próximo día en el trabajo, revisa esto:
- Practica explicar una decisión de diseño en dos minutos, sin jerga.
- Ten un ejemplo real de un desacuerdo con producto y cómo lo resolviste.
- Aprende lo básico de cómo se implementan tus diseños, no hace falta que programes.
- Prepara un caso donde cambiaste de opinión gracias a datos o a usuarios.
- Revisa tu currículum con el verificador de compatibilidad con sistemas de seguimiento para que no se pierda en el filtro.
- Lee ofertas reales en el buscador de empleo para entender qué pide hoy el mercado a tu nivel.
- Sigue leyendo sobre el oficio en nuestro blog de desarrollo profesional.
Herramientas gratis#
- jobrise.io/es/free-ats-checker/
- jobrise.io/es/free-jd-decoder/
- jobrise.io/es/jobs/
- jobrise.io/es/blog/
Preguntas frecuentes#
¿Cuánto tiempo de reuniones tiene un diseñador UI UX al día?
Entre dos y cuatro horas es lo habitual en empresas de producto, dependiendo del nivel y de la fase del proyecto. Los seniors suelen tener más reuniones que los juniors porque participan en decisiones de alcance y prioridad.
¿Hay que saber programar para ser diseñador UI UX?
No hace falta escribir código de producción, pero entender cómo se implementan las interfaces te cambia la vida. Saber qué es factible y qué cuesta caro construir te da credibilidad con quien desarrolla y evita diseños imposibles.
¿Qué herramientas se usan realmente en el día a día?
Figma es el centro de casi todo. Alrededor están Jira o Linear para gestión, Notion o Confluence para documentación, y alguna herramienta de investigación de usuarios si la empresa la paga. El resto varía mucho según el equipo.
¿Cuánto gana un diseñador UI UX de nivel medio?
Los sueldos varían mucho según el país, el tamaño de la empresa y si es presencial o remoto. En general se reportan rangos amplios para perfiles de nivel medio en España y Latinoamérica, así que conviene consultar fuentes oficiales y actuales de tu país antes de negociar.
¿Cómo se pasa de junior a senior en diseño de producto?
Dejando de esperar que te asignen el problema y empezando a plantearlo tú. El salto se nota cuando influyes en las prioridades, guías a otros y tu trabajo se mide por resultados del producto, no por la cantidad de pantallas entregadas.
Envíaselo a quien tenga la entrevista esta semana.