He trabajado con sistemas que tenían más de 100 componentes.
Lo curioso es que, llegado un punto, nadie del equipo sabía realmente cuál era el correcto para cada contexto.
Las discusiones eternas, los tickets que se traspapelaban, los bloqueos en legal por falta de trazabilidad, y los desarrolladores perdiendo la concentración cada dos por tres...
El resultado era claro: el sistema no era invisible.
Era ruidoso. Y caro.
La infraestructura bien diseñada desaparece.
Como la fontanería de una ciudad: solo la notas cuando falla.
❌ El problema que nadie admite:
La mayoría de Design Systems en banca son catálogos de UI con manual de marca.Bonitos ✨
Documentados 📚
Inútiles 🗑️
Porque no resuelven el problema real:
- Equipos perdiendo días debatiendo qué botón usar
- Developers perdiendo contexto cada dos tickets
- Legal bloqueando cambios por falta de trazabilidad
- Nadie midiendo la deuda invisible
Ese tiempo perdido recuperando el foco tras cada interrupción.
No lo ves en dashboards.
Pero es lo que destruye sprints.
✅ Cómo se construye un sistema invisible:
1️⃣ Núcleo pequeño e innegociable
10-15 componentes core.
No 146.
El resto son variantes o composiciones.
¿Por qué importa?
- Si tienes 146 componentes, seguro tienes 12 botones, 8 inputs, 6 date pickers...
- Cada equipo usará uno distinto, nadie sabrá cuál actualizar, y la deuda técnica crece a escondidas.
- Cuando quieres cambiar un comportamiento global, acabas tocando 10 archivos y cruzando los dedos para que nada rompa en producción.
2️⃣ Variaciones regionales controladas
El problema típico en banca:
Tienes un formulario de pago.
España necesita mostrar un disclaimer legal específico.
Alemania necesita un orden diferente de campos por regulación.
Francia necesita traducción + formato de número distinto.
La trampa:
Cada equipo crea su propia versión del componente.
Resultado: 15 variantes del mismo formulario.
Todas ligeramente diferentes.
Todas requieren mantenimiento separado.
Fork hell.
Cómo lo resuelve Stripe (y cómo deberías resolverlo tú):
Stripe tiene un solo componente de pago que funciona en 40+ países.
¿Cómo?
Las diferencias viven en configuración, no en código:
{
"ES": {
"legalDisclaimer": "Texto específico español",
"fieldOrder": ["email", "card", "name"],
"dateFormat": "DD/MM/YYYY"
},
"DE": {
"legalDisclaimer": "Gesetzlicher Hinweis",
"fieldOrder": ["name", "card", "email"],
"dateFormat": "DD.MM.YYYY"
}
}
El componente es el mismo.
La lógica es la misma.
Solo cambia la configuración.
Actualizas el JSON -> se propaga a todos los mercados.
Cero forks.
Otros ejemplos de lo que Stripe hace bien:
✓ Validación IBAN en tiempo real: No esperas días para saber que un formato es incorrecto. Lo sabes mientras escribes.
✓ Gestión de errores regulados: Mensajes claros con códigos específicos. Legal aprueba templates una vez, no cada pantalla.
✓ Autenticación fuerte (SCA): El sistema detecta automáticamente cuándo es necesario por regulación y lo muestra solo entonces.
La lección:
Convierten complejidad regulatoria en ventaja competitiva.
No es magia. Es diseño de infraestructura.
Sistemas que son invisibles pero imprescindibles.
Que priorizan operatividad por delante de estética.
3️⃣ Validación automática integrada
Accesibilidad, trazabilidad, consistencia.
Lo verifica el sistema. No la buena voluntad.
¿Por qué importa?
Porque si la validación depende de que alguien recuerde revisar, tarde o temprano falla.
Accesibilidad:
Tests automáticos de contraste, jerarquía de encabezados, navegación por teclado.
Si un componente no cumple WCAG AA, no pasa a producción. Automáticamente.
Y esto no es opcional:
La Directiva Europea de Accesibilidad (European Accessibility Act) entra en vigor en junio 2025.
Las apps de banca están obligadas a cumplir WCAG 2.1 nivel AA.
No es recomendación. Es ley. Con multas.
Si tu validación de accesibilidad es manual, ya vas tarde.
4️⃣ Source of truth interna
No en Figma.
No en herramientas de terceros que controlan tus costes.
Hablemos de números reales:
Equipo típico en banca: 100 developers + 20 UX
Coste Figma en 2019:
- Professional: €12/editor/mes
- 20 editores UX = €240/mes = €2,880/año
- Viewers gratis para developers
Coste Figma en 2024:
- Professional: €15/editor/mes (subida 25%)
- Organization: muchas empresas necesitan este plan ahora
- Organization: €45/editor/mes
- 20 editores = €900/mes = €10,800/año
Pero aquí viene el problema:
Ahora Figma cobra por "viewer seats" en planes Enterprise para acceso completo a bibliotecas compartidas.
Enterprise plan (el que realmente necesitas para gobernanza):
- Precio estimado: €75-100/seat/mes
- 120 usuarios (20 UX + 100 devs que necesitan acceso) = €9,000-12,000/mes
- = €108,000-144,000/año
4,000% de aumento.
Y no controlas:
- Cuándo suben precios
- Qué features nuevas te obligan a pagar más
- Si mañana deciden cambiar el modelo de licencias
El verdadero riesgo no es solo el dinero, sino que tu gobernanza dependa de decisiones externas. Por eso la fuente de verdad debe ser interna y controlada por tu organización.
¿Por qué importa tanto?
Porque necesitas algo que:
- Para Product Managers:
Cuando un Director Financiero pregunta "¿por qué este copy funciona mejor?", no puedes responder "está en un archivo de Figma que alguien movió de carpeta".
Necesitas datos reales, versioning claro, histórico trazable.
Mostrar qué se aprobó, cuándo, por quién, y qué resultados dio.
- Para Desarrollo:
Si la source of truth cambia cada semana porque alguien actualizó Figma sin avisar, los developers dejan de confiar.
Documentación interna, versionada y sincronizada con el código elimina ambigüedad.
Sin debates. Sin bloqueos.
- Para Legal:
Cuando reguladores preguntan "¿qué mostraban exactamente hace 6 meses?", no puedes depender del histórico de Figma.
Necesitas un sistema inmutable.
Que sobreviva cambios de herramientas, precios o políticas externas.
Que responda auditorías sin colapsar al equipo.
📊 La métrica que importa:
No son las historias cerradas.No es la "adopción del DS".
Cada minuto perdido recuperando contexto es deuda silenciosa.
La que acaba con proyectos sin que nadie la vea venir.
🔄 Los rituales que mantienen el sistema vivo:
-> Demos de aprendizajes, no solo de featuresQué funcionó, qué falló, qué cambió. No es show & tell, es retrospectiva honesta.
-> Decisiones documentadas que se usan de verdad
Un ADR (registro de decisión) no es un PDF que nadie vuelve a abrir.
Es responder "¿por qué lo hicimos así?" sin necesidad de reuniones.
Cuando alguien nuevo pregunta, hay un documento claro que explica:
- Qué decidimos
- Por qué lo decidimos
- Qué alternativas consideramos
Y está vinculado al código, no enterrado en Confluence.
-> Mapas de deuda técnica priorizados por coste real
No por urgencia política. Por cuánto duele mantenerlo.
Liderar un DS no es "entregar más rápido".
Es:
- Alinear incentivos entre equipos
- Negociar excepciones con fecha de caducidad
- Reducir deuda en silencio, sin ruido
El mejor líder de sistema es el que menos se nota.
Porque el sistema funciona solo.
🎯 Si el sistema se ve, interrumpe.
Si ayuda, desaparece.💬 Preguntas para líderes de sistemas:
¿Qué métrica usas para detectar fragmentación?
¿Dónde vive tu fuente de verdad?
¿Cuánto pierdes cada vez que tu equipo se desvía del flujo por ambigüedades?
👇 Comparte en comentarios 👇
#DesignSystems #EnterpriseDesign #ProductLeadership #Banking #Governance