Coverage Audit vs No Tokenizados en Figma

Coverage Audit en Figma mide qué parte de las propiedades comprobadas están vinculadas a Variables; Find Untokenized Values lista cada literal codificado que sigue en el lienzo. Responden preguntas distintas, leen la misma API boundVariables y se ejecutan en este orden: puntuación de cobertura primero, limpieza de literales segundo, Contrast Audit tercero en el mismo alcance.

Los equipos usan ambas comprobaciones cuando cae la adopción de design tokens - tras una migración de tokens, una fusión de librerías o meses de correcciones puntuales. Los valores codificados suelen verse bien en la UI pero rompen modos, exportación y handoff con desarrollo. Esta guía compara las dos auditorías, cuándo usar cada una y cómo encajan en la gobernanza del sistema de diseño; Atomize ejecuta ambos escaneos en un solo plugin. Consulta la guía de design tokens para capas de tokens y DTCG para el contexto de exportación.

En resumen

• Coverage Audit = porcentaje de vinculación en rellenos, opacidad, padding y gap (Total / Bound / Unbound).
• Find Untokenized Values = cada literal codificado con ruta de capa, valor bruto y token sugerido en trece categorías.
• Orden: Coverage primero, Untokenized segundo, Contrast Audit tercero en el mismo alcance.

Cómo encontrar valores codificados en Figma

Los valores codificados son literales en el inspector (hex, px, opacidad) sin alias de Variable en esa propiedad dentro de boundVariables. A escala de archivo, la inspección manual no termina; los equipos ejecutan un escaneo dedicado en alcance Selection, Page o File. El flujo completo - trece categorías, tokens sugeridos, exportación y revinculación - está en Encontrar Valores No Tokenizados en Figma. Usa Coverage Audit primero cuando también necesites un porcentaje único de vinculación para medir la adopción de tokens antes de esa limpieza.

La gobernanza de design tokens es más que publicar una librería de variables: es seguir la salud de las vinculaciones en el tiempo. Tras una migración de tokens (renombrar colecciones, separar primitivos de semántica o absorber un archivo legacy), el porcentaje de cobertura más un backlog no tokenizado son las comprobaciones habituales antes de dar el archivo por listo para design ops e ingeniería.

Dos auditorías, dos preguntas

Cobertura de tokens (Coverage Audit) pregunta: «¿Esta propiedad está conectada a una Variable?» Suma total por cada propiedad admitida e incrementa bound solo cuando Figma reporta alias de variable en ese slot. No tokenizado pregunta: «¿Este valor sigue siendo un literal en el lienzo?» Lee la misma API boundVariables pero reporta el valor bruto, agrupa por categoría de diseño (Fill, Padding, Font size) y puede proponer color/primary/default cuando tu librería ya define ese hex. Ninguna sustituye a la otra: Coverage es el pulso; Untokenized es la lista de corrección.

¿Cuándo usar Coverage Audit?

• Antes de un hito o revisión de diseño cuando los stakeholders necesitan un solo porcentaje de vinculación en la pantalla o página.
• En Selection mientras refactorizas un componente y quieres una puntuación rápida antes/después.
• Justo después de una migración de tokens o fusión de librería - para ver si la revinculación se mantuvo en rellenos, padding y gap.
• Cuando importan más las métricas de adopción de tokens que una lista línea por línea de correcciones.

¿Cuándo usar Find Untokenized Values?

• Antes de publicar la librería o el handoff con desarrollo cuando necesitas cada literal con ruta y valor bruto.
• Cuando Coverage parece sano pero trazo, radio, tipografía o efectos nunca entraron en el pase de cobertura.
• Cuando design ops necesita JSON o XLSX para seguir correcciones fuera de Figma.
• Tras un % bound bajo en Coverage y necesitas la lista de corrección por categoría.

Qué comprueba Coverage Audit

Coverage Audit recorre el árbol de nodos con alcance Selection o Page y cuenta el estado de vinculación por clave de propiedad de Figma. Por nodo inspecciona rellenos visibles, opacidad parcial (entre 0 y 1), los cuatro lados de padding cuando hay layout con padding, y itemSpacing cuando aplica gap en auto-layout. Si boundVariables contiene alias para esa clave, la propiedad cuenta como bound; si no, aparece en Unbound bajo nombres como fills, paddingTop o itemSpacing. El informe no compara píxeles con tu escala - solo si existe enlace a Variable, como documenta Figma para vinculación.

Usa Coverage cuando necesites un número antes de la revisión de diseño: «¿Estamos al 40% o al 90% vinculados en esta pantalla?» Un porcentaje bajo suele indicar que el frame es anterior a tus colecciones de variables o que una rama nunca pasó por revinculación - no que los colores individuales sean incorrectos.

Dónde abrir cada auditoría en Atomize

Instala Atomize desde Figma Community y abre el plugin en tu archivo. Find Untokenized Values está en el panel principal de Atomize: ahí entras al escaneo de trece categorías, exportación y tokens sugeridos. Coverage Audit se ejecuta en el mismo plugin en el panel Coverage Audit (figura en las funciones Free de Atomize como coverage audit). Si tu versión muestra la tarjeta Coverage Audit en el panel, úsala; si no, abre Coverage Audit desde la navegación del plugin de tu build. Ambas herramientas comparten alcance Selection y Page antes de pulsar Scan.

Qué comprueba Find Untokenized Values

Find Untokenized Values es la auditoría profunda de nuestra guía completa del escáner. Considera tokenizada una propiedad solo cuando boundVariables (o vinculaciones en paints) incluyen VARIABLE_ALIAS. Todo lo demás es un hallazgo, aunque el literal coincida con un paso de paleta que ya publicaste - #2563eb junto a un color/blue/600 existente sigue apareciendo hasta que alguien lo vincule. El escáner carga colecciones locales, resuelve cadenas de alias y rellena token sugerido cuando un literal coincide con hex o paso numérico del archivo.

En archivos maduros, padding y gap suelen generar más filas que color porque navegación y formularios pre-token usaron números correctos sin vinculación. La QA visual rara vez lo detecta; el escáner sí.

Trece categorías - qué auditoría las ve

La tabla siguiente replica la lista de categorías del artículo del escáner Untokenized. Coverage Audit cubre las vinculaciones de layout y relleno más frecuentes; Untokenized cubre la superficie completa antes de exportar y modo oscuro.

Orden recomendado: coverage, untokenized, contrast

1. Ejecuta Coverage Audit en Selection al arreglar un componente, o en Page antes de un hito - anota el porcentaje bound y qué claves dominan Unbound.
2. Ejecuta Find Untokenized Values en el mismo alcance - trabaja categoría por categoría, usa tokens sugeridos cuando coincidan con tu nomenclatura, Skip para one-offs de marketing, exporta JSON o XLSX si design ops lleva tickets fuera de Figma.
3. Vuelve a escanear Untokenized hasta vaciar grupos críticos en ese alcance, luego Contrast Audit en la misma selección o página para comprobar objetivos de contraste WCAG 2.1 en texto y rellenos ya vinculados.
4. Repite por pantalla en archivos grandes en lugar de un pase File que mezcle exploración con UI de producción.

Contrast Audit va al final porque limpiar vinculaciones puede cambiar qué variables de color aplican a texto y fondos; revisar contraste en literales que vas a reemplazar desperdicia un ciclo.

Informe típico tras el primer escaneo Untokenized

Tras el primer escaneo Page en un dashboard legacy, los grupos suelen apilarse así - recuentos ilustrativos de archivos tipo producción, no una garantía para el tuyo:

• Padding (24 hallazgos) - Main > Sidebar > Nav item con literales 16px / 12px que visualmente coinciden con tu escala.
• Gap (11) - pilas auto-layout con 8 y 4 en bruto en lugar de gap/2 y gap/1.
• Fill (9) - azules de marketing y grises legacy sin alias pese a primitivos en la librería.
• Corner radius (7) - tarjetas a 8px sin vinculación a cornerRadius.
• Font size (5) - cuerpo a 14px en componentes anteriores a variables tipográficas.
• Opacity (2) - overlays al 40% sin variable FLOAT.

Coverage en la misma página puede mostrar 62% bound con la mayoría de Unbound en paddingTop y fills - los mismos nodos, pero Coverage no lista hex ni sugiere space/4. Por eso los equipos ejecutan Coverage primero por la puntuación y Untokenized después por la lista de trabajo.

/* Mismo botón - Coverage marca claves sin vincular */
fills: sin VARIABLE_ALIAS→ Unbound (Coverage)
paddingTop: sin alias→ Unbound (Coverage)

/* Untokenized añade literal + pista */
fill= #0d99ff                      → sugerir color/primary/default
padding-top= 16px                  → sugerir space/4

Confusiones frecuentes que vemos

• Dar por cerrado con un % alto de Coverage mientras trazo, radio y tipografía nunca entraron en el pase de Coverage - ejecuta Untokenized antes del release.
• Asumir que un relleno vinculado usa el token semántico correcto - Coverage solo comprueba que alguna Variable está enlazada, no el nombre de tu guía de tokens.
• Ejecutar Contrast antes de revincular - los fallos cambian tras enlazar los tokens de rol previstos.
• Usar alcance File en páginas de trabajo activo - Selection o Page mantiene el informe accionable.

Lectura relacionada

• Encontrar Valores No Tokenizados en Figma - flujo completo del escáner, alcances y exportación
• Auditoría de Contraste Figma para WCAG - pares de tokens tras la limpieza de vinculaciones
• Design Tokens de Figma: La Guía Completa - primitivos, semántica y modos

Veredicto final - Coverage vs Untokenized

Coverage Audit indica cuánta superficie comprobada está enlazada a Variables; Find Untokenized Values indica qué literales corregir y a menudo a qué token vincular. Coverage primero por el porcentaje, Untokenized segundo por la lista de trabajo, Contrast tercero por accesibilidad en los tokens que conservaste. Juntas convierten «usamos variables en algún sitio» en un archivo gobernable - sin duplicar la guía larga de Untokenized en cada duda de auditoría.