Preguntas de entrevista UI UX Designer

Describe tu proceso de diseño desde el brief hasta el mockup final.

Empieza entendiendo el problema y los criterios de éxito, no la solución pedida — un brief que pide un dashboard a menudo esconde una pregunta sobre un solo número. Luego investiga el comportamiento y restricciones existentes, esboza varias direcciones ampliamente antes de refinar una, prototipa a la fidelidad que la pregunta requiere, testea con usuarios, e itera. El handoff y la medición post-lanzamiento son parte del proceso, no algo pensado después.

¿Cuál es la diferencia entre UX y UI? Da un ejemplo de mal UX con buen UI.

UX es toda la experiencia de lograr un objetivo — estructura, flujo, y si la cosa resuelve el problema. UI es la capa visual e interactiva a través de la cual eso pasa. Una pantalla de suscripción bellamente diseñada donde cancelar requiere un email a soporte es excelente UI y UX hostil; al revés un formulario plano y feo que te lleva a través en diez segundos es buen UX con UI pobre.

¿Cómo corres usability testing? ¿Cuántos participantes necesitas?

Dale a los participantes tareas realistas en vez de preguntar su opinión, observa en silencio, y resiste explicar la interfaz — en el momento en que ayudas, se pierden los datos. Cinco participantes por grupo de usuario típicamente revelan la mayoría de los problemas severos, y testear más usualmente devuelve los mismos hallazgos; es mejor correr varias rondas pequeñas entre iteraciones que un estudio grande al final.

¿Qué es un design system y por qué se necesita?

Un design system es una biblioteca compartida de componentes, tokens, y reglas de uso que mantiene un producto consistente mientras más gente trabaja en él. Ahorra el costo recurrente de rediseñar un botón y deja a los designers pasar tiempo en problemas reales. Solo sobrevive si tiene un dueño y un proceso de contribución — un sistema no mantenido se convierte en un museo que todos rodean.

¿Cómo defiendes tu solución cuando un stakeholder no está de acuerdo?

Separa la preferencia de la evidencia: pregunta qué resultado les preocupa, luego responde con investigación, datos de uso, o un principio heurístico en vez de gusto. Si el desacuerdo persiste y los datos son escasos, propón un test en vez de ganar la discusión. Poder decir qué te haría cambiar de opinión te hace mucho más persuasivo que defender el trabajo.

¿Qué es a11y? Nombra los requisitos básicos.

Accesibilidad significa que gente con discapacidades pueda usar el producto. La base es contraste 4.5:1 para texto de cuerpo, nunca transmitir significado solo con color, operabilidad completa con teclado con un estado de foco visible, estructura semántica correcta y labels para lectores de pantalla, y texto que se reajusta al hacer zoom a 200 por ciento. Esto también mejora la usabilidad para todos, que es el argumento que usualmente gana presupuesto.

¿Cómo haces el handoff de diseños a desarrolladores?

Un handoff incluye estados, no solo pantallas: vacío, cargando, error, y casos límite como un nombre muy largo o cero resultados. Cubre comportamiento responsivo, especificidades de interacción y movimiento, y qué componentes del design system se usan. El mejor predictor de un handoff suave es que los desarrolladores vieron el trabajo en progreso — un handoff que es la primera conversación ya llega tarde.

¿Cómo trabajas dentro de restricciones cuando la solución ideal no es factible?

Establece qué es realmente la restricción — usualmente esfuerzo, limitación técnica, o timing — y encuentra qué parte del valor sobrevive a menor costo. Lanza la versión reducida deliberadamente, documenta qué se cortó y por qué, y acuerda qué dispararía revisitarlo. Los designers que tratan las restricciones como parte del problema en vez de un obstáculo logran que se construya mucho más de su trabajo.