Design Systems

El objetivo no es diseñar páginas individuales sino un sistema de componentes que genera páginas. Cada vez que construyas algo, pregunta "como funciona este patrón en otros contextos?", no solo "como se ve aquí?". Un sistema bien construido escala porque las piezas son independientes del contexto donde se usan: un Button funciona igual en el checkout que en el onboarding.

Los atomos (input, label, botón) forman moleculas (search form). Las moleculas forman organismos (header). Los organismos forman templates (layout). Los templates con contenido real son pages. Atomic Design no es un proceso lineal: se trabajan los 5 niveles simultaneamente, pero la composición siempre fluye de lo simple a lo complejo. Sin esta jerarquía, los equipos terminan con listas planas de componentes donde nadie sabe que compone que, duplicando lógica y rompiendo consistencia.

Nombrar componentes por estructura, no por contenido ni ubicación. Cuando el nombre refleja el contenido actual ("HeroHomepage", "PricingCard"), cualquier cambio de contexto lo vuelve obsoleto y obliga a renombrar o duplicar. Un nombre que describe la forma ("MediaBlock", "Card", "Grid") permite reutilizar el componente en cualquier página sin fricción. La portabilidad del nombre es la portabilidad del componente.

Antes de crear un componente nuevo, buscar en el sistema de diseño si ya existe uno que resuelva la necesidad. Si no encaja al 100%, evaluar si se puede extender con una prop o variante. Esta restricción saludable previene la proliferación de componentes duplicados que divergen silenciosamente, generan inconsistencias visuales y multiplican el costo de mantenimiento. Agregar al sistema solo cuando se confirma que servira a multiples contextos.

Antes de construir un design system, auditar lo que ya existe en el producto. Capturar cada patrón UI único, categorizar por tipo (botones, cards, forms, navs) y documentar las variantes reales. Este inventario expone inconsistencias, duplicados y nombramientos divergentes que informan las decisiones del sistema. Sin el, se inventa un DS arbitrario que no refleja la realidad del producto y multiplica la deuda visual.

Nunca diseñar solo para el contenido ideal. Un componente debe funcionar con datos perfectos, datos ausentes y datos extremos. Probar los tres escenarios revela fragilidades que el "happy path" del mockup oculta: nombres que desbordan, avatares que no cargan, campos vacios sin fallback. Documentar cada variación como pseudo-pattern garantiza que el componente no se rompa en producción.

Si un componente se rompe a nivel de página (con contenido real), el fix debe volver al atomo o molecula origen. El flujo es bidireccional: la página detecta el problema, el atomo lo corrige, y la corrección propaga automáticamente a todas las páginas que lo consumen. Parchar solo a nivel de página crea divergencia permanente entre el sistema y las instancias.

Un design system no es un PDF que se exporta y se olvida. Es infraestructura viva: versionada en Git, validada por CI, con metricas de adopción reales. Cuando el sistema es un artefacto estático, diverge del producto en semanas y los desarrolladores lo ignoran porque saben que esta desactualizado. Cuando es un organismo vivo con pipeline, changelog y telemetria de uso, se convierte en la fuente de verdad que todo el equipo respeta.

Entre más fluido sea un componente, más resiliente y versatil. Diseñar solo para 3 breakpoints (mobile, tablet, desktop) deja "valles" entre cada salto donde el layout se rompe. Usar unidades relativas, clamp(), min(), max() y container queries permite que el componente se adapte a cualquier ancho sin necesidad de puntos de quiebre explicitos. Testear siempre en viewports aleatorios, no solo en los clasicos 320, 768 y 1024.

Cada molecula (grupo simple de atomos) debe hacer UNA cosa y hacerla bien. Un SearchInput busca, un FilterSelect filtra, un SortToggle ordena. Cuando una molecula acumula multiples responsabilidades se convierte en un god-component: imposible de testear en aislamiento, imposible de reusar parcialmente, y cualquier cambio en una responsabilidad arriesga romper las demas. La solución es descomponer en moleculas de responsabilidad única y componer en un organismo que las orqueste sin acoplarlas.