Del wireframe al diseño: Bricks como esqueleto semántico y Tailwind + Flowtitude como acabado final en WordPress

Cuando todo se mezcla y nada escala

Hay una escena que se repite en casi todos los estudios de desarrollo WordPress.
Empiezas un proyecto con entusiasmo, eliges un constructor potente como Bricks, vas montando secciones, ajustando botones, cambiando tipografías y añadiendo detalles. Todo parece fluir.

Pero pasan unas semanas y empiezan los problemas:

• Un botón tiene un borde redondeado distinto al de la landing.
• La tipografía de los títulos cambia según la plantilla.
• Los colores ya no coinciden porque alguien los definió “a mano” en una página.

El resultado: una web que funciona, sí, pero que carece de coherencia visual. Y cuando el cliente pide un rediseño —nuevo branding, otra paleta de colores, tipografía distinta— lo que parecía un cambio simple se convierte en una pesadilla.

La mayoría de las veces, este caos se debe a que mezclamos estructura y diseño en el mismo momento. Maquetamos y decoramos al mismo tiempo, sin separar responsabilidades.

En Flowtitude tenemos otra forma de trabajar. Construimos primero el wireframe, que es el esqueleto semántico de la web, usando Bricks. Y después aplicamos el acabado final, el diseño, usando Tailwind CSS v4 junto a nuestras convenciones de Flowtitude.

Ese pequeño cambio metodológico tiene un impacto enorme: webs más consistentes, más fáciles de rediseñar y mucho más escalables.

Bricks: la herramienta perfecta para el esqueleto semántico

Lo primero es entender qué significa “esqueleto semántico”.
Un esqueleto semántico es la estructura lógica del contenido: cómo se organizan las secciones, qué etiquetas se usan, cómo se jerarquizan los títulos, cómo se colocan los elementos en la cuadrícula.

Bricks Builder es perfecto para esto porque no se limita a ser un maquetador visual; es un constructor que respeta el HTML. Puedes decidir si un bloque es un <section>, un <article> o un <aside>. Puedes controlar <h1> a <h6> sin trucos raros. Y, sobre todo, puedes crear plantillas reutilizables que mantienen la coherencia semántica en todo el sitio.

Un ejemplo sencillo

Imagina que tienes que mostrar un listado de cursos en tu web.
Con Bricks lo natural es crear una plantilla con un Query Loop que recorra tu CPT “Cursos” y genere una tarjeta por cada uno.

Ese loop define la estructura:

• Una sección que envuelve el bloque.
• Un título principal.
• Un grid de columnas para las tarjetas.
• Dentro de cada tarjeta: imagen, título, descripción y un botón.

En esta fase, no necesitas pensar en colores ni tipografías. Solo en la jerarquía del contenido. El HTML resultante podría verse así:

<section class="container mx-auto py-12">
  <header class="mb-8">
    <h2 class="text-balance">Nuestros cursos</h2>
    <p>Aprende WordPress, Bricks y Tailwind paso a paso.</p>
  </header>

  <div class="grid grid-cols-1 md:grid-cols-3 gap-6">
    <article class="card">
      <img class="card-img" src="cover.jpg" alt="Imagen del curso">
      <div class="card-body">
        <h3 class="card-title">Curso destacado</h3>
        <p class="card-text">Una breve descripción que capta la atención.</p>
        <a class="btn">Ver curso</a>
      </div>
    </article>
    <!-- Más cards generadas por el loop -->
  </div>
</section>

Fíjate en dos cosas:

1. Hay utilidades de Tailwind mínimas (container, mx-auto, grid, gap-6) que ayudan a maquetar, pero aún no hay decisiones de diseño.
2. Aparecen clases semánticas como .card, .card-title, .btn, pero todavía no tienen estilo. Solo son ganchos para el acabado final.

Esto es el wireframe. Una estructura clara, coherente, lista para ser vestida.

Tailwind y Flowtitude: el diseño como acabado final

Cuando el wireframe está sólido, es el momento de aplicar el diseño. Y aquí es donde Tailwind CSS v4 despliega toda su fuerza.

Tailwind te da un set de utilidades coherentes para tipografía, espaciado, color y layout. Pero lo más interesante en v4 es el uso de @theme para definir tokens y de @layer components para crear patrones globales.

Tokens en @theme

Los tokens son como el ADN visual de tu marca:

• Colores principales y secundarios.
• Tipografías.
• Radios de borde.
• Sombras.

En Flowtitude centralizamos todo en @theme:

@theme {
  --color-primary-500: #7c3aed;
  --color-primary-600: #6d28d9;

  --font-sans: ui-sans-serif, system-ui, "Inter", Arial, sans-serif;
  --font-display: "General Sans", var(--font-sans);

  --radius-md: .5rem;
  --shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 0.05);
}

Con estos tokens, cualquier cambio de branding se convierte en cuestión de minutos.

Componentes ligeros en @layer

Después definimos una capa muy fina de componentes, lo justo para no repetir utilidades en cada instancia.

@layer components {
  .btn { 
    @apply inline-flex items-center justify-center px-4 py-2 rounded-[var(--radius-md)] font-medium transition;
  }
  .btn-primary {
    @apply bg-[var(--color-primary-500)] text-white hover:bg-[var(--color-primary-600)];
  }

  .card {
    @apply rounded-[var(--radius-md)] border border-gray-200 bg-white shadow-[var(--shadow-sm)];
  }
  .card-body { @apply p-6 space-y-2; }
  .card-title { @apply text-xl font-semibold text-gray-900; }
  .card-text  { @apply text-gray-600; }
  .card-img   { @apply w-full h-40 object-cover; }
}

Con esto, todas las cards y botones del sitio tendrán un acabado consistente. Y si mañana cambias de estilo, solo necesitas modificar estas reglas.

Caso real: un mismo sitio, dos acabados diferentes

Para verlo en acción, volvamos al listado de cursos. El HTML es el mismo, el loop en Bricks es el mismo. Lo único que cambia es la capa de diseño.

Acabado 1: Corporativo

Colores sobrios, tipografía sans-serif, bordes discretos.

.card       { @apply bg-white border border-gray-200 rounded-lg shadow-sm; }
.card-title { @apply text-lg font-medium text-gray-900; }
.btn        { @apply px-4 py-2 bg-blue-600 text-white rounded-md; }

Acabado 2: Creativo

Gradientes, tipografía display, sombras llamativas.

.card       { @apply bg-gradient-to-br from-pink-500 to-purple-600 text-white shadow-lg rounded-2xl; }
.card-title { @apply text-2xl font-bold font-[var(--font-display)]; }
.btn        { @apply px-5 py-3 rounded-full bg-white text-purple-700 font-semibold; }

El HTML no se toca. El contenido es el mismo. Lo único que cambia es el acabado final.

Esto significa que puedes tener múltiples identidades visuales para la misma estructura. Perfecto para proyectos multibrand, rediseños o incluso para test A/B de estilo.

Por qué es un salto frente a BEM y CSS personalizado

En la comunidad Bricks es habitual ver propuestas basadas en CSS propio con metodología BEM y tokens. No es un error: es ordenado y ha funcionado en muchos proyectos.

Pero en WordPress y, en particular, con Bricks, BEM presenta algunas limitaciones:

• El naming es costoso y subjetivo.
• Los estilos acaban en archivos externos que hay que mantener aparte.
• Muchas veces duplicas lógica que ya tienes en Bricks (por ejemplo, instancias de un componente).

Con Tailwind + Flowtitude, ese peso desaparece.

• El naming se reduce porque las utilidades ya resuelven la mayoría de casos.
• Los tokens se centralizan en @theme.
• La capa de componentes es mínima, solo para patrones que de verdad se repiten.

El resultado: menos fricción, más rapidez y un sistema que se adapta a cualquier constructor.

Impacto real en proyectos WordPress

Este enfoque no es solo teoría bonita. Tiene consecuencias muy prácticas:

• Tiempo de rediseño: cambiar colores y tipografía en toda la web se hace en minutos, no en días.
• Consistencia: todos los botones, cards y formularios se ven iguales sin importar quién los cree.
• Colaboración: los equipos se reparten el trabajo sin pisarse. El maquetador en Bricks trabaja estructura; el diseñador en Tailwind ajusta acabados.
• Futuro asegurado: si mañana Gutenberg domina el mercado, el sistema visual se mantiene. Solo cambias el wireframe, no el diseño.

Conclusión: construir para hoy y rediseñar mañana

La diferencia entre una web que escala y una que se rompe está en cómo separas las capas de tu trabajo. Si mezclas estructura y diseño desde el inicio, cualquier cambio futuro será doloroso.

Si, en cambio, construyes el esqueleto semántico con Bricks y aplicas el acabado final con Tailwind + Flowtitude, tu web se vuelve modular, coherente y preparada para el futuro.

Hoy puedes lanzar un proyecto corporativo sobrio. Mañana, con el mismo esqueleto, puedes darle un acabado creativo y llamativo. Pasado, puedes adaptarlo a otra marca sin reescribir nada.

Eso es lo que llamamos en Flowtitude un sistema de trabajo moderno: WordPress sin miedo al cambio.

¿Quieres llevar este enfoque a tu propio flujo de trabajo?

Lo que hemos visto aquí es solo la base. Con Bricks construyes un esqueleto semántico sólido, y con Tailwind + Flowtitude aplicas un acabado final coherente y flexible. El resultado: webs más consistentes, fáciles de rediseñar y listas para escalar.

Pero hay algo más. Con Flowtitude, además, el marcado se reduce todavía más gracias al uso de estilos semánticos. No necesitas añadir veinte clases en cada elemento: defines patrones inteligentes que entienden el contexto. Así ahorras tiempo, código y dolores de cabeza.