Diseño escalable en WordPress: bloques, patrones, plantillas y estilos

Una web bien diseñada para WordPress tiene que estar preparada para crecer. Si está bien planteada, seguirá siendo visualmente coherente cuando se publican páginas nuevas o cuando se actualizan los contenidos.

Si no diseñamos una web escalable desde el principio, es fácil que se vaya deteriorando a medida que la actualicemos. Sin un sistema claro, lo normal es que se vayan acumulando excepciones que, aunque parecen inofensivas en el momento, pasado un tiempo provocarán que se rompa el diseño de la web.

Algunas de las más habituales son:

• Copiar una sección, modificarla con pequeños cambios y pegarla en otra página.
• Cambiar el tamaño de letra de los títulos sin seguir una regla común, por ejemplo, cambiar el tamaño de un título concreto porque es demasiado largo y no cabe en el espacio reservado.
• Asignar colores a los elementos sin un criterio, por ejemplo, ponerle un color diferente a una llamada a la acción porque combina mejor con la imagen destacada.
• Crear versiones de patrones sin criterio, por ejemplo, crear cinco versiones de patrones parecidas que nadie sabe en qué se diferencian.

Mantener un sitio así se convierte en una pesadilla, porque cualquier cambio exige revisar página por página y corregir decenas de excepciones.

Esto es especialmente importante cuando usamos IA para crear o implementar una web.

Si no le damos instrucciones claras sobre módulos reutilizables, patrones, variantes, estilos globales y límites de edición, la IA generará páginas que no estarán preparadas para crecer. Podrá parecer que las páginas son correctas visualmente, pero estarán llenas de decisiones aisladas que son muy difíciles de mantener.

Diseñar para que el sitio escale consiste en crear una base lo suficientemente clara como para que las decisiones futuras no se tomen desde cero cada vez. Esa base incluye:

• Pensar en módulos reutilizables en lugar de páginas únicas y evitar las excepciones aisladas.
• Diseñar patrones de bloques bien documentados para quienes van a editar la web y que se puedan insertar fácilmente.
• Definir las plantillas necesarias para las vistas dinámicas del sitio: páginas, entradas, archivos, búsquedas, errores 404…
• Definir estilos globales, como tipografía, espaciado o color, entre otros, que funcionen como reglas de diseño y se puedan declarar en el theme.json (el archivo de configuración del tema) o como CSS adicional.

En este artículo vamos a profundizar en todo ello para que puedas diseñar sitios WordPress más escalables, tanto si los implementa una persona como si parte del proceso se apoya en herramientas de IA.

1. Pensar en módulos reutilizables
2. Diseñar patrones y variantes
3. Diseñar plantillas y partes de plantilla
4. Diseñar la experiencia de edición
5. Definir estilos globales
6. Diseñar para que el sitio pueda crecer sin romperse

Pensar en módulos reutilizables

Una web en WordPress no debería depender de páginas diseñadas una a una, como si cada pantalla fuera un caso único. Ese enfoque puede funcionar en un sitio muy pequeño, pero se vuelve frágil en cuanto crece, en cuanto se añaden nuevas secciones o si empiezan a editar contenido varias personas distintas.

El riesgo es acabar con un montón de excepciones aisladas. Las excepciones aisladas son elementos o secciones que, aunque cumplen la misma función, se han diseñado y editado de forma diferente en cada página. Hay que evitarlas a toda costa, porque hacen que sea muy difícil mantener la consistencia en el sitio.

En una web escalable, si una decisión se repite, no se aplica manualmente cada vez, sino que se define una única vez y se reutiliza.

Esto es importante porque cada valor aplicado a mano genera una deuda de diseño. Si un título tiene un tamaño concreto porque se ha ajustado manualmente en una página, ese tamaño no forma parte del sistema: está fijado manualmente en ese caso concreto o, como dicen los desarrolladores, está hardcodeado. Lo mismo ocurre con un color aplicado directamente a un botón, un margen decidido a ojo que no respeta la escala de espaciado o una sección copiada y modificada para salir del paso.

Probablemente, el usuario no se va a enterar de que hay un título en una página que es distinto a los demás, y lo más probable es que esta excepción no afecte a la experiencia de usuario. El problema aparece cuando la web cambia. Si dentro de unos meses se ajusta la escala tipográfica, cambia el color principal de la marca o se decide aumentar el espaciado entre secciones, todo lo que esté conectado al sistema podrá actualizarse de forma coherente. En cambio, todo lo que se haya resuelto como una excepción manual habrá que localizarlo y corregirlo a mano, uno a uno.

Por eso, cuando diseñamos para WordPress, pensamos en módulos reutilizables: piezas que pueden aparecer en distintas páginas con pequeñas variaciones, sin tener que rediseñarlas ni reconstruirlas desde cero cada vez. Algunos ejemplos de módulos o secciones reutilizables son:

• Un bloque hero o sección principal que presenta la propuesta de valor.
• Un bloque de beneficios que resume argumentos clave de forma escaneable.
• Un listado de servicios o productos.
• Una tarjeta de contenido.
• Una sección de testimonios.
• Un bloque de preguntas frecuentes (FAQ).
• Una llamada a la acción.
• Un bloque de logos o clientes.
• Una cabecera para páginas interiores.
• Un formulario de contacto.
• Estructuras de archivo o plantillas de entradas.

Cada una de estas piezas debe diseñarse como parte del sistema, no como un elemento aislado. Si una sección se va a repetir, no debería depender de que alguien la copie y la pegue «más o menos igual». Debería estar pensada con reglas claras: qué partes son editables, qué variantes necesita y cómo se comporta cuando cambia el contenido.

También podemos definir qué elementos deben quedar protegidos para que quien edita pueda modificar el texto o las imágenes sin alterar la composición. En WordPress, esto puede resolverse con el modo de edición content-only, que permite preparar bloques o patrones donde se edita el contenido, pero no el diseño.

En Figma, duplicar un elemento y crear una instancia de un componente pueden parecer lo mismo en la pantalla, pero no lo es: una copia se comporta como una pieza independiente. Un componente, en cambio, mantiene una lógica común aunque se use en distintos lugares.

Por lo tanto, cuando duplicas un elemento, creas una pieza nueva que ya no depende de la original. Pero cuando trabajas con un componente, defines una pieza reutilizable que puede repetirse en distintos lugares y cualquier cambio en el componente principal afectará a sus instancias.

En WordPress ocurre algo parecido: un botón que aparece en toda la web no debería ser un grupo duplicado veinte veces, sino un componente del sistema. Una tarjeta de entrada que se repite en la página de inicio, en el archivo y en las recomendaciones al final de una entrada debería tener una lógica común, aunque el contenido cambie.

Pensar en módulos también ayuda a identificar las piezas que de verdad conviene sistematizar. Se trata de distinguir qué partes se repiten y cumplen la misma función (botones, tarjetas, llamadas a la acción, bloques de contenido) y cuáles son excepciones específicas de una página.

Diseñar patrones y variantes

Una vez identificados los módulos principales, el siguiente paso es diseñar patrones y prever variantes para los diferentes estados de contenido.

Aquí conviene distinguir bien entre componentes y patrones:

• Un componente puede ser una pieza pequeña y reutilizable: un botón, una tarjeta, una etiqueta o un campo de formulario.
• Un patrón es una composición más amplia que agrupa varios componentes y define una estructura de diseño, una jerarquía visual y unas reglas de contenido. Por ejemplo, una sección hero con título, subtítulo, botón e imagen de fondo, una sección de servicios con tres tarjetas, una sección de testimonios o una llamada a la acción con fondo contrastado.

En el contexto de WordPress, los patrones son especialmente interesantes porque pueden traducirse a patrones de bloques. Según la documentación oficial, un patrón es «uno o más bloques que se han configurado previamente y se presentan al usuario»; en otras palabras, los patrones son grupos reutilizables de bloques.

Los patrones permiten insertar secciones completas desde el editor con un clic, tanto en plantillas como en entradas, y son ideales como puntos de partida. Existen patrones sincronizados, que mantienen su contenido idéntico en todos sus usos, y patrones no sincronizados, que crean una copia independiente cada vez que se insertan.

Cuando diseñamos un patrón, tenemos que pensar cómo se usa, cómo se edita y cómo se mantiene. Por ejemplo:

• Una tarjeta de servicio debería contemplar qué ocurre si el título tiene una línea o tres, si no hay imagen, si el texto es demasiado largo o si el botón es opcional.
• Una tarjeta de artículo debería incluir variantes para entradas con o sin imagen destacada, con autor visible o sin autor, con título corto o largo.
• Una sección de testimonios puede necesitar una variante con una sola cita, otra con varias en carrusel y otra en columnas.

El objetivo es anticipar los estados reales del contenido y evitar que el diseño solo funcione en la demo.

Herramientas como Figma o Penpot permiten trabajar con variantes de componentes. Esto es muy útil para documentar los distintos estados de una pieza en un mismo sitio. Por ejemplo, una tarjeta de producto podría tener variantes «normal», «con oferta», «agotado» y «sin imagen». Una tarjeta de artículo podría tener variantes «con imagen», «sin imagen», «categoría destacada» o «título largo».

Diseñar estas variantes no significa cubrir todas las posibilidades imaginables, pero sí los casos más probables en la web real: títulos de longitud variable, textos muy breves o muy largos, imágenes verticales u horizontales, contenido opcional o ausente, precios con descuento, elementos destacados, listas con pocos o muchos elementos, etc.

Además, conviene crear una biblioteca de patrones en el archivo de diseño. Cada patrón debe tener un nombre claro, un objetivo y ejemplos de uso.

Diseñar plantillas y partes de plantilla

En un entorno de edición completa del sitio, las plantillas son una pieza clave para que una web WordPress pueda crecer sin perder coherencia.

Hasta ahora hemos hablado de bloques y patrones. Los bloques permiten construir piezas de contenido; los patrones ayudan a reutilizar composiciones completas y a mantener una lógica común entre distintas páginas. Pero en una web WordPress todavía hay una capa más que conviene diseñar desde el principio: las plantillas.

Las plantillas definen la estructura de las páginas que WordPress genera de forma dinámica. No son una página concreta, sino el modelo que WordPress utiliza para mostrar determinados tipos de contenido: una entrada individual, una página, un archivo de blog, una categoría, una búsqueda, una página 404 o una ficha de producto, si estamos trabajando con WooCommerce.

Esto es especialmente importante porque muchas partes de una web WordPress no se diseñan página a página. Se diseñan como sistemas. Cuando alguien publica una nueva entrada, crea una categoría o añade un producto, WordPress necesita saber cómo debe mostrarse ese contenido sin que haya que diseñarlo manualmente cada vez.

Ahí es donde entran las plantillas.

Una plantilla bien diseñada responde a preguntas como estas:

• ¿Qué estructura tendrá una entrada del blog?
• ¿Dónde irá el título?
• ¿Cómo se mostrará la imagen destacada?
• Qué metadatos aparecerán: fecha, autoría, categoría, tiempo de lectura…
• Qué anchura tendrá el contenido principal.
• Qué ocurre si no hay imagen destacada.
• Cómo se mostrarán las entradas relacionadas.
• Qué elementos forman parte de la plantilla y cuáles podrá editar la persona que publica el contenido.

En una web sencilla, puede parecer suficiente diseñar una página y duplicarla. Pero en cuanto el sitio empieza a crecer, ese enfoque no es sostenible. Si cada entrada, cada landing o cada archivo se construye como una pieza aislada, cualquier cambio futuro se convierte en un trabajo manual. Cambiar la estructura del blog, ajustar el diseño de las categorías o modificar la forma en la que se presentan los productos puede obligarnos a revisar decenas o cientos de páginas.

Si usamos plantillas, la lógica es diferente. Diseñamos una estructura base y WordPress la aplica a todos los contenidos que correspondan a esa plantilla. Si más adelante necesitamos hacer un cambio, lo hacemos en el modelo, no en cada contenido individual.

Por eso, al diseñar una web WordPress escalable, conviene pensar desde el principio qué plantillas va a necesitar el sitio. No solo las páginas visibles en el menú principal, sino también todas las vistas dinámicas que el sistema puede generar.

Por ejemplo:

• Plantilla para entradas individuales.
• Plantilla para páginas.
• Plantilla para archivo del blog.
• Plantilla para categorías.
• Plantilla para resultados de búsqueda.
• Plantilla para página 404.
• Plantilla para productos, si hay WooCommerce.
• Plantilla para archivos de productos o categorías de producto.

Partes de plantilla

También conviene decidir qué partes de esas plantillas serán comunes en todo el sitio. En edición completa del sitio, elementos como la cabecera, el pie de página o determinadas franjas reutilizables pueden gestionarse como partes de plantilla. Esto permite mantener una estructura coherente sin tener que repetir el mismo bloque en cada página.

Distinguir contenido y estructura

La clave está en distinguir bien entre contenido y estructura.

El contenido cambia: títulos, textos, imágenes, productos, entradas, testimonios, casos de éxito.

La estructura debería ser más estable: dónde aparece cada cosa, qué jerarquía visual tiene, qué elementos se repiten y qué reglas mantienen la coherencia del conjunto.

Cuando esta diferencia no se define bien, aparecen los problemas habituales: páginas construidas a mano que deberían depender de una plantilla, patrones usados como si fueran plantillas, bloques duplicados sin criterio o diseños que funcionan en una página concreta pero no soportan contenido real.

Flexibilidad y coherencia

Una buena plantilla debe ser lo bastante consistente para mantener la identidad visual y lo bastante flexible para adaptarse a distintos contenidos.

También es importante prever variantes. Una entrada puede tener imagen destacada o no tenerla. Una categoría puede contener muchas publicaciones o solo unas pocas. Una búsqueda puede devolver resultados o quedar vacía. Un producto puede estar en oferta, agotado o tener variaciones. Si estos escenarios no se piensan en el diseño, acabarán resolviéndose de cualquier manera durante la implementación o, peor aún, cuando el sitio ya esté publicado.

Por eso, cuando preparamos un diseño para WordPress, no basta con entregar la vista ideal. También hay que indicar qué ocurre en los estados menos perfectos: contenido largo, contenido corto, ausencia de imagen, listados vacíos, títulos de dos líneas, categorías con pocos elementos o módulos que se repiten muchas veces.

Plantillas en un flujo de trabajo con IA

En un flujo de trabajo con IA, esto cobra todavía más importancia. Si pedimos a una herramienta que genere una web WordPress sin explicarle qué plantillas necesita, qué partes son reutilizables y qué reglas deben respetarse, lo normal es que produzca páginas que puede parecer que son correctas, pero que son poco escalables. Puede crear diseños visualmente aceptables, pero que no tienen una lógica clara de sistema.

En cambio, si documentamos las plantillas, los patrones, las variantes y las reglas de edición, la IA tiene muchas más posibilidades de interpretar correctamente la arquitectura del sitio. No solo le estamos diciendo cómo tiene que verse una página, sino cómo debe comportarse el sistema cuando el contenido cambie.

Diseñar plantillas es, en realidad, diseñar cómo va a crecer la web. Y en WordPress, esa diferencia es fundamental.

Diseñar la experiencia de edición

Nuestro usuario no es solo el que va a visitar la web, sino también el que la va a editar. Unas pautas mínimas ayudan mucho a quien va a gestionar el contenido.

Al documentar cada patrón conviene indicar qué partes son editables, qué textos tienen límite de caracteres, qué proporciones de imagen se recomiendan y qué partes deberían mantenerse estables para no romper la composición.

Lo ideal es que estas indicaciones estén lo más cerca posible del lugar donde se edita el contenido: por ejemplo, en la descripción del propio campo personalizado o en la interfaz de edición del bloque.

Si hace falta, también se puede crear una página privada con instrucciones o vídeos breves, pero el objetivo debería ser diseñar patrones suficientemente claros y robustos para que no dependan de una documentación externa demasiado extensa.

También es útil señalar en cada patrón en qué páginas conviene usarlos y otras aclaraciones, como el número máximo por página. Por ejemplo, podemos dar indicaciones de este tipo: «En todos los artículos del blog hay que incluir un bloque de CTA que dirija al usuario a un servicio, y en artículos extensos se pueden incluir hasta 3 bloques de CTA». Este tipo de información evita improvisaciones cuando se crean nuevas páginas y ayuda a mantener el diseño coherente.

Con los módulos y patrones definidos, el siguiente paso es asegurarse de que todos comparten el mismo lenguaje visual. Ahí entran los estilos globales.

Definir estilos globales

Los estilos globales son una parte estructural del diseño y conviene definirlos antes de entrar en el detalle de cada página. Un sistema visual coherente permite que las decisiones de tipografía, espaciado y color se apliquen en todos los patrones y bloques sin tener que reinventarlas en cada sección.

En WordPress, estas reglas se declaran en theme.json, el archivo de configuración del tema. A través de él se define qué opciones están disponibles en el editor, qué estilos se aplican globalmente y cómo se comportan los bloques por defecto. Lo que el editor llama «Estilos globales» (Apariencia → Editor → Estilos) es la interfaz que permite modificar esa configuración en tiempo de ejecución.

Paleta de colores y variables de color

Tu trabajo al definir la paleta es decidir qué colores van a estar disponibles en el editor y con qué nombre aparecen. Esa decisión va a determinar directamente cómo va a trabajar quien gestiona el contenido: si le das libertad para que elija cualquier color, cada nueva página puede acabar introduciendo decisiones cromáticas arbitrarias. En cambio, si le das una paleta cerrada y bien nombrada, trabaja con opciones limitadas, comprensibles y coherentes con el sistema visual.

En theme.json, esto se declara mediante settings.color.palette, que define qué colores aparecen en el selector del editor. Con settings.color también puedes decidir qué controles aparecen: color de texto, fondo, enlaces, degradados, duotonos, etc. Cuanto más acotes esas opciones desde el diseño, menos decisiones improvisadas se tomarán después.

También puedes definir ajustes específicos por bloque. Por ejemplo, un bloque Cover podría tener una paleta distinta de la global si el diseño lo necesita. Esto permite mantener una base común para todo el sitio y, al mismo tiempo, controlar excepciones justificadas en bloques concretos.

Por eso, al preparar los colores, conviene definir cada color con tres datos:

• Nombre visible, que verá la persona editora en WordPress.
• Slug técnico, que usará desarrollo en theme.json.
• Función, es decir, cuándo debe usarse ese color.

Por ejemplo:

Nombre visible	Slug técnico	Valor	Uso
Primario	primary	#3858E9	Acciones principales, enlaces destacados
Texto principal	text-primary	#1A1A1A	Texto base sobre fondos claros
Fondo suave	background-soft	#F6F7F9	Secciones secundarias o bloques destacados
Borde sutil	border-subtle	#DADDE3	Separadores, tarjetas y campos de formulario
Error	error	#B42318	Mensajes de error o estados destructivos

El nombre visible debe ser comprensible para quien edita la web. El slug técnico debe ser estable, corto y fácil de usar en código. Y la función evita que el color se utilice de forma arbitraria.

Colores primitivos y semánticos

«Azul» describe el aspecto. «Acción primaria» describe la intención. Si dentro de un año cambia la identidad visual y ese color deja de ser azul, la función puede seguir siendo la misma.

Aquí entran los tokens o variables de diseño. No hace falta montar un sistema complejo para todos los proyectos, pero sí conviene distinguir entre colores primitivos y colores semánticos.

Los colores primitivos describen el valor:

• blue-500
• gray-900
• red-600

Los colores semánticos describen el uso:

• color-action-primary
• color-text-primary
• color-background-soft
• color-border-subtle
• color-feedback-error

Para una web WordPress, normalmente es más útil entregar al desarrollo una paleta semántica, porque esos nombres se pueden trasladar mejor a theme.json y a la interfaz de edición.

WordPress genera propiedades CSS personalizadas a partir de los ajustes preestablecidos declarados por el tema, por ejemplo --wp--preset--color--primary, y también clases asociadas a esos colores.

Entonces, tu trabajo de diseño consiste en:

1. Definir primero los colores de marca.
2. Convertirlos en colores funcionales: texto, fondo, acción, borde, estados.
3. Nombrarlos según su uso, no solo según su apariencia.
4. Indicar qué combinaciones son válidas: texto sobre fondo, botón sobre fondo, enlace sobre fondo, etc.
5. Limitar la paleta a los colores que realmente deben estar disponibles en el editor.
6. Entregar nombre visible, slug técnico, valor y uso recomendado.

Entregamos al desarrollo un conjunto de decisiones ya tomadas: este color es para acciones principales, este para texto, este para fondos suaves, este para errores, este para bordes.

Así, el equipo de desarrollo puede convertir la paleta en preajustes de theme.json, la persona que edita la web tiene opciones claras y el sitio puede crecer sin que cada nueva página dependa de decisiones improvisadas, porque las decisiones ya están tomadas.

Escala tipográfica, jerarquía y tipografía fluida

La escala tipográfica es el conjunto de tamaños de letra que defines para el sitio: cuántos niveles existen, qué diferencia visual hay entre ellos y cómo se comportan en distintos contextos.

Esta escala es lo que permite al lector escanear la página y distinguir un título principal de un subtítulo, una entradilla del cuerpo de texto o un texto secundario de una etiqueta.

En escritorio la escala puede ser más expresiva, con saltos amplios entre niveles. En móvil suele funcionar mejor una escala más contenida: los saltos demasiado grandes consumen espacio vertical y pueden dificultar la lectura. Lo mismo ocurre en interfaces más densas, como paneles de administración, donde la jerarquía debe ser clara pero no dramática.

Tipografía fluida en WordPress

Para cada nivel conviene documentar un tamaño mínimo (el que se usará en móvil) y un tamaño máximo (el de escritorio). Con esos dos valores, el equipo de desarrollo puede implementar tipografía fluida usando clamp() en theme.json mediante settings.typography.fluid.

Con esta técnica, el tamaño crece de forma progresiva entre ambos extremos sin saltos bruscos entre breakpoints o puntos de ruptura del diseño.

No necesitas calcular los valores de clamp() tú, pero sí necesitas definir los rangos desde los que se calculan.

Los valores deben estar en rem, no en px. Es una cuestión de accesibilidad: rem es proporcional al tamaño de fuente que el usuario haya configurado en su navegador, así que si alguien ha aumentado el texto base para leer mejor, el sistema tipográfico lo respeta. Si declaramos los valores en píxeles, se ignora esa preferencia.

La tipografía fluida no solo se adapta a cada dispositivo sino también a las preferencias de cada usuario.

El alto de línea fluido en WordPress

El interlineado también forma parte del sistema tipográfico, pero en WordPress no se gestiona igual que los tamaños de fuente. WordPress permite definir el line-height en theme.json, activar el control de interlineado en el editor y aplicar valores concretos por bloque, pero no ofrece una escala nativa de preajustes de interlineado equivalente a la de los tamaños de letra.

Si necesitamos una escala de interlineados más precisa, podemos documentarla como parte del sistema, declararla como tokens personalizados en settings.custom o aplicarla mediante CSS.

También podemos usar clamp() si queremos que el interlineado cambie de forma progresiva según el contexto. Por ejemplo, un párrafo puede necesitar algo más de interlineado en móvil si las líneas son estrechas y la lectura se vuelve densa, mientras que en escritorio puede funcionar mejor un valor algo más compacto si el ancho de línea está bien controlado.

No todos los textos necesitan el mismo aire. Un título grande suele funcionar mejor con un interlineado más compacto, un párrafo largo necesita suficiente separación para facilitar la lectura, y un texto pequeño necesita aire para no perder legibilidad. Lo importante es no dejar el interlineado como una decisión manual de cada bloque. Igual que definimos una escala tipográfica, conviene definir una escala de interlineados para títulos, párrafos, textos pequeños y elementos funcionales, y documentar cuándo debe usarse cada valor.

El ancho máximo de línea

El ancho máximo de línea es una decisión clave para la legibilidad. Si una línea es demasiado larga, al lector le cuesta volver al inicio de la siguiente sin perderse; si es demasiado corta, la lectura se vuelve entrecortada porque hay demasiados saltos de línea.

Como referencia general, en textos largos conviene trabajar con líneas de entre 60 y 80 caracteres aproximadamente, contando letras, espacios y signos de puntuación. No es una regla rígida, pero sí un buen punto de partida para comprobar si el bloque de texto resulta cómodo de leer.

El ancho adecuado depende del tamaño de letra, de la familia tipográfica, del interlineado y del idioma. Una forma práctica de revisarlo es colocar un párrafo (con texto de verdad, no lorem ipsum) y comprobar cuántos caracteres entran en una línea media.

Si con un cuerpo de texto de 18 px una columna de 720 px genera líneas demasiado largas, podemos reducir el ancho máximo del contenedor; si en móvil las líneas quedan demasiado cortas, podemos ajustar márgenes laterales, tamaño de letra o interlineado. La clave es documentar ese ancho máximo como parte del sistema de lectura y no resolverlo caso por caso en cada bloque.

Y ya tenemos el sistema de lectura

La escala tipográfica, el interlineado y el ancho de línea máximo de los párrafos forman el sistema de lectura del sitio. No son tres decisiones independientes y conviene documentarlas juntas: qué escala se usa en escritorio y en móvil, qué valores mínimos y máximos tiene cada nivel, qué interlineado corresponde a cada estilo y qué ancho máximo de línea se recomienda para párrafos largos. Con esa información, desarrollo decide qué estilos van a theme.json y cuáles necesitan CSS adicional.

Sistema de espaciado

El espaciado es el ritmo invisible del diseño. Un margen incoherente puede estropear una composición aunque la tipografía y el color sean correctos. Para evitarlo, conviene definir una escala basada en múltiplos (por ejemplo, 4, 8, 16, 24, 32 px…) y asignar un nombre de uso a cada valor: separación entre secciones, relleno interno del bloque, distancia entre título y texto, relleno del botón, etc.

Con esa escala documentada, desarrollo puede declararla en theme.json como preajustes con nombre. El resultado práctico es que quien edita un bloque selecciona «espaciado-xl» en lugar de escribir un valor arbitrario, y el sitio mantiene la coherencia sin depender del criterio de cada persona.

En theme.json, el espaciado se gestiona desde settings.spacing, que cubre específicamente margin, padding y gap.

Botones

Los botones merecen un apartado propio porque son el punto donde el diseño y la conversión se tocan directamente. Como mínimo, conviene definir botón primario, secundario y terciario, junto con sus estados: normal, hover, focus, activo y deshabilitado. En theme.json es posible declarar el estado :hover de los botones mediante elements.button; el resto de estados requiere CSS adicional.

Documentarlo desde el diseño evita que cada patrón acabe resolviendo los botones de una forma distinta. Estamos preparando un artículo específico sobre cómo diseñar botones para WordPress con todo el detalle.

Documentar el sistema para desarrollo

Por último, los estilos globales deben incluirse en el handoff del proyecto, es decir, en la entrega de la documentación técnica al equipo de desarrollo.

Documenta la paleta de colores con nombres y valores, la escala tipográfica con tamaños y usos, la escala de espaciado, los radios de borde, los estilos de botones y enlaces, y cualquier regla general (contraste mínimo, anchos máximos, etc.).

Esta documentación permite que la persona que implementa la web configure theme.json de acuerdo con el diseño y que el equipo editorial entienda por qué existen ciertas opciones y cómo usarlas. Te lo cuento todo con detalle en el artículo sobre cómo preparar un archivo de diseño para desarrollo en WordPress (y para la IA).

Diseñar para que el sitio pueda crecer sin romperse

No todos los proyectos necesitan un sistema complejo. Pero si defines aunque sea una paleta de colores semántica, una escala tipográfica fluida, cuatro o cinco patrones bien pensados y las plantillas imprescindibles, tienes una buena base desde la que cualquier persona puede seguir construyendo el sitio sin romper lo que ya está hecho.

Diseñar para WordPress no consiste solo en preparar una versión inicial del sitio, sino en definir las reglas que permitirán que siga creciendo con coherencia. Cuanto más claro sea el sistema, menos dependerá la web de decisiones improvisadas y más fácil será mantenerla, ampliarla y editarla sin romper lo que ya funciona.