Construir sistemas, no páginas

Unidad de contenido — Tecnologías Web
Referencia central: Brad Frost, Atomic Design (2016)

Esta unidad se organiza en dos bloques. El primero trabaja el problema que da origen a la metodología y desarrolla en profundidad su jerarquía de cinco niveles, ilustrando cada uno con código HTML real. El segundo bloque aborda las variables de diseño como instrumento técnico para sostener el sistema, el lenguaje compartido entre diseño y desarrollo, y una apertura hacia la práctica proyectual.

Bloque 1. El problema, la metáfora y la jerarquía

1.1 El problema que da origen a la metodología

Cuando un equipo trabaja en un producto digital sin un sistema de diseño compartido, aparece de manera casi inevitable lo que la industria llama interface inconsistency: botones con colores levemente distintos según quién los diseñó, márgenes que cambian de sección en sección, tipografías que varían sin razón aparente, formularios que se comportan diferente en páginas distintas. Estas inconsistencias no son errores menores: erosionan la confianza del usuario en el producto y representan un costo operativo real, porque cada corrección debe hacerse en todos los lugares donde aparece el problema.

La respuesta habitual a este problema ha sido la guía de estilos (style guide): un documento —muchas veces un PDF— que especifica los colores corporativos, las fuentes aprobadas, las variantes de logotipo. Pero las guías de estilo tienen un límite estructural: documentan decisiones pasadas, no garantizan que el equipo las aplique en el futuro. Son estáticas y, en proyectos de cierta escala, quedan desactualizadas rápidamente.

El diseñador web estadounidense Brad Frost identificó este problema alrededor de 2013 y propuso una solución distinta: en lugar de documentar el resultado (las páginas terminadas), construir el sistema que las genera. En lugar de páginas aisladas, un conjunto de piezas reutilizables y combinables. Esa propuesta es Atomic Design.

"We're not designing pages, we're designing systems of components."

La cita, que Frost toma prestada del diseñador holandés Stephen Hay, sintetiza el cambio de paradigma: el foco pasa de la pantalla terminada al sistema de componentes que permite generar cualquier pantalla. Es un desplazamiento conceptual importante, y conviene examinarlo con cuidado antes de entrar en los aspectos técnicos.

¿Qué significa diseñar un sistema en lugar de páginas? Significa que antes de preguntarse cómo se ve la página de inicio del sitio, el equipo se pregunta: ¿cuáles son las unidades mínimas de las que está hecha cualquier página? ¿Cómo se combinan esas unidades? ¿Qué reglas gobiernan esa combinación? Solo después de responder esas preguntas se produce la pantalla final, como resultado de aplicar el sistema, no como un diseño ad hoc.

Esta lógica tiene consecuencias prácticas importantes:

• Cuando cambia una pieza del sistema (por ejemplo, el color del botón principal), ese cambio se propaga automáticamente a todas las pantallas que usan ese botón.
• Cuando el equipo necesita diseñar una pantalla nueva, no parte de cero: reutiliza las piezas existentes y solo crea lo que genuinamente es nuevo.
• Cuando un nuevo integrante se suma al equipo, puede aprender el sistema y producir interfaces consistentes sin necesidad de revisar cada pantalla existente.

1.2 La metáfora química de Brad Frost

Para explicar la jerarquía de componentes, Frost recurrió a la química. La materia está compuesta por átomos: las unidades más simples, indivisibles en condiciones ordinarias. Los átomos se combinan para formar moléculas, estructuras con propiedades distintas a las de sus partes. Las moléculas, a su vez, se organizan en estructuras más complejas.

La analogía no es perfecta —ninguna lo es— pero resulta productiva porque introduce la idea de niveles de abstracción con propiedades emergentes. Una molécula de agua (H₂O) tiene propiedades que no tiene el hidrógeno ni el oxígeno por separado: la función emerge de la combinación. Del mismo modo, un campo de búsqueda (label + input + button) tiene una función que ninguno de esos elementos tiene individualmente.

Frost traslada esta lógica a la interfaz de usuario y define cinco niveles jerárquicos: átomos, moléculas, organismos, plantillas y páginas. Los dos primeros toman el nombre directamente de la química; los tres restantes son términos propios del diseño y la comunicación visual.

Es importante notar que Frost no propone que los diseñadores "piensen como químicos": propone que usen la metáfora como herramienta pedagógica para comunicar una idea estructural. La jerarquía de niveles es lo que importa; los nombres son vehículos para recordarla y compartirla.

1.3 Nivel 1: Átomos

Los átomos son las unidades mínimas e indivisibles de la interfaz. Son los elementos HTML más básicos: un botón (<button>), un campo de texto (<input>), una etiqueta (<label>), un enlace (<a>), un encabezado (<h1>), un ícono. No se pueden descomponer en partes más simples sin perder su función o su identidad como componente.

Frost incluye en los átomos también las decisiones de estilo más fundamentales: los colores del sistema, los tamaños tipográficos, los valores de espaciado. Aunque estos no son elementos HTML, son las "partículas" que dan forma a todos los demás niveles. Cuando se dice que un botón es un átomo, se asume que ese botón tiene propiedades definidas: un color de fondo, un tamaño de fuente, un espaciado interior. Esas propiedades son, en sí mismas, átomos del sistema.

Una observación que Frost hace explícita en su artículo "From Template to Atoms" (2016) es que los átomos son el nivel más abstracto y, paradójicamente, el más difícil de usar de manera aislada en un diseño real. Un botón solo, fuera de contexto, no comunica mucho. Su función se vuelve evidente cuando se combina con otros elementos. Esto no los hace menos importantes: al contrario, la consistencia del sistema depende de que los átomos estén bien definidos.

En términos de HTML y CSS, los átomos corresponden generalmente a elementos individuales con sus estilos asociados:

/* Átomo: botón primario */
button.btn-primario {
  background-color: #D96B4F;
  color: #ffffff;
  font-size: 16px;
  padding: 8px 16px;
  border: none;
  border-radius: 4px;
  cursor: pointer;
}

/* Átomo: campo de texto */
input[type="text"] {
  border: 1px solid #cccccc;
  font-size: 16px;
  padding: 8px 12px;
  border-radius: 4px;
  width: 100%;
}

1.4 Nivel 2: Moléculas

Las moléculas son combinaciones simples de átomos que forman una unidad funcional con un propósito específico. Lo decisivo en una molécula no es la cantidad de elementos que la componen, sino el hecho de que juntos tienen una función que ninguno tiene por separado.

El ejemplo más citado en la literatura es la barra de búsqueda: un <label>, un <input type="text"> y un <button>. Cada uno de estos elementos existe como átomo independiente. Pero cuando se combinan en una estructura HTML con un propósito compartido —buscar contenido— forman una molécula. El <div> que los contiene actúa como el "enlace químico" que los mantiene juntos.

Otro ejemplo: una tarjeta de producto en un e-commerce puede ser una molécula formada por una imagen (<img>), un nombre (<h3>), un precio (<span>) y un botón de compra (<button>). Ninguno de esos elementos comunica "producto a la venta" individualmente; la molécula sí.

En términos de CSS, las moléculas suelen necesitar estilos de composición: reglas que gobiernan cómo se relacionan espacialmente sus átomos internos. Flexbox y Grid son las herramientas más habituales para esto:

/* Molécula: barra de búsqueda */
.busqueda {
  display: flex;
  align-items: center;
  gap: 8px;
}

.busqueda label {
  font-size: 14px;
  color: #555555;
}

.busqueda input {
  flex: 1;          /* ocupa el espacio disponible */
}

.busqueda button {
  flex-shrink: 0;  /* mantiene su tamaño fijo */
}

1.5 Nivel 3: Organismos

Los organismos son secciones de interfaz relativamente independientes, compuestas por moléculas y/o átomos. A diferencia de las moléculas, los organismos son suficientemente complejos como para tener sentido por sí mismos: pueden existir y funcionar de manera autónoma, sin depender de un contexto específico para ser comprensibles.

El ejemplo más claro es el encabezado de un sitio web (<header>): puede contener el logotipo (átomo), la navegación principal (molécula: lista de enlaces), y la barra de búsqueda (molécula ya definida). Juntos forman un bloque autónomo que puede trasladarse de una página a otra sin perder coherencia.

Otros ejemplos de organismos habituales:

• El pie de página (<footer>): logo + links legales + redes sociales + formulario de newsletter.
• Una sección de artículos destacados: encabezado de sección + grilla de tarjetas de artículo.
• Un sidebar: buscador + categorías + artículos recientes.
• Un formulario de contacto completo: varios campos (moléculas) + botón de envío + texto legal.

La distinción entre molécula y organismo puede ser sutil y depende del contexto. Una navegación puede ser una molécula (una lista de enlaces) o un organismo (si incluye submenús, íconos, buscador integrado). Lo que define el nivel no es la cantidad de elementos, sino el grado de autonomía funcional del componente.

/* Organismo: encabezado del sitio */
header.encabezado-sitio {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 16px 32px;
  background-color: #1C1C2E;
}

/* Átomos y moléculas dentro del organismo */
.encabezado-sitio .logo {
  width: 120px;
}

.encabezado-sitio nav {
  /* molécula de navegación */
  display: flex;
  gap: 24px;
  list-style: none;
}

.encabezado-sitio .busqueda {
  /* molécula de búsqueda ya definida */
  width: 240px;
}

1.6 Nivel 4: Plantillas

Las plantillas son el primer nivel que ya no toma su nombre de la química. Se trata de la estructura de una página: el esqueleto que organiza los organismos en un layout coherente, pero sin contenido real. Una plantilla muestra dónde va cada cosa, no qué es esa cosa.

En el proceso de diseño, las plantillas equivalen a lo que en diseño editorial se llama una maqueta o en desarrollo web se llama un wireframe funcional: una estructura con las proporciones y relaciones espaciales definidas, pero con texto de relleno (lorem ipsum) e imágenes de marcador de posición.

La utilidad de distinguir plantillas de páginas es doble. Por un lado, permite reutilizar la misma estructura para múltiples contenidos distintos: un mismo template de "artículo" puede generar cientos de páginas con contenidos diferentes. Por otro lado, obliga al equipo a pensar en el sistema antes que en el contenido específico: la estructura es primero, el contenido viene después.

En HTML, una plantilla puede verse así:

<!-- template: artículo-con-sidebar -->
<html>
<head>
  <link rel="stylesheet" href="../atoms/tokens.css"/>
  <link rel="stylesheet" href="templates/articulo-con-sidebar.css"/>
</head>
<body>

  <header class="encabezado-sitio">
    <!-- organismo: encabezado -->
  </header>

  <main class="layout-con-sidebar">
    <article class="contenido-principal">
      <!-- título, imagen, cuerpo del artículo -->
    </article>
    <aside class="sidebar">
      <!-- organismo: sidebar -->
    </aside>
  </main>

  <footer class="pie-sitio">
    <!-- organismo: footer -->
  </footer>

</body>
</html>

Notar que la plantilla referencia organismos ya definidos, no los repite. La reutilización es una consecuencia directa de haber construido el sistema desde abajo hacia arriba.

1.7 Nivel 5: Páginas

Las páginas son instancias específicas de una plantilla con contenido real. Es el nivel donde el sistema toma contacto con la realidad: textos definitivos, imágenes reales, datos de usuarios o de base de datos. Es también el nivel donde el diseño se valida: ¿el sistema funciona con contenido real? ¿Resiste un título muy largo? ¿Una imagen de proporciones distintas? ¿Un artículo sin imagen destacada?

Frost subraya que las páginas son el nivel más concreto y, al mismo tiempo, el menos importante para el sistema en sí. Lo valioso es la plantilla, los organismos, las moléculas y los átomos. Las páginas son la consecuencia de aplicar correctamente todos los niveles anteriores.

Esta distinción tiene implicaciones directas en el trabajo diario:

• Si hay que corregir el color del encabezado, se modifica el átomo o la variable de diseño correspondiente, no cada página individualmente.
• Si hay que añadir una nueva sección a todas las páginas del sitio, se modifica la plantilla, no cada archivo HTML por separado.
• Si hay que crear una nueva sección del sitio con la misma estructura, se reutiliza la plantilla y se cambia el contenido.

Bloque 2. Variables de diseño, lenguaje compartido y apertura práctica

2.1 El problema del valor sin nombre

Supongamos que el color principal de una marca es #D96B4F. Sin un sistema, ese valor hexadecimal aparece escrito directamente en el CSS cada vez que se necesita: en el botón principal, en los encabezados activos, en los íconos destacados, en los bordes de las tarjetas. Si en algún momento el cliente decide cambiar ese color —situación completamente habitual en proyectos reales—, el desarrollador debe buscarlo y reemplazarlo en cada lugar donde aparece. No solo es tedioso: es propenso a errores. Es fácil olvidarse de una instancia y terminar con un botón que no coincide con el nuevo color de marca.

El problema no es solo práctico: es también semántico. El valor #D96B4F no comunica nada sobre su función en el sistema. Es un número. No sabemos si es el color primario, el color de alerta, el color de un componente específico. Un valor sin nombre es una decisión sin contexto.

La solución es asignarle un nombre que comunique su rol: variable de diseño.

2.2 Variables de diseño: decisiones codificadas

Una variable de diseño es una decisión de diseño almacenada como variable nombrada en el código. En lugar de escribir el valor directamente, se escribe el nombre de la variable; ese nombre comunica la intención detrás del valor.

En la industria del diseño de software, estas variables suelen llamarse design tokens (término acuñado por Jina Anne en Salesforce alrededor de 2014). Preferimos aquí la traducción directa variable de diseño porque hace visible la idea central: son variables —en el sentido informático del término— cuyo contenido es una decisión de diseño.

En CSS moderno, las variables de diseño se implementan mediante las Custom Properties (Propiedades Personalizadas), introducidas en CSS3. Se declaran en el selector :root para que estén disponibles en todo el documento, y se accede a ellas mediante la función var():

/* ─── Variables de diseño — declaración global ─── */

:root {

  /* === COLORES === */
  --color-primario:     #D96B4F;   /* acción, marca */
  --color-secundario:   #3D405B;   /* encabezados, estructura */
  --color-fondo:        #F7F4EF;   /* fondo global */
  --color-texto:        #1C1C2E;   /* texto principal */
  --color-texto-suave:  #6B6B8A;   /* texto secundario */

  /* === TIPOGRAFÍA === */
  --fuente-principal:   Georgia, serif;
  --fuente-interfaz:    system-ui, sans-serif;
  --fuente-codigo:      'Courier New', monospace;

  --tamaño-xs:  12px;
  --tamaño-sm:  14px;
  --tamaño-base:16px;
  --tamaño-lg:  24px;
  --tamaño-xl:  32px;

  /* === ESPACIADO — regla del 8 === */
  --espacio-xs:  4px;
  --espacio-sm:  8px;
  --espacio-md: 16px;
  --espacio-lg: 32px;
  --espacio-xl: 64px;

  /* === FORMAS === */
  --radio-sm: 4px;
  --radio-md: 8px;
  --radio-lg: 16px;
}

/* ─── Uso en los átomos del sistema ─── */

.btn-primario {
  background-color: var(--color-primario);
  color:            #ffffff;
  font-size:        var(--tamaño-base);
  padding:          var(--espacio-sm) var(--espacio-md);
  border-radius:    var(--radio-sm);
  border:           none;
  cursor:           pointer;
}

body {
  font-family:    var(--fuente-interfaz);
  font-size:      var(--tamaño-base);
  color:          var(--color-texto);
  background:     var(--color-fondo);
  line-height:    1.7;
}

Con este sistema, si el color primario de la marca cambia, se modifica una sola línea —la declaración de --color-primario en el :root— y el cambio se propaga automáticamente a todos los componentes que usan esa variable: botones, encabezados activos, bordes destacados, íconos.

2.3 Categorías de variables de diseño

Las variables de diseño se agrupan habitualmente en cuatro categorías:

1. Color. Paleta completa del sistema: colores de fondo, texto, acción, estado (éxito, error, advertencia), componentes específicos. Es la categoría más extensa y la que más impacta en la identidad visual.
2. Tipografía. Familias de fuentes, tamaños, alturas de línea, pesos. Definen la jerarquía visual del texto en todo el sistema.
3. Espaciado. Valores de padding, margin y gap que regulan las distancias entre y dentro de los componentes. La regla del 8 es la convención más extendida: todos los valores son múltiplos de 8 (4, 8, 16, 32, 64, 128 px). El 4 aparece como excepción para casos de ajuste fino.
4. Forma. Radios de borde (border-radius), sombras (box-shadow), bordes. Definen el carácter visual de los componentes: una interfaz con border-radius: 0 comunica algo muy distinto a una con border-radius: 24px.

Esta clasificación no es la única posible. Algunos sistemas incluyen también variables de animación (duración, curva de aceleración), de icono (tamaños estándar), o de layout (anchos máximos, número de columnas de grilla). Lo importante es que todas las decisiones repetibles del diseño estén nombradas como variables.

La siguiente tabla muestra ejemplos concretos de variables de diseño organizadas por categoría:

2.4 La regla del 8: por qué el espaciado no es arbitrario

La convención de usar múltiplos de 8 para los valores de espaciado responde a una razón técnica concreta: las resoluciones de pantalla más comunes son divisibles por 8 sin resto. Las pantallas de 1920px, 1440px, 1280px, 768px y 360px se dividen en columnas y regiones que caben exactamente en una grilla de 8px, lo que genera alineaciones precisas sin fracciones de pixel.

Pero hay también una razón de diseño: si todos los espaciados del sistema son múltiplos de 8, la grilla visual del sistema es consistente de manera automática. No hay que decidir caso por caso si el padding interno de un botón es 11px o 13px: ambos quiebran la armonía de la grilla. El valor correcto es 8px o 16px, y la respuesta es obvia.

Equipos como los de Google Material Design y Apple Human Interface Guidelines usan variantes de esta convención. Esto no la convierte en una verdad absoluta, pero sí en una práctica muy extendida y probada en producción.

2.5 El lenguaje compartido: diseño y desarrollo hablando lo mismo

Uno de los problemas más comunes en equipos de desarrollo de productos digitales es el handoff: el momento en que el diseñador entrega su trabajo al desarrollador front-end para que lo implemente. Sin un sistema compartido, este momento está lleno de ambigüedades: ¿qué exactamente significa "el botón azul oscuro del encabezado"? ¿Es el mismo que aparece en el formulario de contacto, o es uno diferente?

Atomic Design resuelve este problema al establecer un vocabulario compartido. Cuando diseñador y desarrollador acuerdan que "molécula de búsqueda" refiere a la combinación específica de label + input + button con sus estilos definidos, ese nombre elimina la ambigüedad. No hace falta describir el componente cada vez: alcanza con nombrarlo.

Este lenguaje compartido tiene una implicación adicional: hace posible la documentación viva. Si el sistema de diseño está construido sobre los mismos nombres que usa el código, la documentación de un componente puede incluir tanto su representación visual como su código CSS y HTML correspondiente. Herramientas como Storybook (para JavaScript) o Pattern Lab (del propio Frost) se basan en esta idea.

2.6 Estructura de archivos: el sistema visible en la carpeta

Una consecuencia práctica de Atomic Design es que la estructura de archivos del proyecto puede —y conviene que— refleje la jerarquía de niveles. Esto no es una regla estricta de la metodología, sino una práctica que hace el sistema legible para todo el equipo: al abrir la carpeta del proyecto, la arquitectura del sistema es inmediatamente visible.

/* Estructura de carpetas siguiendo Atomic Design */

src/
  atoms/
    tokens.css           ← variables de diseño (:root)
    button.css
    input.css
    typography.css
    icons.css

  molecules/
    search-bar.css       ← label + input + button
    nav-item.css         ← enlace + ícono
    product-card.css     ← imagen + título + precio + botón

  organisms/
    header.css           ← logo + nav + search-bar
    footer.css
    hero-section.css
    article-sidebar.css

  templates/
    main-layout.css      ← layout base con header y footer
    article-layout.css   ← contenido principal + sidebar

  pages/
    index.html
    about.html
    article-01.html
    article-02.html

Algunos puntos clave sobre esta estructura:

• El archivo tokens.css está en atoms/ porque las variables de diseño son el nivel más fundamental del sistema. Todos los demás archivos CSS deben importarlo.
• Los archivos de moléculas y organismos no repiten los estilos de los átomos: los heredan. El CSS de search-bar.css solo define las reglas de composición de la molécula; los estilos del <button> ya están en button.css.
• Las páginas HTML importan solo los archivos CSS que necesitan, lo que mantiene el peso de la carga bajo control.

2.7 Alcances, límites y críticas

Atomic Design ha tenido una adopción muy amplia en la industria del diseño de interfaces, pero no está exento de críticas y limitaciones que conviene conocer para hacer un uso reflexivo de la metodología.

Sobre la rigidez de la jerarquía: en proyectos reales, la distinción entre molécula y organismo puede ser genuinamente difícil. Un menú de navegación, ¿es una molécula (lista de enlaces) o un organismo (si incluye submenús y logo)? Frost reconoce esta ambigüedad en su propio texto y señala que la jerarquía es una herramienta mental, no una ley. Lo que importa es que el equipo tenga claridad sobre qué es cada componente, independientemente del nivel exacto que se le asigne.

Sobre la escalabilidad real: el valor de Atomic Design se vuelve evidente en proyectos de mediana y gran escala, con múltiples páginas y equipos de trabajo. En proyectos pequeños y de una sola persona, puede introducir una complejidad organizativa innecesaria. Como cualquier metodología, debe evaluarse en función del contexto.

Sobre la relación diseño-desarrollo: la metodología asume cierta simetría entre el trabajo del diseñador y el del desarrollador: ambos hablarían los mismos niveles y usarían los mismos nombres. En la práctica, esto requiere un esfuerzo deliberado de alineación que no siempre ocurre por default.

Sobre la herramienta vs. el sistema: es posible usar Figma, Sketch o Adobe XD organizando los componentes en capas llamadas "átomos" y "moléculas" sin que eso implique haber construido un sistema de diseño real. El riesgo es usar el vocabulario sin adoptar la lógica que lo sustenta. Frost insiste en que Atomic Design no es una convención de nomenclatura: es una forma de pensar el diseño como sistema.

2.8 Relación con otras metodologías de CSS

Atomic Design opera a un nivel de abstracción mayor que las metodologías de escritura de CSS. No las reemplaza: las complementa. Es útil conocer cómo se relaciona con las más extendidas:

• BEM (Block, Element, Modifier): es una convención de nomenclatura de clases CSS que define cómo nombrar los selectores de componentes (.bloque__elemento--modificador). Es compatible con Atomic Design: un componente puede ser un organismo en términos atómicos y usar nomenclatura BEM en su CSS.
• MaintainableCSS (Adam Silver, 2016): propone principios para escribir CSS modular, predecible y escalable, con foco en el aislamiento de componentes. Comparte con Atomic Design la preocupación por la mantenibilidad, pero opera en el nivel técnico del CSS, no en el nivel conceptual del sistema de diseño.
• SMACSS (Jonathan Snook): categoriza las reglas CSS en Base, Layout, Module, State y Theme. Las categorías de Módulo y Layout tienen correspondencia parcial con los niveles atómicos.
• Utility-first CSS / Tailwind: propone escribir estilos directamente en el HTML mediante clases de utilidad. Es una filosofía distinta a la de Atomic Design, aunque ambas buscan consistencia y reutilización. Pueden coexistir si se usan con criterio.