Cómo auditar un design system en 5 días: la checklist

Dentro de cinco días laborables puedes tener tres cosas sobre la mesa: un inventario de componentes con todas las variantes en producción, un mapa de cuánto se ha alejado el producto de la fuente de verdad y una lista de arreglos ordenada por impacto, lista para que un desarrollador la empiece el lunes. Eso es lo que produce una auditoría de design system. Aquí tienes la checklist que seguimos día a día.

La auditoría hace falta cuando el sistema cuesta más de lo que ahorra. Las señales las conoces. Un diseñador rehace un botón porque el correcto está enterrado tres páginas dentro de la biblioteca. Dos pantallas que salieron en el mismo sprint parecen dos productos distintos. Nadie sabe decir cuál de los cuatro grises es el oficial. El zeroheight Design Systems Report 2026 encontró que tres de cada cinco equipos de design system están cortos de personal y que el 16% de los sistemas los mantiene una sola persona. La deriva es la consecuencia previsible. Una auditoría no contrata a nadie, pero le dice a un equipo pequeño dónde le rinden las próximas diez horas.

La forma es fija: un día para el inventario, uno para medir la deriva, uno para la accesibilidad, uno para tokens y documentación, uno para escribir el plan. Cinco días bastan para un sistema de hasta unos sesenta componentes. A partir de ahí, dobla los plazos.

Qué necesitas antes de empezar

Ten todo listo antes o el primer día se te va al segundo:

• Acceso a la fuente de verdad del diseño (la biblioteca de Figma o equivalente) y a la app en producción o a su Storybook.
• Una hoja de cálculo o una herramienta de auditoría. Con una hoja basta. No compres software para tu primera auditoría.
• Un comprobador de accesibilidad en el navegador. Nosotros usamos axe-core, gratuito y de código abierto.
• Dos o tres flujos de usuario reales que recorrer: registro, el panel principal, una pantalla de ajustes o de pago. Las pantallas valen más que la teoría.
• Noventa minutos reservados con quien es dueño del sistema, el quinto día, para entregar la lista.

Día 1: inventaría cada componente en producción

Abre el producto, no la biblioteca. Recorre los tres flujos y apunta cada componente distinto que veas: botones, campos, tarjetas, modales, tablas, empty states, toasts. De cada uno anota dónde aparece y cuántas variantes visuales existen de verdad. Un botón que sale en cinco colores, tres alturas y dos radios de esquina es una sola fila, con el número de variantes al lado.

El número que importa al final del día es la proliferación de variantes: cuántas versiones de cada componente corren en producción frente a cuántas define la biblioteca. Una biblioteca con un botón primario y once botones primarios en producción tiene una proporción de 11 a 1 en ese componente. Esa proporción es la auditoría en una sola cifra, y la usarás después para priorizar.

Día 2: mide la deriva

La deriva no es una sola cosa. Ordena cada incoherencia que registraste en cuatro tipos, porque cada uno se arregla de otra manera:

• Deriva de tokens. Un valor de color, espaciado o tipografía en el código ya no coincide con la fuente del diseño. Solo cerca del 40% de los equipos tiene una pipeline de tokens automática, así que es con diferencia el tipo más frecuente.
• Deriva de variantes. Un componente se renderiza con propiedades que el diseño nunca especificó. Se extiende rápido ahora que el código generado por IA rellena huecos que el diseñador nunca aprobó.
• Deriva de patrones. Los componentes sueltos son correctos, pero se combinan de forma distinta según el área: el mismo formulario dispuesto de tres maneras.
• Deriva de documentación. La documentación describe un comportamiento que el componente ya no tiene.

Puntúa cada elemento de 0 a 2: 0 si está en línea, 1 para una desviación leve, 2 para un componente que se ha separado del todo. Suma los 2. Ese es el titular del segundo día, y cada 2 es candidato a la lista final.

Día 3: audita la accesibilidad

Pasa axe-core por cada uno de los tres flujos. En segundos marca contrastes insuficientes, etiquetas ausentes y orden de foco roto. Lee los resultados con calma, porque las herramientas automáticas detectan alrededor del 57% de los problemas WCAG y el resto lo encuentra solo una persona. Haz entonces dos pasadas manuales que la máquina no puede: recorre cada flujo usando solo el teclado y comprueba que el foco siempre se vea y nunca quede atrapado. Anota cada componente que falla, porque un componente roto en el sistema es un defecto multiplicado en cada pantalla que lo usa. Desde junio de 2025, con el European Accessibility Act en vigor, estos fallos también pesan en lo legal para los productos que se venden en la Unión Europea.

Día 4: revisa tokens y documentación

Coge el archivo de tokens y compáralo con lo que el producto renderiza de verdad. Dos grises que deberían ser uno, una escala de espaciado con un paso raro de 13px, un tamaño de fuente definido pero nunca usado: registra cada desajuste como deriva de tokens, con su gravedad. Luego abre la documentación y ponla a prueba como lo haría un desarrollador nuevo. Elige tres componentes e intenta usarlos partiendo solo de la documentación. Donde no lo consigas, la documentación se ha ido a la deriva, y los componentes sin documentar son justo los que se rehacen desde cero.

Día 5: escribe la lista de arreglos

Convierte cada 2 de la semana en una fila sobre la que un desarrollador pueda actuar. Cada fila nombra el componente, el tipo de deriva, el arreglo en una frase y una estimación de trabajo en horas o días. Luego ordena con una regla sencilla: arriba la proliferación más alta y cualquier fallo de accesibilidad, abajo los problemas cosméticos de un solo caso. Un hallazgo que se queda en observación no cambia nada. Un hallazgo escrito como "reduce once botones primarios a uno, borra los otros diez, 1 día" se hace. Entrega la lista en la sesión de noventa minutos y acompaña a quien es dueño del sistema por los cinco primeros arreglos.

Cómo saber si la auditoría funcionó

Una semana después de la entrega, tres señales dicen que caló. El número de variantes en tus componentes de cabecera está bajando. Las nuevas pull requests citan la lista por fila. Y el equipo ha dejado de preguntar cuál es el token correcto, porque la auditoría lo nombró. Si nada de eso se mueve, el problema nunca fueron los componentes. Era la gobernanza, y eso es otro trabajo.

Dónde fallan las auditorías

El fallo más común es auditar la biblioteca en vez del producto. La biblioteca es donde el sistema debería estar. El producto es donde el sistema está de verdad, y la distancia entre los dos es todo el sentido del ejercicio. El segundo fallo es marcar todo como urgente: el equipo se queda con una lista de 200 filas y ningún orden en que trabajar. El tercero es entregar un documento que nadie lee. Noventa minutos de walkthrough le ganan a un PDF de cincuenta páginas siempre.

Para seguir

Para entender cómo debería estar organizado el sistema que auditas, lee la estructura de un design system: las 7 categorías y el orden.