Skip to main content

Patrones avanzados de diseño y escalabilidad

Escalar no es añadir más componentes, es reducir entropía​

Cuando un sistema crece, el problema ya no es “cómo se ve”. Es:

  • cuántas decisiones hay,
  • quién puede tomarlas,
  • cuándo se rompen sin darse cuenta.

Un sistema que escala no evita la complejidad. La canaliza.

Escalar es impedir que el caos vuelva a aparecer.

De componentes a primitivos de diseño​

En sistemas avanzados, los componentes dejan de ser la unidad principal. La unidad real pasa a ser el patrón. Ejemplos de primitivos:

  • Layouts (stack, cluster, sidebar)
  • Estados (empty, loading, error)
  • Acciones (primary, secondary, destructive)
  • Feedback (toast, inline hint)

Los componentes consumen estos primitivos. No los reinventan.

Variantes como espacio de diseño, no como condicionales​

En sistemas maduros:

  • Las variantes están limitadas
  • Las combinaciones inválidas no existen
  • El sistema “dice no” por defecto

Esto reduce:

  • deuda visual,
  • explosión combinatoria,
  • errores humanos.

Un sistema fuerte restringe más de lo que permite.

Políticas de diseño: reglas explícitas​

Un patrón avanzado no vive solo en código. Vive en políticas. Ejemplos:

  • “No existen botones pequeños destructivos”
  • “Todo modal tiene una acción primaria clara”
  • “El estado loading nunca bloquea navegación”

Estas reglas:

  • No son opiniones
  • Son contratos

Y se reflejan en código.

Escalabilidad ≠ reutilización ciega​

Reutilizar no es copiar. Reutilizar es consumir una decisión central. Señales de mala escalabilidad:

  • Variantes que existen “por si acaso”
  • Componentes genéricos que nadie entiende
  • Overrides constantes
  • Documentación desalineada

Un sistema sano:

  • Tiene menos componentes
  • Pero más claros
  • Y más difíciles de usar mal

Diseño impulsado por estados, no por pantallas​

Las pantallas cambian. Los estados se repiten. Estados universales:

  • Loading
  • Empty
  • Error
  • Success
  • Partial data

Un sistema escalable:

  • Define estos estados una vez
  • Los reutiliza en todas partes
  • Los anima y comunica igual

Composición jerárquica y responsabilidad​

A gran escala:

  • No todos los componentes están al mismo nivel
  • Hay jerarquía de responsabilidad

Ejemplo:

  • Primitivos → patrones → componentes → páginas

Romper esta jerarquía genera:

  • dependencias circulares,
  • estilos frágiles,
  • imposibilidad de refactor.

Tokens como API pública del diseño​

En este punto, los tokens dejan de ser “colores y tamaños”. Son una API estable.

Cambiar un token:

  • Tiene impacto global
  • Debe ser deliberado
  • Debe ser versionado

Un token sin dueño es deuda.

Documentación viva como parte del sistema​

Un sistema avanzado no se recuerda, se consulta. Documentación efectiva:

  • Ejemplos reales
  • Casos límite
  • Uso correcto e incorrecto
  • Evolución histórica

Si no se puede explicar, no se puede escalar.

Gobernanza: quién puede cambiar qué​

Escalar implica decisiones organizativas:

  • Quién añade tokens
  • Quién crea patrones nuevos
  • Quién aprueba cambios estructurales
  • Cómo se gestionan excepciones

Sin gobernanza:

  • El sistema se degrada lentamente
  • Nadie es culpable
  • Todos sufren

Antipatrones de sistemas grandes​

  • “Un componente para cada caso”
  • “Un token por pantalla”
  • “Añadamos una variante más”
  • “Esto solo lo usamos aquí”
  • “Luego lo limpiamos”

Estos son los síntomas antes del colapso.

Señales de madurez del sistema​

  • El sistema impide errores comunes
  • El onboarding es rápido
  • Los cambios grandes son seguros
  • El diseño se mantiene coherente
  • La velocidad aumenta con el tiempo

Escalar es decir no​

La habilidad más difícil:

  • rechazar casos,
  • eliminar opciones,
  • simplificar sin perder potencia.

Un sistema avanzado no impresiona por lo que hace,

sino por lo que no permite hacer.