Preguntas de entrevista para Diseñador UI

Respuesta modelo

El más significativo fue el sistema de diseño de una plataforma fintech B2B. Cuando entré convivían 14 grises, 9 alturas de botón y 4 juegos de iconos distintos, y cada pantalla nueva costaba unos tres días porque todo se rehacía a mano. En lugar de proponer un rediseño completo, que nadie habría aprobado, empecé por una auditoría visual de las 60 pantallas más usadas y la convertí en un argumento de coste. A partir de ahí construí una base de 190 tokens en tres capas y 62 componentes en Figma, versionados y documentados en zeroheight, y los fui introduciendo por áreas para no bloquear la entrega de producto. En siete meses el sistema cubría el 84 % de las pantallas, maquetar una nueva bajó a unas seis horas y, como el color ya era semántico, el modo oscuro salió en seis semanas en vez del trimestre estimado. Lo que más valoro no es el número de componentes, sino que dejamos un proceso de contribución para que el sistema no dependiera de mí.

Respuesta modelo

Trabajo con una regla sencilla: UX responde de qué problema resolvemos y en qué orden ocurren las cosas; UI responde de cómo se ve, se entiende y se comporta cada elemento en pantalla, y de que eso sea consistente y construible a escala. En la práctica eso significa que yo entro cuando hay un flujo validado y me hago cargo de la jerarquía visual, la tipografía, el color, la retícula, la iconografía, los estados de cada componente, el comportamiento en móvil y escritorio, la accesibilidad visual y la entrega a desarrollo. No hago las entrevistas con usuarios ni monto los tests de usabilidad, pero sí participo en las sesiones y leo los informes, porque muchas conclusiones de investigación se resuelven con una decisión de contraste, de jerarquía o de densidad. Y cuando no hay perfil de UX en el equipo, cosa habitual en empresas medianas españolas, lo digo abiertamente y hago la parte que puedo asumir con honestidad, apoyándome en datos de producto en lugar de improvisar investigación.

Respuesta modelo

Primero traduzco la frase, porque «no me gusta» casi nunca significa lo que dice: suele significar que algo no destaca, que no parece de la marca o que se parece demasiado a un competidor. Así que pregunto qué esperaba ver y en qué pantalla concreta le chirría. Después llevo la conversación a criterios comprobables: si el problema es que la acción principal no destaca, lo enseño con una prueba de cinco segundos o con una captura desenfocada, que revela la jerarquía real mejor que cualquier discusión. Si la alternativa que propone no cumple 4,5:1 de contraste, lo enseño en pantalla con Stark y explico que desde 2025 la Ley 11/2023 nos obliga en comercio electrónico y banca, así que no es una preferencia sino un requisito. Y si al final es una decisión de marca legítima, la acepto y busco una solución dentro del sistema, por ejemplo reservar el azul corporativo para superficies y usar un tono derivado con contraste suficiente para acciones. Lo importante es no defender un color, sino la función que ese color cumple.

Respuesta modelo

En tres niveles. El primero es el de sistema, que es el que controlo directamente: cobertura de componentes sobre el total de pantallas, número de valores fijos sustituidos por tokens, incidencias de design QA por versión, tiempo medio para montar una pantalla nueva y semanas necesarias para lanzar un tema o una marca nueva. El segundo es el de calidad comprobable: porcentaje de combinaciones de color que cumplen AA, componentes con foco visible especificado, peso de tipografías e iconos, y estabilidad visual medida en CLS junto con frontend. El tercero es el de producto, que comparto con otros roles y por eso lo presento con honestidad: en el alta de empresa, un rediseño de la jerarquía del formulario junto al equipo de UX subió la finalización en móvil del 61 % al 70 % en un test A/B de cuatro semanas. Nunca me atribuyo entero un número de negocio, pero tampoco me escondo detrás de que el diseño no se mide: las dos primeras capas son enteramente mías y son las que justifican la inversión en diseño ante dirección.

Respuesta modelo

En mi primer año en producto presenté un panel de control que estéticamente era lo mejor que había hecho: mucho aire, tipografía grande, tarjetas espaciadas. Un desarrollador sénior me dijo en la crítica que era precioso y que ningún analista lo usaría, porque necesitaban comparar treinta filas sin desplazar. Me molestó, y precisamente por eso me senté media hora con dos usuarios internos a verles trabajar con la herramienta antigua. Tenían razón: la densidad no era un capricho, era el requisito. Rehice el diseño con una escala de espaciado más compacta, tres modos de densidad, tipografía tabular para las cifras y jerarquía por peso en vez de por tamaño. Aprendí algo que aplico desde entonces: en interfaces de trabajo, el aire es un lujo que se paga con desplazamiento, y la elegancia consiste en jerarquizar sin gastar espacio. Desde ese día llevo siempre las críticas a una pregunta concreta: para quién y en qué contexto se usa esta pantalla.

Respuesta modelo

Intento que no haya un momento de entrega, sino una conversación continua. Enseño los componentes en borrador antes de acabarlos para detectar pronto lo que es caro de construir, y en muchos casos ajusto la propuesta si una alternativa cuesta la mitad y pierde poco. Entrego en Figma con Dev Mode, con los tokens enlazados a variables para que no tengan que copiar valores a mano y con una ficha de estados obligatoria por componente: por defecto, hover, foco visible, activo, deshabilitado, carga, error y vacío, más el comportamiento con texto largo y en el punto de ruptura más estrecho. Lo que no especifico es la implementación: no digo cómo estructurar el componente en código, eso es su terreno. Y cierro el ciclo con design QA en preproducción, reportando incidencias como tickets con captura, prioridad y token afectado, no como una lista de píxeles en un mensaje de Slack. Con ese proceso pasamos de 34 a 7 incidencias visuales por versión.

Respuesta modelo

Sigo tres fuentes distintas a propósito. La primera es normativa y de plataforma: las notas de WCAG, los cambios de Material Design y de las Human Interface Guidelines y las novedades de Figma, porque marcan lo que tendré que hacer sí o sí. La segunda es de oficio: tipografía y color, con foundries y con gente que escribe sobre fundamentos más que sobre pantallas. La tercera son los sistemas de diseño públicos, que son la mejor documentación gratuita que existe; miro cómo resuelven la elevación, los estados y los tokens y comparo decisiones. Para decidir si adopto algo aplico un filtro simple: si una tendencia no sobrevive a una prueba de contraste, a un texto un 30 % más largo por la traducción y a una pantalla de 360 px, no entra en el sistema. Es lo que hago con los efectos de transparencia y desenfoque, que quedan muy bien en una presentación y provocan problemas de legibilidad y de rendimiento en cuanto hay contenido real detrás.

En tres capas. La primera son los tokens primitivos, que solo describen valores sin significado: la rampa de color completa, la escala de espaciado, los radios, las sombras y los tamaños de texto. La segunda son los semánticos, que asignan función: superficie, superficie elevada, texto primario, texto secundario, borde, acción principal, estado de error o de éxito. La tercera son los de componente, que solo creo cuando un componente necesita una excepción justificada, por ejemplo el fondo de un botón terciario. Las marcas y los temas se resuelven en la capa semántica con modos de Figma: el mismo token de superficie apunta a un primitivo distinto según el modo, y ninguna pantalla se toca. Es importante que el modo oscuro no sea una inversión: la jerarquía se construye con superficies de distinta luminancia en lugar de con sombras, y hay que bajar la saturación de los colores muy vivos porque sobre fondo oscuro vibran. Exporto con Style Dictionary a variables CSS, a Swift y a XML de Android desde una única fuente de verdad, para que no haya tres definiciones del mismo azul viviendo por separado.

Separando el color de marca del color funcional. Los mínimos son 4,5:1 para texto normal, 3:1 para texto grande a partir de 24 px o 18,66 px en negrita, y 3:1 para componentes de interfaz y elementos gráficos necesarios para entender la pantalla, incluido el indicador de foco. Muchas identidades españolas tienen un corporativo que simplemente no llega en texto pequeño sobre blanco, y el error es forzarlo. Lo que hago es construir la rampa en OKLCH, donde los saltos de luminancia son perceptualmente uniformes, y definir para cada color de marca un tono de acción con contraste suficiente y otro de superficie para grandes áreas. Así la marca sigue presente en el fondo, en los grandes bloques y en la ilustración, y el texto y los controles usan las variantes accesibles. Además nunca codifico información solo por color: un estado de error lleva color, icono y texto. Reviso con Stark dentro de Figma mientras diseño, no al final, y dejo los pares aprobados documentados en el sistema para que nadie tenga que volver a decidirlo.

Parto de la base del cuerpo de texto, normalmente 16 px, porque es el tamaño por defecto del navegador y bajar de ahí penaliza a mucha gente. Sobre esa base construyo una escala modular con una razón moderada, entre 1,2 y 1,25 para interfaces densas, y la redondeo a valores enteros o a múltiplos de 2 para que encaje con el sistema de espaciado. Cada nivel lleva su propio interlineado (más ajustado a medida que crece el tamaño, alrededor de 1,5 en texto corrido y 1,1 a 1,2 en titulares) y su propio ajuste de tracking, que suele ser ligeramente negativo en los tamaños grandes. Controlo el ancho de línea entre 45 y 75 caracteres, porque es lo que más afecta a la legibilidad y casi nadie lo especifica. En móvil no reduzco el cuerpo de texto, reduzco los saltos de la escala para que los titulares no ocupen media pantalla. Prefiero una fuente variable subconjuntada a tres pesos estáticos, porque pesa menos y da más control, y siempre defino una tipografía de respaldo con métricas ajustadas para que no haya salto de maquetación mientras carga la fuente.

La regla que uso es que una variante representa el mismo elemento en otro estado o con otra jerarquía —un botón primario, secundario y terciario, o con icono a la izquierda—, mientras que un componente distinto aparece cuando cambia la función o la estructura, como un botón y un enlace, aunque visualmente se parezcan. Si una matriz de variantes empieza a multiplicarse sin control, suele ser la señal de que hay que sacar propiedades booleanas o slots en lugar de crear combinaciones. Para que la librería no se pudra hacen falta tres cosas. Nomenclatura estable y compartida con desarrollo, porque el nombre del componente en Figma y en el código debe ser el mismo. Gobernanza explícita: quién revisa, cómo se propone un componente nuevo, versionado semántico y una política de deprecación con aviso antes de eliminar nada. Y medición: un informe mensual de cobertura y de detached instances, que es el indicador más honesto de la salud del sistema. Si un equipo desengancha un componente cada semana, el problema no es del equipo, es que ese componente no cubre un caso real.

Comparto la capa de significado y adapto la de comportamiento. Los tokens semánticos, la jerarquía, la iconografía y el lenguaje visual son los mismos en las tres plataformas. Lo que cambio son los patrones que el usuario ya tiene aprendidos del sistema operativo: navegación inferior y hoja modal en iOS frente a los patrones de Material Design 3 en Android, gesto de retroceso, posición de las acciones destructivas en los diálogos y controles nativos de fecha o selección, que casi nunca merece la pena reconstruir. También respeto los mínimos de cada guía: 44 puntos de objetivo táctil en iOS, 48 dp en Android y 24 px como mínimo de WCAG 2.2 en web. Con la tipografía tengo cuidado especial, porque el tamaño dinámico de iOS y la escala de fuente de Android pueden agrandar el texto mucho más de lo que uno dibuja, así que diseño con Auto Layout pensando en que todo crezca. Mi criterio para divergir es simple: me separo de la guía de la plataforma solo cuando la marca aporta algo que el usuario no puede obtener de otro modo, y nunca en la navegación.

Para un componente interactivo, como mínimo: por defecto, hover, foco visible, activo, deshabilitado, cargando, error y seleccionado cuando aplique. Para un contenedor o una vista: estado vacío, primer uso, carga con esqueleto, contenido parcial, error de red y contenido excesivo. Además compruebo cuatro condiciones que casi nadie dibuja: texto un 30 % más largo por traducción al catalán o al inglés, cadenas sin espacios que rompan el contenedor, el punto de ruptura más estrecho a 360 px y el comportamiento con el texto ampliado al 200 %. El estado de foco lo trato aparte porque es el que más se olvida y el que exige WCAG 2.2 con contraste 3:1 respecto a lo que le rodea; especifico grosor, separación y color del indicador en el sistema, no en cada pantalla. Y siempre indico el orden de lectura previsto, porque el orden de las capas en Figma no determina el orden del DOM y esa conversación con desarrollo evita la mitad de las incidencias de accesibilidad.

Tomo decisiones de diseño sabiendo lo que cuestan. En imágenes, defino formatos y tamaños por punto de ruptura y trabajo con AVIF o WebP en vez de PNG de cuatro megas, y reservo siempre el espacio con una relación de aspecto para no provocar saltos de maquetación. En tipografía uso una fuente variable subconjuntada al alfabeto que necesito y una de respaldo con métricas ajustadas, porque las fuentes son la causa más habitual de CLS. Con el movimiento animo transformaciones y opacidad, no propiedades que obliguen a recalcular la maquetación, y sustituyo animaciones Lottie pesadas por transiciones simples siempre que puedo. Vigilo especialmente los desenfoques y las sombras muy grandes, que son caros en móviles de gama media, que es la mitad del parque en España. Y en listas largas asumo que habrá virtualización, así que diseño filas de altura predecible. En la práctica esto significa hablar con frontend antes de dibujar, no después: casi todos los problemas de rendimiento visual se deciden en el archivo de diseño.

Nunca con un lanzamiento único, salvo que la marca cambie y haya una fecha de comunicación. Empiezo con una auditoría visual que inventaría lo que existe —cuántos grises, cuántos botones, cuántos tamaños de texto, cuántos iconos— porque ese inventario convierte el problema estético en un argumento de coste que dirección entiende. Después establezco la base invisible: tokens, escala tipográfica, espaciado e iconografía, que se pueden introducir sin que el usuario note casi nada. Solo entonces voy área por área, empezando por la de más tráfico o la más dolorosa para el negocio, con una convivencia controlada de estilos durante unos meses y una regla clara de qué zona ya está migrada. Acompaño cada tanda con design QA en preproducción y con pruebas visuales automatizadas en Storybook y Chromatic para detectar regresiones. Y mido: cobertura de componentes, deuda visual pendiente e incidencias por versión. Un rediseño anunciado como un gran cambio genera resistencia interna; uno presentado como una reducción de coste por pantalla se aprueba.

Lo primero es preguntar qué parte concreta es cara, porque casi nunca lo es el diseño entero: suele haber uno o dos elementos que disparan el coste, como una animación compleja, una tabla con ordenación y filtrado a medida o un componente que no existe en la librería. Con eso claro, propongo una versión por fases: qué entra en esta entrega para que la funcionalidad sea usable y digna, y qué se incorpora en la siguiente. Si hay que sacrificar algo, sacrifico lo decorativo antes que lo funcional o lo accesible, y esa jerarquía la digo en voz alta para que la decisión quede documentada. También compruebo si puedo resolverlo con componentes que ya existen, aunque el resultado sea menos brillante, porque un diseño construido a tiempo vale más que uno perfecto que se implementa a medias. Lo que no hago es aceptar en silencio y quejarme luego del resultado en la crítica de diseño.

Lo enseño en pantalla en lugar de discutirlo. Abro Stark, mido, y explico que 4,5:1 en texto no es una opinión mía sino el nivel AA de WCAG 2.2, exigible en nuestro sector desde que la Ley 11/2023 es aplicable, con riesgo de reclamación y de exclusión en licitaciones. Después propongo tres salidas concretas en lugar de un no: un tono de acción derivado del corporativo con la luminancia ajustada, que mantiene la familia cromática; el corporativo puro reservado a superficies y grandes áreas donde no hay texto encima; o el botón corporativo con el texto en un color que sí cumpla. En mi experiencia, cuando marketing ve las tres opciones a tamaño real elige la primera en cinco minutos. Y dejo el par aprobado documentado en el sistema, para que la discusión no vuelva a repetirse dentro de tres meses con otra persona.

El primer mes, inventario y confianza. Audito las pantallas más usadas, cuento cada inconsistencia y la traduzco a coste: cuánto se tarda hoy en montar una pantalla nueva y cuántas incidencias visuales llegan por versión. En paralelo hablo con desarrollo para saber qué componentes ya existen en código, porque el sistema tiene que partir de lo construido, no de lo ideal. El segundo mes, la base invisible: rampa de color y tokens semánticos, escala tipográfica, espaciado, radios y un juego único de iconos. Elijo las decisiones que menos rompen lo existente, aunque no sean las que yo dibujaría en un lienzo en blanco. El tercer mes, los diez componentes que aparecen en el 80 % de las pantallas —botón, campo de texto, selector, tabla, modal, navegación, aviso, tarjeta, pestañas y paginación— documentados y con todos sus estados, y los aplico primero en un área concreta que sirva de escaparate. Al cerrar el trimestre presento el antes y el después con las cifras de la auditoría inicial, que es lo que consigue presupuesto para seguir.

Acepto la restricción y reduzco el riesgo con lo que tenga a mano. Reviso los datos de producto que ya existen —analítica, tickets de soporte, grabaciones de sesión si las hay— porque suelen contener el 70 % de lo que una investigación formal confirmaría. Miro cómo lo resuelven productos de referencia del mismo sector, no para copiar sino para no inventar un patrón que la gente no conoce. Diseño la versión más convencional posible, apoyada en componentes existentes, y dejo por escrito las dos o tres suposiciones que estoy haciendo y qué mediríamos después para comprobarlas. Si puedo robar dos horas, hago una prueba de pasillo con cinco compañeros que no sean del equipo, que es barata y detecta los errores más gruesos. Y dejo la decisión reversible: si algo hay que cambiar tras el lanzamiento, que sea un cambio de token o de componente y no un rediseño. La clave es no bloquear la entrega ni fingir que la falta de investigación no existe.

Primero separo el fondo de la forma. Reviso si sus objeciones tienen un patrón: si siempre señala la densidad, la accesibilidad o la coherencia con el sistema, entonces hay un hueco real en mi trabajo y lo agradezco aunque el tono no me guste. Cuando detecto el patrón, cambio la forma de presentar: llego a la crítica con el criterio explícito y las alternativas que ya descarté, porque muchas objeciones nacen de que la gente ve la pantalla final sin ver el camino. Si aun así el rechazo es sistemático y sin argumento, lo hablo con esa persona en privado, sin público, preguntando directamente qué esperaría ver; casi siempre hay una expectativa no dicha. Y si no se resuelve, lo llevo a mi responsable como un problema de proceso y no como un conflicto personal: propongo que las críticas tengan un objetivo declarado al principio y que las objeciones se formulen contra un criterio compartido. Lo que no hago es dejar de presentar trabajo para evitar el mal rato, porque eso perjudica al producto y a mi propio crecimiento.