Revisión de desviaciones del sistema de diseño: cada pantalla y cada pull request, contra vuestros tokens

El caso, en movimiento

01 / 05La carpetaPantallas, diffs y tokens

Lo publicado, lo que está a punto de publicarse y la fuente de verdad, juntos.

Calidad-de-diseno / Sprint-42

• PNGpantalla-ajustes-produccion.png
• DIFFpr-4821-panel-facturacion.diff
• JSONtokens.json
• MDinventario-componentes.md

4 archivos

02 / 05ClaudePrimero, el sistema

Lee los tokens, la biblioteca y el inventario, y después revisa pantalla por pantalla y diff por diff.

Claude lee el sistema de diseño

• ✓Tokens de color y tipografía
• ✓Componentes aprobados
• ✓Espaciado
• ✓Patrones de interacción

03 / 05TúSi es criterio tuyo, pregunta

Un valor escrito a mano que coincide con un token no es lo mismo que uno que no coincide.

Claude pregunta

¿Marco los valores fijos aunque coincidan con un token?

Sí, con gravedad bajaNo, los omito si coinciden

04 / 05El informe de desviacionesQué se ha desviado y cuánto

Cada hallazgo dice qué regla incumple y cuál es la corrección.

informe de desviaciones · sprint 42

PlanCard.module.css L7	amarillo	valor fijo, gravedad baja
Botón de facturación	rojo	componente no aprobado
Panel de ajustes	verde	coincide, se omite
Espaciado del modal	rojo	fuera de la escala

05 / 05ProgramadasDos veces al día, antes de fusionar

Revisa los pull requests de interfaz abiertos y las últimas capturas de producción.

◷ Tarea programada ActivaRevisión de desviaciones

Días laborables a las 10:00 y a las 16:00

Configuración

Prueba un plugin

El plugin de Design de Anthropic trae /design-system, ya preparada para comparar una pantalla o un pull request con un archivo de tokens y un inventario de componentes. Si tu administrador gestiona los plugins y todavía no está en tu cuenta, sáltatelo: nada de lo que sigue lo necesita.

Conecta tus herramientas

Prepara la carpeta de trabajo

Arrastra a una carpeta las capturas de producción, los diffs de los pull requests que quieres revisar, vuestro archivo de tokens y el inventario de componentes, y añádela a Claude con Añadir carpeta. Claude lee de ahí y deja el informe en la misma carpeta. Si haces este control a menudo, guárdala como un proyecto: la fuente del sistema se carga una vez.

El prompt

Copia esto en Claude, con la carpeta Calidad-de-diseno / Sprint-42 añadida:

Revisa las pantallas publicadas y los pull requests abiertos de esta carpeta contra nuestro sistema de diseño. Para cada uno, enumera cada lugar donde se desvía de nuestros tokens, componentes, espaciado o patrones de interacción, califica la gravedad y propón la corrección que cumple el sistema. Omite todo lo que ya coincida.

Lo que te deja: el informe de desviaciones

Un ejemplo con datos inventados, para que veas el formato:

INFORME DE DESVIACIONES · sprint 42 · tokens v3.4.0 (datos inventados)
Revisado: 3 pantallas y 2 pull requests · 9 desviaciones, 2 de gravedad alta

ALTA   pr-4821 · BillingPanel.tsx L112
       Botón escrito a mano; no es el componente aprobado
       Corrección: usar <Button variant="primary"> de la biblioteca
BAJA   PlanCard.module.css L7
       Valor fijo que coincide con el token (marcado como pediste)
OMITIDO  pantalla-ajustes-produccion.png: coincide con el sistema
Comentario para el pull request #4821: listo para publicar cuando lo apruebes

Por qué funciona

• Prompt1

  Detalla qué revisar. Tokens, componentes, espaciado e interacción: la lista de comprobación es explícita y no depende de lo que a Claude le parezca importante.

• Prompt2

  Pide una gravedad para cada hallazgo. Así el triaje sabe qué corregir este sprint y qué puede esperar.

• Prompt3

  Di qué dejar fuera. El informe contiene solo trabajo por hacer, nunca ruido de lo que ya está bien.

• Fuente

  Pon los archivos de referencia en la carpeta. Los tokens y el inventario se leen, no se recuerdan: la revisión no se desvía con el tiempo.

Para que el borrador salga mejor

• Practicar

  Dale un ejemplo que te guste. Ponlo en la carpeta y Claude seguirá su estructura y su estilo.

• Practicar

  Pídele que señale la incertidumbre. Añade «señala todo lo que no tengas claro» y sabrás dónde mirar primero al revisar.

Haz que Claude trabaje para ti

La skill del plugin es genérica. Cuando el informe sea uno que publicarías de verdad en un pull request, pídele a Claude que escriba vuestra versión de la skill: con vuestros umbrales de gravedad, las excepciones permitidas, la correspondencia entre componente y código, y el tono de comentario al que responde vuestro equipo de desarrollo.

Convierte lo que hemos hecho en esta tarea en una skill, o edita la skill /design-system con mis correcciones.

Hazlo repetible

Compártelo como un artefacto

Las desviaciones se acumulan sin ruido entre un sprint y otro. Pídele a Claude que publique el informe como un artefacto: el equipo del sistema de diseño tendrá un solo enlace, que se actualiza volviendo a ejecutar la skill.

Publica ese informe de desviaciones como un artefacto para el canal del sistema de diseño. Mantén un recuento de los hallazgos de gravedad alta que siguen abiertos.

Ejecútalo en cada pull request que toque la interfaz

Una desviación es mucho más barata de corregir antes de fusionar. Escribe /schedule o abre Programadas en la barra lateral y prográmalo dos veces al día.

/schedule Los días laborables a las 10:00 y a las 16:00, revisa los pull requests etiquetados «ui» y las pantallas nuevas de Calidad-de-diseno/Sprint-42. Ejecuta /design-system en cada uno y deja el informe como comentario del pull request o en [el canal del sistema de diseño].

Compártelo con tu equipo

Tu /design-system personalizado lleva ya los tokens, el mapa de componentes, la escala de gravedad y la lista de excepciones. Compártelo para que cada equipo reciba la misma revisión en cada pull request y el equipo del sistema deje de ser el cuello de botella de «¿esto está dentro del sistema?».

Qué cambia para el control de calidad del diseño

Las pantallas y los pull requests se comprueban contra tu sistema de diseño, con cada desviación calificada, explicada y acompañada de su corrección: trabajo listo para arreglar, no una revisión al azar. Lo hiciste con un conjunto de pantallas; el mismo enfoque vale para las páginas de marketing, la aplicación móvil y las herramientas internas.

Termínalo donde vive el archivo

De cara al futuro

En una agencia de aquí, así se usa

En una agencia que entrega diseño a varios clientes, la desviación aparece cuando el sistema de un cliente pasa por muchas manos: la agencia lo diseña, el cliente lo amplía y otro equipo lo implementa. Cada pull request que toca la interfaz es una oportunidad de que se rompa, y quien lo revisa casi nunca tiene los tokens en la cabeza. Con los tokens y el inventario en la carpeta, la comprobación se hace igual en cada entrega y el comentario sale con el archivo y la línea.

Revisa este diff contra los tokens del cliente adjuntos. Dime cada desviación de color, tipografía, espaciado o componente, con el archivo y la línea, una gravedad (alta, media o baja) y la corrección. Redacta el comentario para el pull request en un tono [cordial y directo], como lo escribiría una persona del equipo de diseño. No lo publiques: déjamelo para que lo revise.

Decides tú qué comentario se publica y qué se corrige antes de fusionar. Claude revisa y propone; quien responde ante el cliente es la persona del equipo.