La mayoría de proyectos WordPress funcionan bien durante seis meses. El séptimo, el diseño empieza a divergir. Al año, el sitio es técnicamente correcto y visualmente inconsistente. Nadie sabe exactamente cuándo ocurrió, ni por qué. En la mayoría de casos, el origen es el mismo: no hay un sistema de diseño WordPress definido desde el principio.
Hemos visto este patrón suficientes veces como para entender que no es un problema de talento ni de herramientas. Es un problema de sistema.
En este artículo explicamos la metodología que aplicamos en proyectos WordPress de cierta escala: cómo la organizamos, por qué tomamos las decisiones que tomamos, y qué hemos aprendido en el proceso.
El problema de construir WordPress sin sistema de diseño
Cuando un equipo desarrolla con WordPress sin un sistema de diseño definido, cada componente acaba siendo una decisión local.
El equipo de desarrollo que implementa el hero usa font-size: 2.5rem porque así lo ve en Figma. El que hace las cards usa 2.4rem por la misma razón. Los dos miraron el mismo archivo. Los dos creen que hicieron lo correcto. Y dentro de su propio contexto, los dos acertaron.
Multiplicado por cincuenta componentes y tres años de iteraciones, el resultado es predecible: un CSS que nadie se atreve a tocar, valores que surgieron de ningún sitio, y un equipo de diseño que ha perdido la confianza en lo que le entregan.
El problema no es Gutenberg. No es la clientela que cambia de opinión. No es el plugin que actualizó alguien sin avisar. Es la ausencia de sistema.
Sin sistema, cada decisión se toma dos veces: una en diseño y otra en desarrollo. Y las dos versiones nunca son exactamente la misma.
Tres capas, una sola fuente de verdad
La metodología que aplicamos organiza el diseño en tres capas progresivas. Cada una se construye sobre la anterior. Ninguna puede saltarse.
F1 — Tokens primitivos
Todo empieza en theme.json, el archivo de configuración nativa de WordPress FSE. Aquí viven los valores primitivos: la paleta de color completa (de primary-50 a primary-900), las escalas tipográficas con sus rangos fluidos, los valores de espaciado, las sombras.
La clave está en que estos valores son fluidos por defecto. En lugar de declarar font-size: 1.5rem para un H2, declaramos un clamp() que interpola entre el tamaño mínimo (móvil) y el máximo (escritorio). El diseño es responsivo desde el token, no desde una media query que alguien añadió más tarde.
theme.json también define los dos anchos que gobiernan toda la composición: el ancho de contenido (1.200px) y el ancho wide (1.312px). Cualquier sección puede ser content, wide o full sin una sola línea de CSS adicional. El editor lo expone como un control visual. El cliente lo puede cambiar. El resultado es siempre predecible.
F2 — Clases semánticas
Los tokens primitivos no se usan directamente en los componentes. Se mapean primero a variables semánticas (--color-brand-primary, --spacing-component-md) y luego a clases atómicas reutilizables que llamamos Global Classes.
Estas clases son el vocabulario del sistema: .btn-primary, .card, .heading-display, .text-on-dark. Cada una encapsula una intención de diseño, no un valor arbitrario. Cuando el color de marca cambia, cambia en un sitio. El resto del sistema se actualiza solo.
El matiz importante: las Global Classes no llevan layout. Sin display: flex, sin grid, sin @media para estructura. Eso lo gestiona WordPress de forma nativa. Las clases son para atributos visuales: color, tipografía, radio, sombra. La separación entre «cómo se ve» y «cómo se coloca» es intencionada y no negociable.
F3 — Patrones y constructores
La tercera capa son los patrones de bloque: las secciones completas que se insertan desde el editor —hero, grid de features, carrusel de testimonios, sección de recursos— compuestas a partir de los átomos de F1 y F2.
La decisión arquitectónica más importante de F3 es cómo se generan esos patrones. Optamos por constructores PHP que serializan el markup de Gutenberg de forma programática, en lugar de archivos estáticos escritos a mano.
La razón es simple: cuando un átomo cambia —por ejemplo, el espaciado interno de un botón— el cambio se propaga a todos los patrones que usan ese átomo. Sin constructores, habría que actualizar cada archivo de forma manual. Con constructores, el átomo cambia en un sitio y todos los patrones lo heredan.
Figma como fuente de extracción, no como referencia visual
Uno de los errores más frecuentes en la integración diseño-desarrollo es usar Figma como referencia visual: el equipo de desarrollo abre el archivo, mira el componente, y aproxima los valores a ojo.
Nuestro proceso funciona al revés. Extraemos los valores exactos de Figma con herramientas de inspección programática antes de escribir una sola línea de código. font-size, line-height, letter-spacing, gap, padding, border-radius: cada valor tiene una fuente concreta. Si no lo podemos extraer, no lo podemos implementar.
Esto tiene una consecuencia importante: si un valor no existe en el sistema de tokens, eso es un hallazgo, no un motivo para hardcodearlo. O el token necesita actualizarse, o el diseño necesita revisarse, o hay un caso genuinamente excepcional que hay que documentar.
La norma más contraintuitiva que aplicamos en este punto es que la escala tipográfica del sistema de diseño prevalece sobre los valores de Figma cuando hay discrepancia. Figma muestra el desktop snapshot de un tamaño que el sistema expresa de forma fluida. Si el token dice clamp(1rem, calc(0.95rem + 0.22vw), 1.125rem) y Figma muestra 18px a 1.440px, el token gana. Figma no estaba equivocado: simplemente estaba mostrando un fotograma de algo que el sistema ya resuelve de otra manera.
Por qué Greenshift y qué hacemos con él
WordPress tiene bloques nativos para prácticamente todo: párrafos, encabezados, imágenes, botones. La pregunta es cuándo usarlos y cuándo no.
Nuestra regla es binaria y no tiene excepciones no documentadas:
- Bloques core → estructura y layout únicamente. Grupos, filas, columnas, la chrome FSE (header, footer, contenido principal). Nada de contenido de usuario.
- GreenLight (Greenshift) → todos los átomos de contenido. Encabezados, párrafos, enlaces, botones, listas, iconos, badges. Todo.
La razón no es preferencia estética. Es traducibilidad.
Cuando un proyecto es multilingüe, todo el contenido tiene que estar disponible en varios idiomas, gestionado por el cliente sin intervención técnica. WPML, el plugin de traducción más extendido en proyectos de esta escala, tiene un soporte mucho más sólido y predecible sobre el contenido de las páginas que sobre las plantillas FSE.
Greenshift viene con su propio archivo de configuración WPML que registra sus bloques como traducibles, incluyendo los atributos de texto, alt text, href y título. Eso significa que un átomo GreenLight es tan traducible como un bloque core nativo, sin configuración adicional. La elección tiene un fundamento funcional, no solo estilístico.
La segunda razón es la edición. Los átomos GreenLight son editables directamente en el editor de bloques. La clientela puede cambiar el texto, el color, el enlace. El desarrollador no tiene que tocar nada. Eso no es un detalle menor: es el modelo mental que hace que el CMS funcione como CMS.
Nada hardcodeado: el contrato con el editor
Hay un principio que atraviesa toda la metodología y que tiene más impacto del que parece a primera vista: ningún texto visible en el sitio puede ser una cadena literal en PHP.
Cada sección que construimos tiene una fuente de datos explícita para cada elemento de copy:
- Texto de instancia (el titular de una sección específica): contenido editable del bloque, vive en la página, se traduce por página.
- Texto compartido entre términos (etiquetas de filtros, descripciones de categorías): metadatos de taxonomía, gestionados desde el panel de términos.
- Cadenas de interfaz que no pueden ser bloques: función
__()con textdomain, traducibles desde WPML String Translation.
El PHP puede tener fallbacks literales (get_field('cta_text') ?: 'Más información'), pero solo como red de seguridad. El contenido real siempre tiene una fuente editable.
La consecuencia práctica: cuando un cliente de otro mercado necesita cambiar el texto de un botón, no abre un ticket de desarrollo. Lo cambia él mismo desde el panel.
Lo que cambia cuando tienes sistema
La pregunta que nos hacemos al final de cada proyecto es si el siguiente componente fue más fácil que el anterior. Si la respuesta es no, algo en la arquitectura está fallando.
Con este sistema, la respuesta suele ser sí. No porque los componentes sean más simples, sino porque el vocabulario ya está definido. El desarrollador que implementa una nueva sección sabe exactamente qué tokens usar, qué clases aplicar, cómo componer la estructura sin CSS nuevo, dónde va el contenido editable.
El diseñador sabe que lo que ve en Figma es lo que va a renderizar el navegador, porque los valores vienen del mismo archivo que definió el sistema.
El cliente sabe que puede editar el titular de cualquier sección sin llamar a nadie, que el sitio está disponible en varios idiomas, y que cuando cambie el color de marca, cambiará en todas partes.
Eso no es una garantía que se pueda dar sin sistema. Con sistema, es simplemente lo que pasa.
Gutenberg no es el problema. El proceso es el problema.
Llevamos años escuchando críticas a Gutenberg que, en el fondo, son críticas a la ausencia de metodología alrededor de él. El editor de bloques tiene sus limitaciones, como cualquier herramienta. Pero la mayoría de los proyectos que «no funcionan bien con Gutenberg» en realidad no tienen sistema de diseño, no tienen convenciones de nomenclatura, no tienen una política clara sobre qué va en un bloque y qué va en CSS.
La tecnología no es el cuello de botella. El cuello de botella es construir sin protocolo.
Un sitio WordPress enterprise no necesita la herramienta más sofisticada del mercado. Necesita un equipo que sepa exactamente qué decisión tomar en cada punto, por qué la toma, y cómo ese punto encaja con los demás.
Eso es lo que intenta hacer este sistema. No es el único sistema válido. Es el que hemos refinado trabajando con proyectos reales, con clientes y clientas reales, con restricciones de tiempo y presupuesto reales.
Y de momento, funciona.
¿Estás construyendo un proyecto WordPress que ha superado la escala en la que el enfoque habitual deja de funcionar? Hablamos.
Preguntas frecuentes
¿Qué es un sistema de diseño WordPress?
Un conjunto de tokens (colores, tipografías, espaciados), clases reutilizables y patrones de bloques que garantizan coherencia visual en todos los componentes de un sitio, sin depender de decisiones manuales caso a caso.
¿Por qué usar Greenshift con Gutenberg?
Greenshift extiende el editor nativo con bloques de contenido atómicos (encabezados, botones, listas) que son editables desde el panel y traducibles con WPML sin configuración extra. Esto separa layout (bloques core) de contenido (GreenLight), haciendo el sistema más predecible y mantenible.
¿Qué es WordPress FSE?
Full Site Editing es el modo nativo de WordPress para diseñar cabeceras, pies de página y plantillas completas desde el editor de bloques, usando theme.json como fuente central de tokens de diseño.
¿Cuándo vale la pena esta metodología?
En proyectos de media-alta escala donde más de un desarrollador toca el código, el cliente necesita editar contenido de forma autónoma, o el sitio debe mantenerse durante más de dos años sin acumular deuda técnica visual.
