El día de un diseñador UX/UI se parece poco a lo que muestran los portfolios. Menos tiempo del que se imagina va a dibujar pantallas y mucho más a entender el problema, alinear expectativas y explicar decisiones. Diseñar es la parte visible; el resto del trabajo es lo que hace que esa parte tenga sentido.

Esta nota reconstruye una jornada típica en un equipo de producto, con las herramientas concretas de cada etapa y —lo más importante— el criterio con el que se decide qué hacer primero cuando todo parece urgente.

9:00 — Arranque: revisar antes de crear

El día no empieza en el archivo de diseño. Empieza revisando qué cambió desde ayer: comentarios en las pantallas, preguntas del equipo de desarrollo sobre una entrega anterior, algún dato nuevo de analítica o un ticket de soporte que expone un problema de usabilidad.

Esta media hora define la prioridad del día. Un desarrollador bloqueado esperando una definición de un estado de error pesa más que cualquier exploración visual pendiente: su tiempo detenido cuesta más que el tuyo.

Herramientas típicas: Figma para comentarios, Slack para consultas, Jira o Linear para el estado del sprint, y un panel de analítica para ver el comportamiento real.

9:30 — Daily con el equipo

Quince minutos con producto, desarrollo y QA. El diseñador no reporta tareas de diseño: reporta qué está bloqueando a otros y qué necesita para desbloquearse. Es la instancia donde se detecta que la funcionalidad que estabas diseñando cambió de alcance, antes de invertir tres días en ella.

10:00 — Bloque de discovery

Antes de proponer solución hay que entender el problema. Según la etapa, este bloque puede ser:

• Entrevistas con usuarios: cuatro o cinco conversaciones alcanzan para detectar los patrones principales.

• Análisis de datos: dónde abandonan el flujo, qué pantalla concentra el error, cuánto tarda una tarea.

• Revisión de soporte: los tickets repetidos son la lista de problemas de usabilidad mejor documentada y gratuita que tiene cualquier empresa.

• Benchmark: cómo resolvieron esto otros productos, para no reinventar patrones que los usuarios ya conocen.

Es la etapa que más diferencia a un diseñador senior de uno junior. El junior recibe "hacé una pantalla de checkout"; el senior pregunta qué problema estamos resolviendo y para quién. Los materiales públicos del Nielsen Norman Group siguen siendo la mejor referencia gratuita sobre métodos de investigación, y su informe abierto sobre carreras en experiencia de usuario muestra con datos cómo se reparten las actividades entre perfiles de diseño e investigación.

Herramientas típicas: FigJam o Miro para mapear hallazgos, Maze o UserTesting para pruebas remotas, Notion para documentar, y una hoja de cálculo para ordenar datos.

11:30 — Bloque de diseño concentrado

Acá aparece lo que la mayoría imagina como "el trabajo": wireframes de baja fidelidad para probar la estructura, iteración sobre el flujo, y recién después la interfaz visual usando los componentes del sistema de diseño.

Un principio que ahorra semanas: no diseñes en alta fidelidad lo que todavía puede cambiar de estructura. Cuando una pantalla se ve terminada, la conversación se desvía a colores y tipografías, y nadie discute si el flujo tiene sentido.

El bloque también incluye lo que no se muestra en un portfolio: estados vacíos, de carga y de error, mensajes, comportamiento responsive y verificación de contraste y accesibilidad. Un flujo sin sus estados es un flujo a medio terminar.

Herramientas típicas: Figma para todo el proceso, el sistema de diseño como fuente de componentes, y herramientas de IA para generar variantes de copy o explorar alternativas rápido. Las actualizaciones de producto de Figma del último tiempo empujaron fuerte en esa dirección.

14:00 — Revisión con stakeholders

La reunión donde más diseños mueren. La diferencia entre salir con una decisión y salir con veinte comentarios contradictorios está en cómo se presenta:

• Empezá por el problema y el dato que lo respalda, no por la pantalla.

• Mostrá una propuesta principal y una alternativa, nunca cinco opciones equivalentes.

• Pedí decisiones concretas: "¿aprobamos este flujo para pasar a desarrollo?" en lugar de "¿qué les parece?".

• Anotá quién pidió qué. Evita rehacer lo mismo dos semanas después.

15:30 — Handoff con desarrollo

Entregar un archivo no es hacer handoff. Lo que necesita el equipo de desarrollo es: espaciados y tokens definidos, comportamiento responsive explicado, todos los estados de cada componente, transiciones y casos borde documentados —qué pasa con un nombre de 60 caracteres, con la lista vacía, con la conexión caída—.

El tiempo invertido acá se recupera multiplicado: cada caso no documentado vuelve como una consulta, una interpretación libre o un retrabajo.

16:30 — Cierre: sistema de diseño y documentación

La última hora suele ir a mantenimiento: actualizar componentes, documentar decisiones, ordenar el archivo para que otro pueda retomarlo. Es trabajo invisible que evita que en seis meses existan cuatro botones primarios distintos.

Cómo se prioriza cuando todo es urgente

Qué cambió con la inteligencia artificial

La IA absorbió buena parte de la producción mecánica: generar variantes de una pantalla, escribir textos de interfaz, sintetizar entrevistas, producir imágenes de referencia. Eso liberó horas, pero también subió la vara: si generar opciones ya no es el cuello de botella, el valor se corre hacia decidir cuál es la correcta y poder defenderla.

Los perfiles que mejor están capitalizando el cambio son los que usan IA para acelerar el discovery —resumir decenas de entrevistas o tickets en patrones— y no solo para producir pantallas más rápido. Si querés ver qué competencias están pidiendo hoy las empresas, este análisis de las habilidades de UX/UI más buscadas en ofertas activas lo desarrolla con datos.

Cursos recomendados de Coderhouse

• Para empezar: el Curso de Diseño UX/UI cubre el proceso completo, de la investigación al prototipo, con proyectos que sirven como portfolio.

• Para profundizar en la etapa que más diferencia: el Curso de UX Research trabaja métodos de investigación, entrevistas y testing, que es lo que separa a un maquetador de un diseñador de producto.

• Para el perfil completo: la Carrera de Diseño UX/UI integra research, interfaz, sistemas de diseño y handoff en un recorrido largo.

• Para sumar la capa de IA: el Curso de Introducción a la Inteligencia Artificial te da la base para incorporar IA a tu flujo de trabajo con criterio.

Preguntas frecuentes

¿Cuántas horas por día diseña realmente un diseñador UX/UI?

En un equipo de producto, entre tres y cuatro horas de trabajo concentrado en el archivo de diseño. El resto se reparte entre investigación, reuniones, handoff y documentación. En equipos chicos o agencias la proporción de diseño puro suele ser mayor, pero también lo es la cantidad de proyectos en paralelo.

¿Hace falta saber programar para trabajar en UX/UI?

No es requisito, pero entender cómo funciona el desarrollo frontend mejora mucho el handoff: te permite proponer soluciones viables, dimensionar el costo de una decisión y comunicarte con el equipo técnico sin intermediarios. No necesitás escribir código de producción; sí entender qué implica lo que estás pidiendo.

¿Qué diferencia hay entre UX y UI?

UX se ocupa de la experiencia completa: qué problema resuelve el producto, cómo está estructurado el flujo y si la persona logra su objetivo. UI se ocupa de la interfaz visual: componentes, jerarquía, tipografía, color y estados. En la mayoría de las posiciones de la región ambas responsabilidades conviven en el mismo rol.

¿Cuál es el error más común de los diseñadores junior?

Saltar directamente a la solución visual sin haber entendido el problema, y entregar flujos sin sus estados de error, carga y vacío. Ambos generan retrabajo y son la principal fuente de fricción con el equipo de desarrollo.

¿Qué herramientas hay que dominar sí o sí?

Figma es prácticamente obligatorio, junto con FigJam o Miro para trabajo colaborativo. Después conviene tener nociones de alguna herramienta de testing remoto, de un gestor de tareas como Jira o Linear, y de analítica para leer el comportamiento real de los usuarios. Sumar herramientas de IA al flujo dejó de ser opcional en la mayoría de los equipos.