¿Qué evalúan realmente las entrevistas para diseñador UX?

Con quién te vas a sentar realmente

Una entrevista para diseñador UX rara vez es una sola conversación. Suele ser una secuencia: un filtro con reclutamiento, luego una revisión de portfolio con uno o dos diseñadores, después un ejercicio de diseño o desafío en pizarra, luego una ronda con las personas con las que realmente trabajarías —un product manager, un ingeniero, a veces un investigador— y a menudo una charla final con el hiring manager o líder de diseño. Las empresas pequeñas comprimen esto en dos o tres sesiones; las más grandes lo extienden durante semanas con una evaluación formal entre rondas donde los entrevistadores comparan notas en una plantilla de valoración.

La revisión de portfolio es la parte que más pesa, y normalmente la conduce un diseñador en activo, no recursos humanos. Esto importa porque ellos han construido lo que estás describiendo y conocen dónde están las costuras. No evalúan tus diapositivas. Escuchan si puedes explicar una decisión bajo presión moderada, y si la decisión fue realmente tuya.

La revisión de portfolio: qué hacen realmente

El formato estándar es "cuéntame un proyecto". Suena a charla trivial. No lo es. Un diseñador que conduce esta revisión busca algunas cosas específicas mientras hablas:

• De dónde vino el problema. ¿Un stakeholder te entregó una solución disfrazada de brief ("necesitamos un dashboard"), o llegaste a la necesidad subyacente? Si dices "el PM pidió X" y luego describes construir X, eso es una señal de alerta. Si dices "el PM pidió X, pero cuando revisé tickets de soporte e hice tres entrevistas con usuarios descubrí que la fricción real era Y", esa es la respuesta que quieren.
• Qué hiciste tú versus qué hizo el equipo. Los casos de estudio escritos para un portfolio tienden a usar "hicimos" constantemente. Un buen entrevistador interrumpirá y preguntará "¿cuál fue tu contribución específica a ese flujo?" Si no puedes separar tu trabajo del trabajo del equipo, asumen que ibas de acompañante.
• Compromisos que hiciste y por qué. No "consideramos varias opciones y elegimos la mejor" —qué opción, qué se habría perdido en cualquier caso, y qué dato o restricción inclinó la balanza. Cronograma de ingeniería, deuda técnica, guías de marca, requisitos de accesibilidad, un stakeholder que no cedía— nombra la restricción real.
• Qué pasó después del lanzamiento. ¿Miraste los números, ejecutaste una prueba de usabilidad de seguimiento, obtuviste volumen de tickets de soporte, o el proyecto terminó al entregarlo a ingeniería? Muchos candidatos no tienen respuesta aquí porque la organización nunca cerró el círculo, y un entrevistador decente lo notará sin penalizarte por ello— pero sí te penalizará si afirmas un resultado que nunca mediste.

Una respuesta superficial en una revisión de portfolio suena fluida y no dice nada verificable: "rediseñamos el flujo de onboarding y realmente mejoró la experiencia de usuario". Sin línea base, sin métrica, sin restricción nombrada, sin distinción entre tu aporte y el del equipo. Alguien que revisa portfolios profesionalmente escucha esto constantemente y deja de prestar atención en una frase.

El ejercicio de diseño o desafío en pizarra

Esta es la evaluación práctica, y su formato varía mucho según la empresa, así que sé específico sobre qué tipo te piden:

• Ejercicio en vivo en pizarra/Figma. Te dan un enunciado en el momento —"rediseña el flujo de checkout para una app de supermercado" o "diseña una forma de que dos personas dividan una cuenta"— y te piden que hagas bocetos, estructures tu pensamiento y lo expliques en tiempo real, a menudo en Figma, FigJam o literalmente una pizarra. Esto no se evalúa por pulido visual. Se evalúa por si haces preguntas de clarificación antes de dibujar nada (quién es el usuario, qué dispositivo, cuál es la restricción de negocio), si consideras más de una estructura, y si puedes defender una decisión cuando el entrevistador rebate— porque rebatirá, deliberadamente, para ver si te pliegas o razonas.
• Ejercicio para llevar. Un brief en el que trabajas durante unos días y presentas. Aquí lo que se evalúa está más cerca del trabajo real: ¿puedes delimitar un brief genuinamente ambiguo, y puedes presentar una justificación a una sala, no solo entregar pantallas? Si el brief no especifica un método de investigación, usar uno de todas formas (incluso un test guerrilla ligero con cinco personas) y mencionarlo suele notarse.
• Ejercicio de crítica. Te muestran una pantalla o flujo existente —a veces el producto de la propia empresa— y te preguntan qué cambiarías. Esto evalúa criterio más que ejecución: ¿puedes identificar el problema real de usabilidad (una jerarquía de información confusa, una convención de plataforma violada, un fallo de accesibilidad como contraste insuficiente o estados de foco ausentes) en lugar de hacer sugerencias cosméticas sobre color y tipografía?

Una respuesta superficial en cualquiera de estos suena como opinión de diseño sin usuario: "haría el botón más grande y cambiaría el color para que destaque". Un diseñador que te entrevista quiere escuchar qué problema específico resuelve el cambio —descubribilidad, ratio de contraste, tamaño de área táctil, competir con un elemento visual más fuerte cercano— e idealmente una forma de verificar si el cambio funcionó.

Las preguntas que realmente no son sobre diseño

Algunas preguntas se repiten precisamente porque son difíciles de fingir, y vale la pena nombrarlas porque no suenan a preguntas técnicas en la superficie.

"Cuéntame de una vez que un stakeholder no estuvo de acuerdo con tu diseño." Esta es una pregunta de colaboración disfrazada de historia de conflicto. Una respuesta débil termina con "y finalmente lo vieron a mi manera" o, peor, "simplemente hice lo que querían". Una respuesta sólida describe un desacuerdo específico, qué evidencia o razonamiento tenía cada lado, y una resolución que implicó cambiar algo realmente —ya sea tu diseño o tu propia perspectiva, basándose en algo que aprendiste. Si nada se mueve nunca en tus historias, eso señala que no negocias realmente, solo narras.

"¿Cómo sabes cuándo un diseño está terminado?" o "¿Cómo manejas una funcionalidad sin tiempo para investigación?" Estas sondean si tienes un proceso funcional bajo restricciones reales, no el doble diamante de libro de texto. Una respuesta superficial recita un framework por nombre —"siempre empiezo con empathy mapping, luego ideación, luego prototipado"— sin conectarlo nunca a una restricción. Un diseñador experimentado describe qué recortó y por qué: "no había tiempo para un estudio completo, así que ejecuté un test no moderado de cinco minutos en las dos pantallas más arriesgadas y lo usé para decidir entre dos direcciones".

"¿Cómo trabajas con ingeniería?" Esto verifica si entiendes qué estás entregando realmente —estados de componentes, casos extremos, estados vacíos, estados de error, no solo el camino feliz— y si alguna vez has tenido un cambio de diseño debido a una restricción técnica real que no anticipaste. Si tu respuesta implica que los ingenieros simplemente construyen lo que les envías, eso se lee como inexperiencia, no confianza.

Preguntas de métricas y negocio —"cómo medirías el éxito de esta funcionalidad", o "cómo decides qué priorizar"— verifican si puedes conectar una decisión de diseño con un número que le importa al negocio (conversión, tiempo de completación de tarea, volumen de tickets de soporte, retención) en lugar de solo a lenguaje estético o de usabilidad. No necesitas ser analista de datos, pero nombrar una métrica que realmente seguirías, aunque sea aproximadamente, te separa de alguien que nunca ha tenido que justificar un espacio en el roadmap.

Qué hacer con esto

Antes de cualquier entrevista, elige dos o tres proyectos y reconstruye la historia de cada uno alrededor de: el problema real detrás del brief, un compromiso difícil, tu contribución específica versus la del equipo, y qué pasó después del lanzamiento, incluso si la respuesta es "no lo medimos y esto es lo que seguiría la próxima vez". Esa última honestidad funciona mejor que una afirmación vaga de éxito.

Si haces un ejercicio de diseño en vivo, practica los primeros noventa segundos —las preguntas de clarificación— más que el dibujo. La mayoría de desempeños débiles no son malas ideas, son un candidato que empieza a bocetar antes de saber quién es el usuario o cuál es la restricción.

Y si el problema que realmente enfrentas es anterior a todo esto —solicitudes que no van a ninguna parte y ninguna entrevista para preparar— ese es un problema diferente con un mecanismo diferente, que vale la pena resolver antes de pulir respuestas de entrevista para una llamada que nunca llega. jobmarket.pro lee el anuncio completo, lo coteja con un perfil de tu experiencia real, y prepara la solicitud a partir de eso, sin inventar nada que no hayas hecho.