Talently
Talently
Diseñador UI

Diseñador UI

Traduce la intención de la experiencia en interfaces visuales coherentes, accesibles y estéticamente sólidas.

Un UI Designer es responsable de diseñar la capa visual e interactiva de los productos digitales: la tipografía, el color, el espaciado, los componentes, las animaciones y el sistema visual que los usuarios perciben y con el que interactúan. Su trabajo transforma los wireframes y flujos del UX Designer en interfaces pixel-perfect que comunican la identidad de la marca, respetan los principios de usabilidad y son implementables por el equipo de desarrollo. Colabora estrechamente con UX Designers, desarrolladores frontend y equipos de branding para garantizar coherencia visual a través de todo el producto.

FigmaDesign SystemsTipografíaAccesibilidadPrototipadoMotion Design

Recluta al mejor Diseñador UI aquí

Empieza ahora

Responsabilidades Principales

  • •Diseñar los componentes visuales del producto manteniendo coherencia con el sistema de diseño y los principios de marca.
  • •Crear y mantener una biblioteca de componentes en Figma con variantes, estados y especificaciones de implementación.
  • •Garantizar que los diseños cumplen los estándares de accesibilidad WCAG en contraste de color, tamaño de tipografía y estados de foco.
  • •Colaborar con desarrolladores frontend para garantizar que la implementación preserva la intención visual del diseño.
  • •Diseñar microinteracciones y animaciones que refuerzan el feedback del sistema y mejoran la percepción de calidad.
  • •Participar en la evolución del design system documentando patrones, decisiones de diseño y guías de uso de componentes.

Habilidades Clave

Technical Skills

  • Dominio avanzado de Figma: componentes con variantes, auto layout, estilos, prototipos interactivos y design tokens
  • Principios de tipografía aplicada: jerarquía visual, escala tipográfica, legibilidad y pairing de fuentes
  • Teoría del color aplicada al diseño de interfaces: paletas, contraste WCAG, modos claro y oscuro, y semántica del color
  • Diseño de sistemas visuales: tokens de diseño, componentes atómicos y documentación de patrones para equipos de desarrollo
  • Principios de motion design y microinteracciones con herramientas como Figma Prototyping o After Effects
  • Conocimiento básico de CSS y HTML para comunicarse con precisión con el equipo de frontend sobre las especificaciones de implementación

Soft Skills

  • Criterio visual sólido para tomar decisiones de diseño fundadas en principios, no solo en preferencias personales
  • Capacidad de recibir y dar feedback de diseño de forma constructiva separando el trabajo del ego
  • Colaboración fluida con UX Designers para traducir flujos y wireframes en diseños visuales sin perder la intención funcional
  • Comunicación precisa con desarrolladores sobre especificaciones de implementación: espaciados, estados, comportamientos responsivos
  • Consistencia y disciplina para mantener el design system actualizado a medida que el producto evoluciona
  • Apertura a la restricción técnica: entender las limitaciones de implementación del frontend como input de diseño, no como obstáculos

Casos de uso reales

Contexto

Un sistema de diseño bien construido multiplica la velocidad del equipo y garantiza coherencia visual en todo el producto. Es la base sobre la que todos los diseñadores e ingenieros del equipo construyen.

Ejemplos reales

  • Definición de design tokens para colores, tipografía, espaciado y elevación como fuente de verdad del sistema
  • Construcción de una biblioteca de componentes atómicos con variantes y estados documentados en Figma
  • Diseño del modo oscuro con tokens semánticos que adaptan automáticamente los colores sin rediseñar cada componente
  • Documentación de guías de uso para cada componente: cuándo usarlo, cuándo no, y qué alternativas existen

Contexto

Cada nueva feature o producto necesita un tratamiento visual que respete el sistema existente y al mismo tiempo resuelva los nuevos requerimientos de presentación de información.

Ejemplos reales

  • Diseño de dashboards con jerarquía visual clara que guía la atención hacia las métricas más relevantes
  • Interfaces de configuración con alta densidad de información organizadas de forma escaneable
  • Flujos de onboarding con progresión visual que reduce la percepción de complejidad
  • Páginas de error y estados vacíos con comunicación clara y calls to action contextuales

Contexto

Los productos digitales modernos deben funcionar correctamente en desktop, tablet y móvil con adaptaciones visuales que respeten las convenciones de cada plataforma.

Ejemplos reales

  • Diseño de layouts responsivos con breakpoints definidos y comportamiento de cada componente por tamaño
  • Adaptación de la navegación principal para mobile con patrones nativos de cada plataforma
  • Diseño de versiones condensadas de componentes complejos para pantallas pequeñas
  • Especificaciones de implementación responsive para el equipo de desarrollo con comportamiento documentado

Contexto

Las microinteracciones son los detalles que distinguen un producto de calidad percibida alta de uno que se siente genérico. El feedback visual del sistema comunica al usuario que sus acciones tuvieron efecto.

Ejemplos reales

  • Estados de hover, focus y active para todos los elementos interactivos del sistema
  • Animaciones de transición entre estados que refuerzan la jerarquía y el flujo de la interfaz
  • Indicadores de carga y esqueletos de contenido que reducen la percepción de latencia
  • Feedback de acciones críticas: confirmaciones, errores y estados de éxito con animaciones contextuales

Contexto

El diseño no termina en Figma. La colaboración con el equipo de desarrollo garantiza que la implementación preserva la intención visual y que las especificaciones son lo suficientemente claras para no requerir múltiples ciclos de revisión.

Ejemplos reales

  • Especificaciones de componentes con todos los estados, variantes y comportamientos documentados
  • Handoff en Figma con tokens de diseño conectados al código para reducir la divergencia entre diseño e implementación
  • Revisiones de implementación con una checklist de criterios visuales antes del merge
  • Sesiones de trabajo conjunto con frontend para resolver dudas de implementación en tiempo real

Preguntas básicas

Usar tamaño, peso tipográfico, color y espaciado para crear niveles claros de importancia. El elemento más importante debe destacar visualmente por contraste o tamaño. Agrupar información relacionada con proximidad y separar grupos con espaciado generoso. Limitar los niveles de jerarquía a tres o cuatro para no saturar al usuario. Reducir la cantidad de elementos que compiten por la atención simultáneamente: si todo es importante, nada lo es.
Usar el plugin de Figma Contrast o herramientas como Colour Contrast Checker para verificar que el texto sobre fondo cumple el ratio mínimo de 4.5:1 para texto normal y 3:1 para texto grande (18px o mayor). Los elementos de UI interactivos también deben cumplir 3:1 contra su entorno. Verificar también el modo oscuro si el producto lo soporta. Incluir la verificación de contraste como un paso obligatorio antes del handoff, no como una revisión posterior.
Diseñar mínimo cinco estados: default (estado base), hover (feedback al acercarse con el cursor), focus (indicador de foco para navegación por teclado, borde visible y de alto contraste), active/pressed (feedback al hacer click, generalmente más oscuro o con desplazamiento sutil), y disabled (comunicar que no es interactivo, reducción de opacidad o color diferente, cursor no-allowed). Cada estado debe ser distinguible del anterior sin ser tan diferente que parezcan componentes distintos.
Legibilidad en pantalla: preferir fuentes diseñadas para pantalla sobre las diseñadas para impresión. Tamaño mínimo de 16px para cuerpo de texto para legibilidad confortable. Definir una escala tipográfica con ratios claros (Major Third, Perfect Fourth) para consistencia en la jerarquía. Verificar la disponibilidad de los pesos necesarios (regular, medium, semibold) para construir la jerarquía sin depender de un solo peso. Considerar el rendimiento de carga: fuentes web con muchos pesos incrementan el tiempo de carga.
Construir el componente con auto layout para que se adapte automáticamente al contenido. Definir variantes para los estados distintos (default, hover, disabled) y las variaciones de contenido (con icono, sin icono, con badge). Usar estilos y tokens de diseño en lugar de valores hardcodeados para que los cambios globales se propaguen automáticamente. Nombrar las capas de forma descriptiva y consistente con la nomenclatura del sistema. Documentar en la descripción del componente cuándo usarlo y cuándo no.
No invertir simplemente los colores: el modo oscuro requiere un rediseño de la paleta. Definir tokens semánticos (color-background-primary, color-text-secondary) en lugar de tokens literales (gray-100). Cada token tiene un valor distinto en modo claro y oscuro. Los colores de marca y énfasis también deben ajustarse: los colores vibrantes que funcionan sobre fondos claros pueden ser agresivos sobre fondos oscuros. Las sombras y elevaciones se reemplazan por sutiles variaciones de luminosidad del fondo. Verificar el contraste de todos los componentes en ambos modos.
Establecer el design system como única fuente de verdad: todos los diseñadores usan los mismos componentes, tokens y estilos de la biblioteca central. Definir un proceso claro para proponer cambios al sistema: ningún diseñador modifica los componentes centrales directamente sin revisión. Realizar revisiones de diseño periódicas entre el equipo para detectar inconsistencias antes del handoff. Asignar un owner del design system responsable de aprobar cambios y mantener la documentación actualizada.
Todos los estados del componente (default, hover, focus, disabled, error) documentados en el mismo frame. Espaciados y dimensiones con las medidas exactas o referenciadas al sistema de espaciado. Comportamiento responsive documentado con los breakpoints y el comportamiento esperado en cada uno. Especificaciones de animación si las hay: duración, easing, propiedades animadas. Assets exportados en los formatos y resoluciones correctos. Un listado de las interacciones que no son evidentes en el diseño estático. El objetivo es que el desarrollador no necesite preguntar para implementar correctamente.

Preguntas técnicas

Tres niveles de tokens: primitivos (los valores base: blue-500, gray-100, 16px), semánticos (el significado: color-action-primary, color-text-secondary, space-md que referencian los primitivos), y de componente (específicos de un componente: button-background-primary). Los temas y modos solo cambian la capa semántica: el mismo token color-action-primary apunta a blue-500 en modo claro y a blue-300 en modo oscuro. Los componentes siempre usan tokens semánticos, nunca primitivos directamente. Este modelo permite cambiar un tema completo modificando solo la capa semántica sin tocar ningún componente.
Definir variantes de celda por tipo de contenido: texto, número (alineado a la derecha), estado con badge, fecha, acciones. La alineación comunica el tipo: números a la derecha para facilitar la comparación visual, texto a la izquierda. Los encabezados con ordenación tienen indicadores de dirección de sort activo e inactivo. Las filas con hover tienen highlight sutil para indicar interactividad. Las acciones de fila se revelan en hover o están siempre visibles según la frecuencia de uso. Diseñar también el estado de tabla vacía y el de carga con skeleton rows.
Proximidad: agrupar los campos relacionados semánticamente con menor distancia entre sí y mayor separación entre grupos. Similitud: usar el mismo estilo visual para todos los campos del mismo tipo (inputs, selects, checkboxes). Continuidad: alinear todos los labels y campos en una cuadrícula consistente que crea líneas visuales implícitas. Cierre: usar secciones con bordes sutiles o fondos diferenciados para que el usuario perciba cada grupo como una unidad completa. El resultado es un formulario donde el usuario puede escanear la estructura sin leer cada campo individualmente.
Distinguir por urgencia: las notificaciones informativas aparecen como toasts en la esquina sin requerir acción, desaparecen automáticamente en 4-5 segundos y no se posicionan sobre contenido interactivo. Las notificaciones que requieren acción son modales o banners persistentes que no desaparecen solos. El área de aparición debe ser consistente para que el usuario la anticipe. El sonido solo para notificaciones críticas y con control de usuario para desactivarlo. Diseñar el estado de múltiples notificaciones simultáneas para evitar un stack interminable.
Usar auto layout en Figma que se corresponde directamente con flexbox en CSS, facilitando la traducción. Diseñar con la cuadrícula y los tokens del sistema para que los valores sean los mismos que el código ya tiene definidos. Evitar efectos visuales que tienen alto costo de implementación y bajo impacto perceptual (sombras complejas superpuestas, gradientes radiales con múltiples stops). Cuando se propone algo visualmente ambicioso, consultar con el desarrollador antes de finalizar el diseño para validar la viabilidad. El mejor diseño es el que se implementa fielmente, no el más elaborado.
Definir una cuadrícula base (24x24px es el estándar más común) y un área de padding interno consistente para que todos los iconos tengan el mismo peso visual. Establecer un estilo unificado: outlined, filled, o duotone, con grosor de trazo consistente. Nombrar los iconos según su significado semántico, no su forma visual (check-circle, no circle-with-tick). Organizar en categorías semánticas en Figma. Verificar legibilidad en tamaños pequeños (16px) y en modo oscuro. Documentar los iconos que tienen uso semántico específico (warning solo para errores, no decorativamente) para mantener la consistencia en el uso.
La animación debe comunicar la relación espacial entre las pantallas: navegación hacia adelante usa transición de izquierda a derecha, retroceso de derecha a izquierda. Las modales y paneles secundarios emergen desde su origen (un botón, un elemento de lista) para reforzar la relación contextual. Duración entre 200-400ms para transiciones de navegación; más rápido se siente brusco, más lento parece lento. Usar easing con aceleración al inicio y desaceleración al final (ease-out para entradas, ease-in para salidas). Siempre diseñar con reduced-motion en mente: la animación es una mejora progresiva, no un requisito funcional.
Checklist de revisión propia: verificar contraste de todos los textos, revisar que todos los estados de los componentes interactivos están diseñados, verificar el comportamiento en los breakpoints definidos, revisar la consistencia con el design system (ningún valor hardcodeado fuera del sistema), verificar que los assets están correctamente exportados. Hacer zoom out al 50% para evaluar la jerarquía visual global: los elementos más importantes deben destacar también a distancia. Pedir feedback de un colega antes del handoff: el diseñador se vuelve ciego a sus propios errores después de horas de trabajo en el mismo archivo.

Preguntas avanzadas

Modelo federado: un equipo core de design system (1-2 personas) mantiene los componentes fundamentales y los tokens. Cada equipo de producto puede proponer extensiones y componentes específicos de su dominio a través de un proceso de RFC. Los componentes que se repiten en más de dos productos se promueven al sistema central. El core team hace releases versionados con changelogs claros. Cada equipo de producto tiene representación en las decisiones del sistema para que sientan ownership. La gobernanza debe balancear la consistencia global con la autonomía local: demasiado control central genera fricción, demasiada autonomía genera fragmentación.
Métricas de velocidad: tiempo desde wireframe hasta handoff para features similares antes y después de la mejora del sistema. Número de idas y vueltas entre diseño e implementación por feature. Métricas de calidad: número de inconsistencias visuales detectadas en revisiones de implementación. Percepción de los equipos con encuestas NPS interno: ¿cuánto confían los diseñadores y desarrolladores en el sistema? El dato más valioso es el cualitativo: qué bloqueadores específicos resolvió la mejora. Sin métricas pre-mejora como baseline, es imposible demostrar el impacto con datos.
No cambiar todo a la vez: identificar los componentes con mayor deuda visual y mayor visibilidad para el usuario. Introducir los cambios de forma incremental con feature flags si la infraestructura lo permite. Comunicar los cambios con anticipación, especialmente en los flujos más usados. Mantener la funcionalidad idéntica durante la transición visual: cambiar apariencia y comportamiento simultáneamente multiplica la fricción. Medir la satisfacción del usuario con los cambios introducidos antes de extenderlos al resto del producto. La familiaridad tiene valor; cambiar sin necesidad genera resistencia sin beneficio.
Mapear los componentes del framework con los del design system para identificar dónde hay correspondencia directa (se usa el componente del framework con theming), dónde hay gap (se necesita un componente custom), y dónde el framework tiene algo que el design system no contempla. La estrategia más eficiente es theming profundo del framework con los tokens del design system para los componentes comunes, y componentes custom solo donde el framework no puede satisfacer el requerimiento sin modificaciones costosas. Documentar explícitamente qué viene del framework y qué es custom para que los desarrolladores sepan dónde buscar cada componente.
Revelación progresiva como principio central: la interfaz muestra las acciones más comunes y frecuentes de forma prominente, y revela densidad y funcionalidad adicional de forma gradual. Para usuarios expertos: atajos de teclado, acciones en bulk, configuración avanzada accesible sin estar en el flujo principal. Para usuarios nuevos: onboarding contextual, tooltips que se pueden descartar, y defaults inteligentes que minimizan las decisiones iniciales. Validar con ambos perfiles por separado: las soluciones que sirven para ambos en la misma interfaz existen pero requieren iteración real con usuarios de ambos extremos, no solo con uno.
El principio fundamental es no depender del color como único canal de información: usar siempre color más forma, color más texto, o color más patrón. Diseñar con paletas evaluadas para los tipos de daltonismo más frecuentes (deuteranopia, protanopia) con herramientas como Figma's vision simulator. Los estados de error, advertencia y éxito usan iconos y texto además del color. Los gráficos usan patrones o etiquetas directas además del color para la leyenda. Un diseño que funciona sin colores generalmente es más claro y accesible para todos los usuarios, con o sin deficiencias visuales.

Errores comunes en entrevistas

Las pantallas bonitas sin contexto no demuestran criterio de diseño. Los entrevistadores de UI evalúan por qué se eligió esa tipografía, por qué ese espaciado, por qué esa paleta. Un portfolio que no puede responder esas preguntas demuestra ejecución sin razonamiento, que es lo opuesto a lo que un equipo maduro busca.
Un diseño que solo muestra el estado default de los botones, inputs y cards no es un diseño completo. Los estados hover, focus, disabled, error y loading son parte del diseño, no responsabilidad del desarrollador inventarlos. Los entrevistadores técnicos de UI siempre preguntan qué pasa cuando el usuario hace hover o cuando hay un error.
El UI Design es una disciplina con principios. Elegir una tipografía porque 'se ve bonita' o un color porque 'es moderno' sin poder articular el ratio de contraste, la escala tipográfica ni la semántica del color demuestra que las decisiones son intuitivas y no reproducibles ni mantenibles por un equipo.
El contraste WCAG, los estados de foco visibles y el no depender solo del color para comunicar información son requisitos mínimos de cualquier UI Designer profesional. Presentar diseños con texto en gris claro sobre blanco o sin estado de foco visible demuestra desconocimiento de los estándares básicos de la profesión.
Un UI Designer que no conoce los conceptos básicos de CSS (flexbox, grid, border-radius, transitions) produce diseños que el equipo de desarrollo implementa con compromisos que degradan la calidad visual. El conocimiento técnico básico no es opcional; es lo que distingue a un UI Designer que puede colaborar efectivamente con desarrollo de uno que genera fricción constante.
Aunque los roles colaboran estrechamente, el UI Designer no es responsable de la investigación de usuarios ni de la arquitectura de información. Un candidato que no puede articular claramente cuál es su responsabilidad específica y cómo trabaja en conjunto con el UX Designer genera dudas sobre su comprensión del proceso de diseño y su capacidad de colaborar efectivamente en un equipo con roles diferenciados.