Si 40 equipos personalizan el mismo botón, tu Design System tiene un problema (y cómo detectarlo)

Los equipos de Design Systems en contextos complejos cargan con un problema silencioso:

Nadie sabe con certeza cuánto de lo que construyen realmente impacta en producción.

Tienes documentación. Tienes componentes. Tienes governance.

Pero no tienes visibilidad.

Un día revisas 3 productos diferentes y encuentras que el mismo componente se implementó de 4 formas distintas en cada uno.

Y pasa en silencio. Sin que nadie lo vea como un problema.

Eso es la realidad de escalar un sistema en contextos con múltiples equipos autónomos.

No es caos. Es invisibilidad.

🧩 ¿Cómo medir el ROI de un Design System?


En contextos financieros complejos la situación es más complicada que en otros sectores.

No es solo que tengas múltiples productos: tienes regulaciones, auditorías, cumplimiento normativo, y presión constante por eficiencia.

Un cambio en tu sistema de diseño no es "fast and furious"; es coordinado, medido, rastreado.

Entonces, ¿cómo mides si tu sistema funciona?

Aquí viene lo importante:

🎯 ¿Por qué contar componentes no sirve?


He visto a líderes decir: "Usamos 450 instancias de nuestro botón el mes pasado."

Suena impresionante.

Significa nada.

¿Por qué?

Un botón dentro de un header que aparece en 30 páginas: ¿cuenta como 1 o 30?

Un componente copiado y pegado en 15 lugares ¿cuenta hacia tu sistema o cuenta como 15 fracasos?

Más importante: si construyes 200 componentes pero solo 15 se usan en serio...

¿Realmente tienes un sistema o tienes una biblioteca gigante que nadie mantiene?

Lo brutal es que la mayoría de equipos pasa meses midiendo números que no dicen nada.

Necesitas cambiar el enfoque.

De "frecuencia absoluta" a "amplitud de uso".

No "cuántas instancias de un componente".

Sino "cuántos equipos diferentes usan este componente."

📊 ¿Cuáles son las métricas mínimas viables?


Primer sprint (Semana 1-2):

Olvida 50 gráficos. Necesitas 4 métricas. Punto.

1️⃣ Cobertura visual: ¿Qué % de tu interfaz usa componentes DS?

2️⃣ Adopción por equipo: ¿Cuántos equipos usan el sistema?

3️⃣ Consistency score: ¿Cuántas desviaciones hay por producto?

4️⃣ Time to component: ¿Cuánto tardan los equipos en implementar un componente nuevo?

Eso. Es. Todo.

¿Cómo crear tu baseline en menos de dos horas?

  • Selecciona 3 productos reales de tu compañía.
  • Cuenta manualmente (sí, old school):

Ejemplo: "En el flow de onboarding, 7 de 10 pantallas usan componentes propios del DS.*"

  • Ese es tu baseline: 70% de cobertura en onboarding.
  • Define un objetivo realista a 90 días, por ejemplo: subirlo al 85%.
  • Calcula tu "consistency score":
  • Escoge 20 pantallas representativas (elige 3-4 flujos clave: onboarding, transferencias, pagos...).
  • Revisa visualmente y toma nota de incoherencias:
  • "Este botón tiene padding de 12px aquí, 16px allá."
  • "Este input lleva borde, en el siguiente no."
  • Si tu DS cubre solo un 65% en alta de usuario, el 35% restante es deuda visual y funcional que crecerá con cada release.
  • Registra cada desviación (ese es tu score inicial).

Truco para escalar sin volverte loco:

  • Puedes acelerar este proceso automatizando parte del análisis:
  • Sube las capturas de esas 20 pantallas a una carpeta.
  • Lanza un script sencillo (por ejemplo, en Cursor) o usa una herramienta que detecte inconsistencias visuales o a nivel de código.
  • Al final obtendrás algo así:
  • "En estas 20 pantallas encontré X desviaciones. Las más críticas son: Button padding (8 veces), Input border (6), Spacing en cards (4)."

🔥 ¿Cuál es la métrica que nadie mide pero debería?


Aquí viene lo que te hace brillar:

Cada vez que un equipo detacha o customiza un componente existente (en lugar de usarlo directo), lo registran.

Simple: un comment en el Figma o un ticket.

"Usamos Button pero con border-radius customizado porque nuestro caso de uso es diferente."

Ahora multiplica.

Si 40 equipos detachan el Button de 5 maneras diferentes = mismo problema resuelto 40 veces.

Traducción: desperdicio masivo.

Horas perdidas. Inconsistencia en producción. Deuda técnica acumulada.

Pero aquí está lo fascinante.

Cada detach que registres es un insight puro.

No es fallo de adoption.

Es fallo de diseño.

Porque ahora sabes exactamente dónde iterar.

💡 El script que lo cambia todo


Aquí tienes el copy final para explicar el escaneo por código (sin Figma) y con tu tono claro y técnico:

¿Cómo saber cuántos equipos realmente usan tu componente estándar y cuántos hacen la suya por libre?

Un script sencillo te lo da en minutos.
No toca Figma ni docs—solo código real.

Escanea automáticamente toda la base de código:
Busca importaciones del tipo:


import { Button } from 'design-system';

Cuenta cada import y lo agrupa por carpeta, equipo, o contexto (puedes mapear esto a tu monorepo o naming de proyectos).

Detecta "copias" y personalizaciones:
Localiza componentes que se llaman igual pero se redefinen localmente, o que extienden el original con estilos, props o code duplicado.
Ejemplo:


import { Button } from 'design-system';
// Creo una variante para casos especiales
const DangerButton = (props) => (

Cada caso suma como "instancia customizada".

Te saca un informe real:


Equipo Onboarding: 11 imports estándar, 2 custom 
Equipo Cuentas: 17 imports estándar, 7 custom 
Equipo Pagos: 13 imports estándar, 1 custom

Así ves, sin interpretación, qué equipos adoptan 100% el patrón y cuáles lo "rompen".

Puedes extraer extra info:
El script te lista también las props usadas, variantes más frecuentes, o props sospechosas de ser hack:



¿Qué ganas?

  • Datos accionables para saber qué componentes funcionan y cuáles invitan a custom.
  • Argumentos sólidos para priorizar refactors ("este equipo lo rompe siempre, hablemos con ellos").
  • Una visión de verdad sobre la salud y adopción de tu Design System—la métrica que de verdad importa.

Zero human effort después del setup (2 horas máximo).

🧠 Predicción de adoption antes de que falle


Aquí es donde brilla el machine learning simple (y no lo digo como AI hype).

El patrón es claro:

Si ves que componentes similares fueron detachados 3+ veces en los últimos 90 días...

El componente nuevo que vas a lanzar probablemente TAMBIÉN será detachado.

¿Por qué?

Porque hay un patrón no resuelto en ese dominio de componentes.

Entonces, antes de lanzar ese componente nuevo, puedes:

  • Detectar automáticamente el patrón de detach histórico
  • Correlacionarlo con el nuevo componente
  • Generar alertas: "Este Button tiene 8 deviaciones en el histórico. Tu nuevo componente tiene similitudes. Revisa estos 3 casos de uso antes de lanzar."

Básicamente, predices si algo va a fallar antes de que falle.

El diseñador no se frustra. El componente sale mejor.

Adoption sube automáticamente porque resolviste el problema real.

📈 Cómo crece esto sin romperse


Mes 1: 50% de cobertura en 2 productos piloto. Baseline feo pero honesto.

Mes 2: Líderes ven el problema. Asignan recursos para mejorar componentes rechazados.

Mes 3: Cobertura sube a 68%. Equipos empiezan a pedir nuevos componentes (buen signo).

Mes 4-6: Escala a otros productos. Cada producto nuevo que entra, ya empieza a 65% de cobertura porque entienden el patrón.

Mes 12: 80% de cobertura global. Sistema mantenido por 2 personas. Ahorro anual estimado: €200k-400k en horas de diseño/dev.

❌ Lo que NO hagas


No compares con otras empresas.

Cada banca es diferente. Cada contexto es diferente. Cada design system es diferente.

Aquí es donde la mayoría falla:

  • Figma dice que la mejor práctica es tener 80% de componentes reutilizables.
  • Otra banca tiene 6 diseñadores y 50 componentes.
  • Design Systems Collective dice que debería tener X métrica.
  • Olvidar preguntar a los equipos por qué detachan componentes.
  • Medir solo la frecuencia en vez de entender el patrón.
  • Comparar tu sistema con bancos que tienen realidades regulatorias y de negocio distintas.

Olvida todo.

Tu Design System es sumiso al proyecto, no al revés.

Las normas de Figma no son las tuyas.

Las mejores prácticas de otra banca no son las tuyas.

¿Por qué?

  • Porque tu contexto tiene regulaciones específicas.
  • Tiene equipos con dinámicas que no son las de otra banca.
  • Tiene historias de código y decisiones que otra empresa jamás enfrentó.

Invierte en conocer tu contexto.
Un simple log de cuándo y por qué se detacha un botón puede ahorrar miles de euros/mes en soporte y QA.

Después, diseña tus métricas desde ahí. No desde lo que otros hacen.


Mitos frecuentes en métricas DS bancarias:

  • "Más componentes = más madurez". Falso. (He visto bancos con +200 componentes que no logran ni 60% de coherencia visual.)
  • "Estándar solo importa en UX". Falso: en banca, el auditor legal usa tus pantallas como evidencia.
  • "Comparar con benchmarks de otras empresas". Falso, tu contexto manda.

🚀 Tu primer movimiento (próximos 7 días)

  • Toma 1 producto. Mira 3 flows completos.
  • Cuenta: cuántos componentes son DS, cuántos son custom.
  • Ese % es tu baseline.
  • Fija objetivo a 90 días: +15%.
  • Reúnete con 2 equipos. Pregunta: "¿Qué componente necesitarías que no existe? ¿Qué componente nuestro es un problema?"

Eso es suficiente para mover la aguja.

Key Takeaways / Acciones para responsables:

Mide equipos, no solo instancias.*

Registra cada custom, es una señal estratégica.*

Pregunta a equipos por qué adaptan.*

Ajusta el score regularmente: los productos bancarios evolucionan cada trimestre.*

Si quieres que tu equipo o tu manager vea el impacto, imprime este checklist y úsalo el próximo trimestre.

Para profundizar:

¿Cuál sería el ahorro en horas (o reducción de deuda técnica) si pudieras visualizar todas las personalizaciones que hoy están ocultas?

#DesignSystems #Banca #ProductLeadership #Métricas #Eficiencia