Encontrar Valores No Tokenizados en Figma: Auditoría de Cobertura de Tokens

Los valores codificados se acumulan en cada archivo de Figma que usa tokens de diseño — no por descuido de los diseñadores, sino porque las Variables de Figma son opcionales a nivel de propiedad. Cada relleno, lado de espaciado, radio y tamaño de fuente debe vincularse individualmente, y ningún flujo de trabajo fuerza ese paso al elegir un color o establecer un valor de espaciado. El resultado es la deriva de tokens: propiedades que parecen correctas en el lienzo pero no tienen vinculación a Variable, invisibles para los cambios de modo, las exportaciones de tokens y los cambios aguas arriba en el sistema de diseño. La revisión manual, propiedad por propiedad, es técnicamente posible pero impracticable en archivos con miles de capas. El escáner Find Untokenized Values de Atomize recorre trece categorías de propiedades en cualquier archivo, página o selección, verifica cada propiedad contra boundVariables y produce un informe agrupado con un token sugerido para cada hallazgo — para que la limpieza se traduzca directamente en un flujo de tickets.

Flujos relacionados: Guía completa de Design Tokens en Figma para capas primitivas y semánticas, Coverage Audit vs Valores No Tokenizados para la diferencia entre puntuación de vinculación y lista de literales, Auditoría de contraste para WCAG para verificaciones de accesibilidad tras la limpieza de vinculación, y la especificación DTCG para los estándares de exportación de tokens.

Qué es un valor tokenizado en Figma

Un valor tokenizado en Figma es cualquier propiedad de capa vinculada a una Variable de Figma a través del mapa boundVariables de ese nodo. El inspector puede seguir mostrando #0D99FF o 16px, pero Figma almacena un VARIABLE_ALIAS que apunta a un ID de variable — así los cambios de modo, las actualizaciones de biblioteca y las exportaciones de tokens se resuelven con nombres como color/primary/default o space/4 en lugar de un literal puntual. Tokenizado no significa «se ve acorde a la marca». Dos componentes pueden compartir rellenos y espaciados idénticos mientras solo uno está vinculado. El escáner comprueba únicamente la vinculación: si un slot de propiedad no tiene alias en boundVariables, el valor no está tokenizado y entra en el informe aunque los píxeles coincidan con tu escala primitiva. Por eso los equipos combinan este escaneo con una configuración estructurada de tokens primitivos y semánticos — nombres y vinculaciones deben alinearse, no solo la apariencia.

Qué significa realmente «no tokenizado»

Un valor no tokenizado es una propiedad que contiene un literal bruto sin alias de Variable en ese slot. Un relleno de #0D99FF y un relleno vinculado a color/primary/default se ven idénticos en el lienzo; solo el vinculado responde a los cambios de modo, fluye a través de tu pipeline de exportación de tokens y recoge cambios de los tokens aguas arriba. El escáner señala cada literal que expone la API — esa clasificación es binaria y mecánica, por lo que un pase automatizado es la única forma honesta de medir la cobertura en miles de capas. La deriva de tokens se acumula más rápido en las propiedades de espaciado y radio, no en el color. Las anulaciones de color se detectan en la revisión visual porque un rojo incorrecto es obvio. Un valor de espaciado 2px fuera de la escala de tokens pasa desapercibido durante meses, hasta que un desarrollador compara la especificación de diseño con el código y descubre que la brecha se ha convertido en un desajuste de múltiples propiedades. Los componentes con más probabilidades de tener espaciado codificado son aquellos construidos antes de que se estableciera el sistema de tokens: barras de navegación, modales y elementos de formulario.

Tokenizado vs no tokenizado - un ejemplo rápido

El mismo frame de botón puede verse idéntico en dos archivos y seguir estando en estados completamente diferentes. El primero está completamente vinculado; el segundo tiene los mismos valores, escritos a mano. El escáner ignora el primero y reporta cada propiedad del segundo.

/* Tokenizado - vinculado a Variables */
relleno          →  color/primary/default (#0d99ff)
relleno/x        →  space/4 (16px)
relleno/y        →  space/3 (12px)
radio            →  radius/md (8px)
fuente/tamaño    →  text/body/md (14px)

/* No tokenizado - mismos valores, sin vinculación */
relleno          =  #0d99ff
relleno/x        =  16px
relleno/y        =  12px
radio            =  8px
fuente/tamaño    =  14px

El coste real de la deriva de tokens

La deriva de tokens no es un problema cosmético — conlleva un coste medible en cuatro dimensiones.

Inconsistencia de diseño. Dos componentes que deberían compartir el mismo lenguaje visual divergen silenciosamente. Una tarjeta usa 16px de relleno mediante una Variable; otra, copiada de un archivo diferente, usa 14px escritos a mano. La diferencia son un par de píxeles hoy. Seis meses después es un sistema de diseño en el que nadie confía, porque el control visual detecta la inconsistencia pero no puede rastrearla hasta su causa raíz.

Confusión del desarrollador. Cuando la especificación de diseño muestra 16px pero el sistema de tokens define space/4 como 12px, los desarrolladores se ven obligados a elegir: codificar el valor en CSS (duplicando la deriva en el código) o señalar la inconsistencia en revisión (retrasando el sprint). En cualquier caso, el contrato de tokens entre diseño y código se rompe. Con el tiempo, los desarrolladores dejan de confiar en los nombres de los tokens y vuelven a leer valores de píxeles del inspector — anulando el propósito de un sistema de tokens de diseño.

Fallos de accesibilidad. Los ratios de contraste codificados no responden al modo oscuro, al modo de alto contraste ni a la tipografía escalada por el usuario. Un par de colores que cumple WCAG AA en modo claro puede fallar por completo en modo oscuro cuando los valores no pasan por Variables conscientes del modo. El problema es invisible en la revisión de diseño — solo aparece en producción, donde la solución es más lenta y costosa.

Costes de rebranding. Sin vinculación, cambiar un color primario implica buscar en cada frame y componente — una auditoría manual que lleva días en un archivo maduro — en lugar de actualizar una Variable y ver cómo el archivo se resuelve en segundos. El coste es proporcional al tiempo que la deriva pasó desapercibida.

Cuándo aparece la deriva — el ciclo de vida del sistema de diseño

La deriva de tokens sigue un patrón predecible a lo largo del ciclo de vida del sistema de diseño. Entender cuándo ocurre ayuda a los equipos a presupuestar el esfuerzo de auditoría en los momentos adecuados.

Etapa temprana (0–3 meses). El conjunto de tokens está incompleto. Los diseñadores asignan Variables donde existen y codifican el resto porque la alternativa es bloquear el trabajo hasta que cada token esté definido. Esto es normal y esperable — el objetivo en esta etapa no es la deriva cero, sino un plan de cuándo se ejecutará la primera auditoría.

Etapa de crecimiento (3–12 meses). Los componentes se copian entre archivos, se fusionan en bibliotecas y se adaptan para nuevas funcionalidades. Copiar y pegar arrastra los valores literales pero no la vinculación — el archivo de destino puede ni siquiera tener las mismas colecciones de Variables. Las entregas de agencias, las plantillas de la comunidad y los frames de exploración de diseño introducen nuevos literales más rápido de lo que la revisión manual puede detectarlos.

Etapa madura (12+ meses). El sistema de tokens está completamente definido, pero los componentes construidos antes de su establecimiento siguen vivos en los archivos de producción — barras de navegación, modales, elementos de formulario que pasaron cada revisión visual porque sus valores codificados coincidían con la paleta. Los nuevos miembros del equipo se incorporan sin conocer completamente la estructura de tokens y añaden valores puntuales durante iteraciones rápidas. Los componentes pre-token de este tipo suelen representar el 60–70% del total de hallazgos en un primer escaneo.

Auditoría manual vs escaneo automatizado

Antes de los escáneres automatizados, los equipos dependían de auditorías manuales de tokens — un diseñador abre el archivo, inspecciona las propiedades de cada componente una por una y anota cualquier cosa que parezca un valor codificado. La tabla a continuación muestra por qué ese enfoque falla en archivos reales.

Auditoría manual vs escaneo automatizado para cobertura de tokens

La diferencia fundamental está en la lógica de detección. Un auditor humano compara un valor de relleno con la escala de tokens y se pregunta «¿esto parece correcto?» — lo que pasa por alto una desviación de 2px en espaciado cada vez. Un escáner verifica boundVariables y se pregunta «¿hay un alias en este slot?» — lo que detecta cada propiedad no vinculada independientemente de si el valor en píxeles coincide con la escala.

Por qué aparecen valores no tokenizados en sistemas de diseño maduros

La deriva de tokens es un problema estructural, no un fallo de disciplina — no puedes corregirla a base de insistencia. En un sistema de diseño, los tokens son el contrato compartido que debe mantenerse sincronizado entre los archivos de diseño y el código, y la deriva rompe ese contrato silenciosamente. Las Variables en Figma son opcionales a nivel de propiedad y ningún flujo de trabajo fuerza ese paso en el momento de editar. Al construir las herramientas de auditoría de Atomize con archivos de diseño reales, encontramos sistemáticamente que la deriva entra por cuatro vectores: frames de exploración copiados a la página de componentes sin limpieza de vinculación, tonos de corrección rápida que nadie incorpora a la biblioteca de tokens, componentes construidos antes de que existieran sus definiciones de tokens y frames importados de bibliotecas no publicadas o externas. Cada incidente es menor; el agregado es la brecha que describen los hilos de r/DesignSystems — tokens y variables que se vuelven «inconsistentes o desaparecidos» una vez que un producto lleva suficiente tiempo en marcha. Un escaneo automatizado convierte ese agregado invisible en una lista numerada.

Qué comprueba el escáner de Atomize

El escáner cubre trece categorías de propiedades en un solo paso, cerrando las brechas de auditoría que dejan abiertas las herramientas que solo verifican color. La deriva de espaciado y radio es más difícil de detectar visualmente que la deriva de color — un valor de relleno 2px fuera de la escala pasa la revisión de diseño durante meses — y sin embargo la mayoría de los plugins de la comunidad se detienen en rellenos y trazos. En escaneos de producción, las categorías de relleno y espacio producen rutinariamente más hallazgos que el color en componentes construidos antes de que se estableciera el sistema de tokens.

La cobertura completa de categorías: color de Relleno y Trazo (variables COLOR), Grosor de trazo, Radio de esquina, Relleno, Espacio, Margen, Opacidad y Altura de línea (variables FLOAT), Efectos incluyendo sombra exterior, sombra interior, desenfoque de capa y desenfoque de fondo (variables COLOR / FLOAT), Familia tipográfica (variables STRING) y Tamaño y Peso de fuente (variables FLOAT / STRING). Si solo has construido una capa primitiva hasta ahora — lo cual está bien para sistemas en etapa temprana — el escáner aún encuentra coincidencias cuando los valores brutos se alinean con las variables primitivas. Para un resultado más completo, combina esta auditoría con una estructura de tokens primitivos y semánticos saludable para que las sugerencias apunten a los nombres que realmente quieres que los componentes vinculen.

Tres alcances de escaneo - Selection, Page, File

Elegir el alcance de escaneo correcto es el factor más importante en la relación señal-ruido del informe. Un escaneo File en un archivo de trabajo activo mostrará cientos de hallazgos en progreso junto con la deriva real, diluyendo los elementos accionables; un escaneo Selection en un componente terminado da un resultado limpio y rápido. Un ritmo práctico de tres alcances: Selection como comprobación continua mientras se itera, Page antes de las entregas de revisión de diseño, y File como puerta dura antes de cada publicación de biblioteca. Adapta el alcance al momento de tu flujo de trabajo y el informe seguirá siendo útil en lugar de abrumador.

Comparación de los tres alcances de escaneo

En archivos de larga trayectoria, el alcance File puede producir miles de hallazgos en la primera ejecución. Trata ese escaneo inicial como una línea base y presupuesta la limpieza en iteraciones en lugar de bloquear el trabajo en un único ticket prioritario.

Leer el informe y actuar sobre él

El informe agrupa los hallazgos por categoría de propiedad. Cada fila muestra el nombre del nodo, su ruta de capa, la página en la que se encuentra, el valor bruto y un token sugerido cuando coincide uno — hacer clic en el nombre del nodo lo selecciona en el lienzo y cambia automáticamente a la página correcta. Trabaja el informe categoría por categoría: resuelve primero los colores, luego relleno y espacio, luego tipografía. Los efectos y la opacidad tienden a producir los casos únicos más intencionales y son buenos candidatos para un pase de Skip. Cuando es posible, el informe nombra el token que probablemente querías — Atomize carga todas las colecciones de variables locales, sigue las cadenas de alias hasta llegar a un literal y construye mapas de búsqueda de valores hex a variables de color y de valores numéricos a variables numéricas. La sugerencia es una pista, no una acción automática — tú mantienes el control sobre lo que se vincula. Vuelve a escanear después de cada pase de limpieza para confirmar que la vinculación se realizó correctamente.

Find Untokenized Values vs otros plugins de auditoría de Figma

El escáner de Atomize es la única herramienta en la comunidad actual de Figma que cubre las cinco dimensiones de auditoría — color, espaciado, tipografía, efectos y sugerencias de tokens — con exportación en un solo paso. La mayoría de las alternativas manejan bien los rellenos y trazos pero se detienen ahí, dejando la deriva de espaciado y tipografía invisible a menos que ejecutes un segundo plugin. En auditorías de archivos reales, las categorías que esas herramientas omiten — relleno, espacio, tamaño de fuente, altura de línea — eran precisamente donde vivían las mayores acumulaciones de deriva en productos maduros.

Atomize Find Untokenized Values vs otros plugins de auditoría de Figma

Mejores prácticas para mantener alta la cobertura

La cobertura de tokens solo mejora de forma duradera cuando el escaneo es parte del ritual de publicación, no una limpieza única. Una sola auditoría revela la deuda pendiente; no detiene la próxima ronda de deriva, porque la causa raíz — la incorporación opcional por propiedad sin una puerta — persiste. Los equipos que ejecutaron el escáner con regularidad detectaron las regresiones dentro del ciclo de iteración en lugar de en la retrospectiva post-publicación, lo que hizo que cada corrección fuera pequeña y contextualmente obvia en lugar de grande y arqueológicamente confusa. Combina los escaneos regulares con las mejores prácticas del sistema de diseño más amplias que mantienen la estructura de Variables saludable y las sugerencias precisas.

Ejecútalo en cada rama de publicación

Antes de publicar una nueva versión de la biblioteca, ejecuta un escaneo de alcance File y resuelve primero las categorías de alto impacto — colores, luego relleno y espacio, luego tipografía. Los efectos y la opacidad tienden a producir los casos únicos más intencionales y son buenos candidatos para una pasada de Skip en lugar de una pasada de corrección.

Alcance por componente, no por página

Cuando los diseñadores están en mitad de la iteración, un escaneo Page puede ser demasiado ruidoso porque los frames de trabajo en progreso contaminan el informe. El alcance Selection en el componente activo te da un ciclo de retroalimentación más rápido y respeta el hecho de que la exploración siempre implica algunos valores codificados que se normalizarán más tarde.

Limitaciones que debes conocer antes de escanear

• Los degradados se reportan como gradient-{type} en lugar de un hex, por lo que la coincidencia del token sugerido cae de vuelta a la revisión manual para los rellenos con degradado.
• Los efectos se comprueban a nivel de vinculación de estilo, no por propiedad de sombra, por lo que una sombra parcialmente vinculada puede seguir siendo marcada como no tokenizada.
• El espaciado dentro de los grupos denominados icon o banner se omite intencionalmente para evitar falsos positivos en los layouts de vectores internos.
• El escáner recorre como máximo 100 niveles de profundidad — el anidamiento extremo más allá de eso es raro en la práctica pero vale la pena conocerlo.
• La vinculación automática desde el informe no está expuesta en la interfaz actual; el informe señala las sugerencias, tú haces la vinculación en el selector de variables de Figma.

Estas restricciones son límites de la API de Figma, no brechas en el diseño del escáner. La API del Plugin expone algunas vinculaciones como estilos de pintura y otras como alias directos de Variable, por lo que un escáner que las confunda produciría falsos negativos en los nodos vinculados a estilos. La documentación oficial de Variables de Figma es la referencia más fiable si quieres saber exactamente qué propiedad expone qué forma de vinculación.

Dónde encaja esto en un flujo de trabajo impulsado por tokens

Find Untokenized Values cierra el lado de entrada del pipeline de tokens — confirmando que los valores de diseño están realmente vinculados antes de llegar al código. Si tu equipo confunde este escaneo con Coverage Audit de Atomize, lee Coverage Audit vs Valores No Tokenizados para la diferencia entre puntuación de vinculación y lista de literales, y el orden de ejecución. Combínalo con una auditoría de contraste en Figma antes de publicar para que los fallos de accesibilidad no pasen cuando la vinculación ya está limpia — cumplir los umbrales de contraste WCAG 2.1 es el mínimo exigible. Vincular sin exportar sigue siendo una brecha: los equipos que ejecutan el escáner consistentemente también necesitan el lado de salida — mover las Variables a JSON DTCG, propiedades CSS personalizadas o constantes TypeScript mediante un flujo de trabajo de paridad diseño-código. El W3C Design Tokens Community Group ha estado estandarizando el formato de intercambio en la especificación DTCG, y herramientas de construcción como Style Dictionary muestran el pipeline completo de extremo a extremo. Ejecuta la auditoría antes de cada paso de exportación y te aseguras de que el lado del diseño cumple el contrato antes de llegar al código.

Veredicto final - Find Untokenized Values

La cobertura de tokens no es medible por inspección — la deriva se oculta en propiedades que parecen correctas en el lienzo pero no llevan ninguna vinculación de Variable. Find Untokenized Values elimina ese punto ciego: recorre el árbol de nodos completo, verifica cada propiedad contra boundVariables, nombra el token que probablemente querías y exporta el resultado para que la limpieza pase a un flujo de tickets real en lugar de quedarse en la memoria del diseñador. Conviértelo en una puerta de publicación y el informe se convierte en una señal de regresión; ignóralo y la deriva se acumula silenciosamente hasta que la brecha entre diseño y código es demasiado grande para cerrarla en un sprint.