← Proyectos ATS UI Kit

ATS UI Kit

Un sistema de seguimiento de candidatos cálido y accesible: tablero de pipeline, perfiles de candidatos y una librería completa de componentes.

Rol
Design system, diseño de UI, dirección de arte
Herramientas
Figma, Stark
Año
2026
Resultado
22 componentes, 2 pantallas, 171 variables
Portada
Portada del kit: el tablero de pipeline en modo claro y el perfil de candidato en modo oscuro.

Por qué un ATS

Quería construir un design system completo y no solo un conjunto de pantallas, y necesitaba un dominio lo bastante complejo como para ponerlo a prueba.

El seguimiento de candidatos funciona bien para eso. Un tablero de pipeline necesita cinco estados simultáneos codificados por color que se distingan entre sí. Un perfil de candidato tiene que contener varios tipos de contenido sin convertirse en una pared de información. Y los dos tienen que funcionar en modo claro y oscuro sin dejar de ser accesibles.

Una aclaración sobre qué es esto. No es un caso de estudio de UX. No entrevisté reclutadores ni lo testeé con usuarios. Las decisiones de producto salen de analizar herramientas ATS existentes y de lo que el sistema necesitaba demostrar. Lo que sigue es sobre el sistema en sí: cómo están estructurados los tokens, dónde me equivoqué con el color y cómo están construidos los componentes.

Dos capas de color

El color vive en dos capas.

Primitivos: son las rampas en bruto. Ocho paletas, cada una desde un casi blanco hasta un casi negro, sin ningún significado asociado: “color/terracotta/700” es solo un color.

Semánticos: se apoyan sobre los primitivos y llevan la intención: “surface/brand”, “text/primary”, “border/subtle”, “stage/screening/accent”. Los componentes solo referencian semánticos, nunca apuntan directamente a un primitivo.

La ventaja es que un rebranding deja de ser una búsqueda. Cambiás los valores de una rampa y cada componente que apunta a ella se actualiza, en ambos modos, de una sola vez. También significa que una misma definición de componente funciona en claro y en oscuro, porque el semántico se resuelve distinto en cada modo.

114 primitivos, 57 semánticos.

Rampa de primitivos terracota y una tabla de semánticos con sus valores en modo claro y oscuro.

Dónde se rompió el mapeo de color

El tablero codifica por color cinco etapas: Applied, Screening, Interview, Offer y Rejected.

El primer mapeo usaba taupe para Applied y neutro para Rejected. En el extremo claro de esas rampas se parecían tanto que se leían como un mismo estado, y mi neutro era tan cálido que en realidad no funcionaba como neutro.

Así que enfrié toda la rampa de neutros. No es un ajuste local: el neutro sostiene la mayoría de las superficies, textos y bordes del kit, así que todos se movieron con él. Ayudó, pero no alcanzó. Uno al lado del otro en un tablero, un gris cálido y un gris frío con la misma luminosidad se siguen leyendo como un solo estado, no como dos.

Entonces reasigné: taupe, ocre, terracota, oliva y rojo. Cinco tonos que se separan por sí solos, sin depender de cuánto empuje cada uno.

El modo claro quedó consistente en los cinco: mismos pasos, solo cambia el tono. El modo oscuro no pudo mantener eso. El número dentro del badge de Rejected no pasaba el contraste AA en los pasos compartidos, así que se movió.

Podía mantener la tabla simétrica o mantener el contraste. Me quedé con el contraste.

Comparación en tres pasos del mapeo de color de las etapas: el estado inicial, la versión con neutros más fríos y la versión final.

Cuatro estados documentados

Un tablero en un design system no sirve de mucho si solo existe en su estado de reposo. Construí cuatro.

  1. Rejected colapsado: la columna final queda como una franja vertical angosta, disponible pero fuera del camino.
  2. Rejected expandido: abierta, con tarjetas que muestran una línea breve con el motivo en lugar de una calificación.
  3. Drag and drop: la tarjeta levantada con el cursor de agarre, un fantasma atenuado en su posición original y el destino marcado con un contorno punteado.
  4. Acciones masivas: varias tarjetas seleccionadas con checkboxes y una barra de acciones oscura con la cantidad seleccionada y las acciones disponibles.

Son frames estáticos, no un prototipo. La idea era documentar los estados para que quien los construya tenga de dónde partir.

Los cuatro estados del tablero: Rejected colapsado, Rejected expandido, drag and drop y acciones masivas.

Todo sobre un candidato, en una sola pantalla

El perfil reúne identidad, datos de contacto, habilidades, adjuntos, avance por etapas, métricas, scorecards de entrevistas, notas y un timeline de actividad. Es mucho para una sola pantalla sin que se vuelva una pared.

Lo dividí en dos. Un panel lateral izquierdo fijo contiene todo lo que identifica a la persona y la acción principal. El área principal está organizada en pestañas y abre en un resumen que muestra el stepper, cinco métricas clave, los scorecards, las notas recientes y la actividad.

El stepper hace más de lo que su tamaño sugiere. Responde en qué parte del proceso está el candidato antes de que se lea cualquier otra cosa en la pantalla.

Perfil del candidato completo, con el panel lateral de identidad y el área principal en pestañas.

Dos modos, una definición de componente

El modo oscuro es un mapeo semántico separado, no una inversión.

Cada token semántico tiene un valor para cada modo, y por eso una sola definición de componente se ve correctamente en cualquiera de los dos. El oscuro necesitó rampas de primitivos más largas: las superficies que en claro funcionan en el paso 900 necesitan en oscuro pasos que no existen hasta el 1000 o más, así que varias rampas se extendieron.

La geometría del layout es idéntica en ambos modos. Solo cambia cómo se resuelven los semánticos.

Un mismo tablero dividido por la mitad: la izquierda en modo claro y la derecha en modo oscuro.

22 componentes

Cada componente tiene una descripción, para que cualquiera que abra el archivo entienda para qué sirve sin tener que desarmarlo.

Algunas decisiones que vale la pena mencionar:

  • Los componentes usan barras en el nombre para agruparse en el panel de assets: Badge/Stage, Board/Column, Profile/Scorecard. Los subcomponentes internos llevan un guion bajo como prefijo para que no estorben.
  • Las capas dentro de los componentes se nombran por su función, nunca por el contenido de ejemplo. Una capa de texto llamada “John Doe” se queda llamando “John Doe” para siempre, aunque la instancia diga otra cosa.
  • La barra de progreso del attachment chip es un frame con auto layout y extremos redondeados iguales, así que su relleno depende del valor del gap y no de un ancho fijo. El gap se puede editar en una instancia; el ancho de un hijo no. Eso permite redimensionar la barra sin desacoplarla y animarla entre frames con Smart Animate.
Muestra de varios de los 22 componentes del kit.

Contraste, verificado en ambos modos

Cada combinación de color de texto y de elementos interactivos se verificó con Stark contra WCAG AA, en modo claro y oscuro.

La accesibilidad decidió qué pasos podía usar. Hubo casos en que el valor que se veía mejor no pasaba y tuvo que irse, y eso es parte de por qué el mapeo de etapas terminó usando un paso distinto en cada rampa.

Verificación de contraste de las combinaciones de color con la herramienta Stark contra WCAG AA.