Component drift: como se degrada un design system y como detectarlo

Abre un producto que lanzo un design system hace un ano. Mira tres botones en la misma pantalla. A menudo encuentras tres radios de borde distintos, dos versiones del mismo azul "primario" y un boton que se anima al pasar el raton mientras los demas se quedan quietos. Nadie lo decidio. Se acumulo.

Esa acumulacion es el component drift: la lenta divergencia entre los componentes que define tu design system y la interfaz que de verdad sale a produccion. El sistema no se rompio en un commit. Se erosiono en cientos de decisiones pequenas y sin revisar, cada una razonable por separado. Cuando alguien se da cuenta, la limpieza ya no es un ticket. Es un proyecto.

Que aspecto tiene el component drift en un codigo real

El drift no es un solo problema. Aparece en cuatro formas, y casi todos los equipos las tienen las cuatro a la vez.

Drift de componentes. El mismo elemento existe en tres o cuatro versiones casi identicas. Un Card en la libreria, un Card que alguien copio y ajusto para el dashboard, y un tercero hecho desde cero porque los dos primeros "no encajaban".

Override de tokens. Los valores locales se cuelan. Un espaciado de 14px donde la escala solo tiene 12 y 16. Un codigo hexadecimal pegado a mano en lugar de un token de color. Cada override es pequeno. Juntos fragmentan el sistema hasta que nadie sabe que significa "estandar".

Proliferacion de variantes. Las variantes "solo por esta vez" se acumulan. Un boton gana un tamano nuevo para una campana, un color nuevo para un equipo, un hueco de icono para una pantalla. A los seis meses el boton tiene cuarenta variantes y nadie sabe cuales estan aprobadas.

Drift de comportamiento. Lo visual coincide, el comportamiento no. Un modal atrapa el foco, otro no. Un formulario valida al salir del campo, otro al enviar. Es el drift mas dificil de ver, porque una captura parece correcta.

Estas cuatro formas se suman. Un override de un token genera un componente casi identico, que alguien bifurca en una variante nueva, que se comporta un poco distinto del original. Una pequena desviacion de un martes se convierte en cuatro tipos de drift para el trimestre siguiente. Por eso el drift parece invisible hasta que esta en todas partes: cada paso es demasiado pequeno para marcarlo, y el total es demasiado grande para ignorarlo.

Por que pasa el drift, y por que culpar a las personas no sirve

El drift casi nunca nace de una mala decision. Nace de una buena decision cuyo razonamiento no viajo. Como dice el equipo de UXPin, un sistema se va a la deriva porque el pensamiento detras de los componentes buenos nunca se comunico lo bastante bien como para evitar los malos.

Tres mecanismos explican la mayoria de los casos. Primero, los handoffs en los que se reconstruye: cuando un ingeniero recrea un diseno a partir de un mockup estatico, la interpretacion se cuela, los casos limite se escapan y bajo plazo se hacen sustituciones. Segundo, la falta de un proceso de entrada para los cambios: sin una forma definida de pedir un token o una variante nuevos, los equipos los anaden sobre la marcha para resolver el problema que tienen delante. Tercero, la brecha de adopcion: un sistema tecnicamente solido se acaba esquivando en seis meses cuando el equipo lo recibio hecho en lugar de construirlo. Ninguno de estos es el villano. Ese es el punto. El drift es una propiedad del sistema, no un fallo personal.

Cuanto cuesta de verdad el drift

El dato de partida da que pensar. En el Design Systems Report 2026 de zeroheight, solo el 8% de los equipos describe su sistema como "muy estable", mientras que el 44% lo considera inestable o muy inestable. Casi la mitad del sector construye sobre cimientos que se mueven.

La cuenta se paga en tres sitios. Mantenimiento: una sola actualizacion de marca se convierte en una revision enorme sobre decenas de componentes, con mucho margen para que algo se escape. Velocidad: los ingenieros dejan de fiarse de la libreria y reconstruyen desde cero, asi que el sistema deja de ahorrar tiempo, que era todo su proposito. Calidad: estados de foco y validaciones incoherentes son fallos de accesibilidad, y con la European Accessibility Act, en vigor desde junio de 2025, eso supone un riesgo real. Un sistema que se va a la deriva no solo se ve desordenado. Convierte en silencio tu mayor palanca de eficiencia en un lastre. Cuanto mas tiempo corre sin control, mas se extiende el instinto de reconstruir, y la interfaz reconstruida es drift con otro nombre.

Como arreglar el drift que ya tienes

Del drift que ya existe no se sale solo con prevencion. Primero hay que encontrarlo. Una auditoria del design system mapea cada decision visual en produccion y senala donde hay valores escritos a mano en lugar de tokens.

Haz la limpieza en este orden. Escanea el codigo en busca de valores hardcoded que deberian ser tokens y de tokens que ya no coinciden con su definicion. Unifica los componentes casi identicos en uno solo, dejando solo las variantes que el sistema aprueba de verdad. Marca el resto como obsoleto con un calendario claro, en vez de borrarlo de un dia para otro, para que los equipos tengan margen de migrar. Cuantos menos componentes haya, menos drift, y un sistema mas pequeno aun cabe en la cabeza de una sola persona: por eso conviene reducir la superficie con decision.

Prioriza por radio de impacto, no por lo feo que se vea algo. Un boton con drift usado en 80 pantallas importa mas que una card suelta en una pagina de ajustes. Mapea cada elemento con drift a donde sale en produccion, arregla primero los componentes compartidos de alto trafico y deja la cola larga para la auditoria programada. Asi la limpieza sigue siendo publicable, en vez de convertirse en un paron de seis semanas que nadie aprobo.

Como detectar el drift antes que los usuarios

La prevencion necesita dos controles distintos, y casi todos los equipos hacen solo uno.

Tests de regresion visual. Cazan el drift nuevo. Herramientas como Chromatic, Percy y el open source BackstopJS toman una imagen de cada componente y la comparan con una baseline en cada build, de modo que un cambio accidental en un componente compartido aparece ya en la pull request. Hace falta, pero tiene un punto ciego: detecta el cambio respecto a la ultima baseline, no la desviacion respecto a la especificacion. Si el drift ya esta en la baseline, el test lo protege sin mas.

Linting de especificacion y tokens. Caza el drift acumulado. Una regla de lint o un escaneo en CI compara lo que sale a produccion con la definicion del sistema: codigos hexadecimales a mano, espaciados fuera de escala, componentes que apuntan a valores en crudo en lugar de a tokens. La guia de Material Design es tajante: un token de componente debe apuntar a un token de sistema o de referencia, nunca a un valor hardcoded como un codigo hexadecimal. Un escaneo que corre en CI convierte ese principio en una barrera.

Los dos controles son mecanicos. La parte que de verdad aguanta es la gobernanza: un proceso de entrada definido para tokens y variantes nuevos, una revision antes de que salga la excepcion "solo por esta vez", y una propiedad que no desaparece despues del lanzamiento. El drift es el sintoma. El bucle de revision que falta es la enfermedad.

Los equipos que evitan el drift no son los que tienen mas herramientas. Son aquellos donde anadir una variante exige una conversacion, no solo un commit. Las herramientas sacan el drift a la luz. Las personas, y el bucle que acuerdan seguir, son lo que evita que vuelva.