Cómo preparar un archivo de diseño para desarrollo en WordPress (y para la IA)

Preparar un archivo de Figma para desarrollo consiste en hacer explícitas las decisiones importantes: cómo se llaman las capas, qué elementos son componentes, qué variables definen el sistema visual, qué plantillas hay que construir, qué comportamientos no se pueden deducir solo mirando la pantalla y qué restricciones técnicas tiene el proyecto.

El archivo de diseño necesita contener más contexto del que se ve a simple vista.

Cuando diseñamos, seguimos un sistema que en el handoff (el proceso de entrega del diseño a desarrollo) hay que hacer explícito: cómo se organizan las secciones, qué patrones se repiten, qué relación hay entre los tamaños y espaciados de escritorio y de móvil, etc.

Esto siempre ha sido útil en el handoff entre diseño y desarrollo. A la persona que iba a implementar la web le venía fenomenal que lo pusiéramos todo muy claro en el propio archivo de diseño. ¡Y a nuestro yo del futuro!

Ahora, además, las herramientas de IA pueden leer archivos de diseño a través del MCP y generar documentación o código a partir de ellos. Por eso, preparar bien el archivo es todavía más importante.

La IA puede inferir muchas cosas, pero no conoce el contexto del proyecto si no se lo damos. Cuanto más claro sea el archivo, mejor podrá entenderlo. Y cuanto mejor lo entienda, más útil será el resultado que devuelva.

En este artículo te explico cómo preparar un archivo de Figma para que se pueda implementar mejor en WordPress y para que además sea más comprensible si trabajas con IA en el proceso.

1. Nombrar las capas
2. Crear variables
3. Crear componentes y sus variantes
4. Añadir Auto Layout
5. Diseñar las plantillas necesarias
6. Añadir anotaciones
7. Automatizar tareas de revisión y documentación con Claude
8. Diseñar para WordPress hasta el final

Nombrar las capas

Durante mucho tiempo, mi forma pragmática de trabajar no pasaba por nombrar absolutamente todas las capas del archivo.

En muchos proyectos, si el diseño lo iba a implementar una persona con la que trabajabas de cerca, o si el archivo era relativamente pequeño, podías permitirte cierto margen. Nombrabas los componentes principales, ordenabas las pantallas, dejabas algunas notas y el resto se resolvía con comunicación directa.

Pero cuando la IA entra en el flujo, ese margen se reduce.

Una persona puede mirar una pantalla, entender el contexto, recordar una conversación, preguntarte una duda o interpretar que ese grupo de elementos forma una card aunque se llame Group 14. Pero una IA conectada a Figma depende mucho más de lo que diga el archivo de forma explícita.

Y una de las formas más directas de decirle a la IA qué es cada cosa es nombrar bien las capas.

Los nombres automáticos de Figma (Frame 32, Group 14, Rectangle 8) no aportan información porque no explican qué función cumple cada elemento ni qué relación tiene con el resto.

Un nombre como hero/title o product/card/price ya contiene información útil. Indica a qué bloque pertenece el elemento, qué papel cumple y, en muchos casos, qué tipo de contenido se puede esperar (una frase, una cantidad, un párrafo, una imagen…).

Una convención práctica para proyectos WordPress es usar el patrón bloque/elemento o, cuando haga falta más detalle: bloque/elemento/variante.

Por ejemplo:

No hace falta nombrar cada rectángulo si no aporta nada al desarrollo. Pero sí conviene nombrar todo lo que tenga función estructural, semántica o reutilizable.

Es especialmente útil nombrar:

• Plantillas y patrones.
• Secciones principales.
• Componentes y sus variantes.
• Botones.
• Menús y otros elementos de navegación.
• Cards.
• Formularios y campos de formulario.
• Elementos que dependan de contenido dinámico de WordPress (el título de una entrada, la imagen destacada, el extracto, el precio de un producto, el nombre del autor, una taxonomía).
• Grupos que tengan lógica de layout (un wrapper que centra el contenido, un contenedor que define el ancho máximo, una fila que distribuye elementos con un gap concreto…).

Crear variables

Una parte importante del handoff no está en las pantallas, sino en el sistema que hay detrás.

Colores, tipografías, espaciados, radios, sombras y estilos no deben depender de valores aislados aplicados a mano capa a capa.

Si cada color está escrito como un hexadecimal independiente, cada relleno se ha ajustado manualmente y cada tamaño tipográfico se ha definido de forma suelta, se ve bien el diseño, pero no se ve la lógica que lo sostiene, que es lo que necesita ver el desarrollador (y la IA).

Color: nombrar por función

En lugar de aplicar #1A1A18 directamente a todos los textos principales, puedes definir una variable como color/text/primary.

Aunque en un proyecto pequeño algunos de estos valores sean iguales, nombrarlos por función ayuda a entender el diseño.

Un mismo color puede cumplir roles distintos. Puede ser el color principal de la marca, el color de acento para destacar elementos de la interfaz, el color de los enlaces o el color del anillo de foco. Visualmente puede ser el mismo valor, pero funcionalmente no está haciendo siempre lo mismo. Si lo nombras solo como blue, estás describiendo su apariencia. Si lo nombras como color/accent/primary, estás describiendo su función.

Para desarrollo, esa función suele ser más útil que el color exacto. 

Y para la IA también. Si Claude encuentra una variable llamada blue, puede saber qué valor tiene. Si encuentra color/accent/primary, entiende mejor qué papel cumple en la interfaz.

Espaciado: una escala suficiente

Con el espaciado pasa lo mismo.

No hace falta crear una escala enorme, pero sí conviene tener una escala clara. Por ejemplo:

• space/2xs → 0.25rem.
• space/xs → 0.5rem.
• space/s → 0.75rem.
• space/m → 1rem.
• space/l → 1.5rem.
• space/xl → 2rem.
• space/2xl → 3rem.

Lo importante es que los gaps y paddings principales respondan a una lógica común. Así, cuando el desarrollador vea un espacio entre cards, un padding de sección o una separación entre bloques, no tendrá que reconstruir el criterio desde cero.

También puedes documentar qué espaciados deben ser fluidos en CSS. Por ejemplo:

--space-section-y: clamp(3rem, 2rem + 5vw, 7rem);

Figma no puede aplicar ese clamp() como valor real de Auto Layout, porque necesita representar un número concreto en el lienzo. Pero puedes documentarlo en la descripción de la variable y en la página de documentación del archivo.

La idea es sencilla: en Figma se declaran los valores mínimo y máximo, en móvil y en escritorio respectivamente. Y en la documentación, se pone el CSS que hará falta para aplicar el comportamiento fluido.

Tipografía fluida: estilos y documentación

Los estilos de texto también deberían definirse por rol. Por ejemplo:

Si el proyecto usa tipografía fluida, puedes documentarlo igual que con el espaciado:

font-size: clamp(2rem, 4vw + 1rem, 4rem);

Figma tendrá un tamaño fijo para poder diseñar, pero el archivo puede indicar que ese estilo debe convertirse en una regla fluida en CSS.

Cómo se conecta esto con WordPress

Todo este sistema encaja bien con WordPress porque los estilos globales y el archivo theme.json también trabajan con presets y valores reutilizables.

La relación sería esta:

Variables de Figma → design tokens → CSS custom properties → theme.json → estilos disponibles en WordPress.

Una variable de Figma como color/brand/primary puede convertirse en un preset de color del tema.

Una escala de espaciado puede trasladarse a presets de spacing o a custom properties. Los estilos tipográficos pueden convertirse en presets de font size. Los valores fluidos documentados con clamp() pueden incorporarse al CSS del tema o a los estilos globales.

Crear componentes y sus variantes

El criterio para crear componentes no depende solo de si algo se repite visualmente, sino de si debe mantenerse de forma consistente en todos los lugares donde aparece. Cuando un cambio en ese elemento debería aplicarse también al resto de sus instancias, conviene convertirlo en componente.

En WordPress, esa misma lógica puede traducirse después en un bloque sincronizado, un patrón reutilizable o una parte del sistema de diseño del tema.

Algunos ejemplos claros de componentes en un proyecto WordPress:

Y estos son ejemplos típicos de variantes de un componente:

• Los estados de los botones. Un botón no existe solo en estado normal. Puede tener estado hover, focus, active, disabled, loading, etc.
• Un campo de formulario puede estar vacío, completado, en foco, con error o deshabilitado.
• Una card puede tener imagen o no tenerla.
• Un mensaje puede ser informativo, de error, de éxito o de advertencia.

Todos esos estados deberían formar parte del sistema de componentes, no aparecer como elementos sueltos en una página perdida del archivo.

Por ejemplo:

button/primary/default
button/primary/hover
button/primary/focus
button/primary/disabled
button/primary/loading

O en propiedades de componente:

type: primary | secondary | ghost
state: default | hover | focus | disabled | loading
icon: true | false

Esto ayuda al desarrollador porque le muestra qué estados existen y cómo deben resolverse. Y ayuda a la IA porque le permite entender que no está viendo cinco botones diferentes, sino cinco estados de un mismo componente.

En WordPress esto tiene una lectura adicional: muchas de estas decisiones terminan afectando a bloques, patrones o estilos globales. Cuanto mejor esté estructurado el componente en Figma, más fácil será trasladarlo a una implementación mantenible.

Añadir Auto Layout

Auto Layout es una de las funcionalidades más importantes de un archivo de Figma preparado para desarrollo. No solo porque ordena mejor el diseño y se trabaja mejor, sino porque comunica el comportamiento del componente.

Un grupo de elementos colocado manualmente dice dónde está cada cosa en un frame concreto. Un frame con Auto Layout dice cómo se relacionan los elementos entre sí: dirección, separación, alineación, relleno, crecimiento, ajuste al contenido y comportamiento cuando cambia el tamaño.

Esa información es muy útil para desarrollo.

Si un botón tiene Auto Layout, relleno horizontal y vertical definidos, y el texto está configurado en hug contents, el desarrollador entiende cómo debe crecer cuando el texto cambie. Si una card tiene Auto Layout vertical, relleno interno y una distribución definida como, por ejemplo, una separación fija entre elementos o space between para empujar el enlace al final, se entiende mejor cómo debe comportarse cuando el título ocupa dos líneas o la descripción es más larga.

En WordPress esto es especialmente importante porque el contenido rara vez es fijo.

Aunque en este artículo no vamos a entrar en detalle en cómo diseñar para contenido dinámico porque ya hablamos de eso en otro artículo, sí conviene recordar que WordPress trabaja con contenido editable: títulos, extractos, imágenes, productos, categorías, menús, formularios y traducciones. El diseño debe poder adaptarse a esa realidad.

En un proyecto WordPress, Auto Layout ayuda a traducir mejor el diseño a CSS Flexbox, Grid o estructuras de bloques. También ayuda a que una herramienta de IA entienda si una serie de elementos forma una columna, una fila, una lista, una card o una navegación.

La comprobación práctica es sencilla: antes de dar un componente por terminado, redimensiónalo. Cambia el texto. Prueba el caso incómodo. Si el componente se rompe en Figma, es probable que también genere dudas en desarrollo.

Diseñar las plantillas necesarias

WordPress funciona con plantillas: entradas, archivos, categorías, resultados de búsqueda, páginas de error, fichas de producto, checkout, áreas privadas o páginas generadas por plugins.

Por eso, una parte importante de preparar el archivo para desarrollo consiste en enumerar qué plantillas hay que crear.

No todas necesitan el mismo nivel de detalle visual. Algunas pueden estar completamente diseñadas y otras pueden resolverse con una estructura clara y las notas suficientes. Pero conviene que existan dentro del archivo, aunque sea como frames de referencia.

En un proyecto WordPress estándar, revisaría al menos estas:

Si el proyecto tiene WooCommerce, añadiría:

Si hay membresías, reservas, cursos, donaciones o cualquier funcionalidad específica, también conviene identificar las pantallas que genera el plugin correspondiente.

Por ejemplo:

• Página de acceso.
• Recuperación de contraseña.
• Área privada.
• Listado de reservas.
• Formulario de inscripción.
• Confirmación de envío.
• Mensaje de error.
• Estado vacío.
• Pantalla de acceso denegado.

Igual que nombrar las capas, nombrar correctamente las plantillas también ayuda al desarrollador y a la IA.

Un frame llamado Page 7 no dice nada. Un frame llamado template/single-post o template/product-single ya aporta más contexto. Si después le pides a Claude que revise el archivo, podrá entender mejor qué tipo de pantalla está analizando.

Preparar variaciones de estilo del tema

Si el diseño se va a implementar como un tema de bloques, también conviene pensar si habrá variaciones de estilo.

En WordPress, una variación de estilo es una alternativa visual del theme.json principal. Se guarda como un archivo JSON dentro de la carpeta /styles del tema y puede modificar colores, tipografía, espaciado, estilos de bloques u otras partes del sistema visual. En la práctica, permite que el usuario elija entre varias versiones visuales del mismo tema desde el editor del sitio.

En Figma, esto se puede preparar creando una página específica para variaciones de estilo. La clave es mantener los mismos nombres de tokens y cambiar sus valores según cada variación. Por ejemplo, color/background/default, color/text/primary o color/accent/primary deberían llamarse igual en todas las variaciones, aunque sus valores cambien.

Si usas variables de Figma, los modos para variables pueden ayudarte a representar esas alternativas: Base, Calm, Bold, Dark, etc. Así puedes aplicar la misma estructura visual a varias versiones del sistema sin duplicar todo desde cero.

Para cada variación, conviene documentar qué cambia y qué se mantiene: color, tipografía, espaciado, radios, estilos de botones o estilos de bloques. También es útil indicar el archivo previsto en WordPress, por ejemplo /styles/calm.json o /styles/theme/calm.json.

Además, conviene crear una pequeña muestra visual común para comparar variaciones: título, párrafo, enlace, botones, card, cita, formulario y algún bloque con fondo. Esa muestra permite comprobar legibilidad, contraste y coherencia antes de trasladar la variación a theme.json.

No hay que confundir estas variaciones globales con las variaciones de estilo de bloque. Las variaciones de bloque afectan a bloques concretos y en WordPress se aplican como una clase del tipo .is-style-{name}. En Figma, se pueden documentar como estilos alternativos de un mismo bloque: por ejemplo, group/section-muted, quote/editorial o card/boxed.

El objetivo es que el archivo de diseño no solo muestre una versión visual de la web, sino también las alternativas que WordPress tendrá que ofrecer dentro del sistema de estilos del tema.

Añadir anotaciones

Las anotaciones sirven para documentar todo aquello que una persona o una IA no puede deducir con seguridad solo mirando el diseño.

No hace falta anotar lo evidente. Si un botón dice «Enviar mensaje», no necesitas una nota que diga «botón para enviar el mensaje». Pero si ese botón queda deshabilitado hasta que se aceptan las condiciones legales, eso sí conviene explicarlo.

Algunos ejemplos de anotaciones útiles:

Puedes incluir las anotaciones en una página de documentación o junto al componente correspondiente.

Para trabajar con IA, lo más seguro es que las anotaciones estén como texto visible dentro del propio frame o en una zona de documentación claramente relacionada. Así el modelo puede leerlas como parte del contexto.

Las anotaciones no sustituyen una conversación con desarrollo, pero reducen mucho las zonas grises y que no se nos olvide nada. Y en proyectos donde interviene la IA, ayudan a que el modelo no tenga que completar el comportamiento a partir de patrones genéricos. Así, evitamos que alucine y se invente cosas por falta de contexto.

Una buena práctica es reunir toda la documentación en una página dedicada dentro del mismo archivo de Figma: 

• Sistema de color.
• Escala tipográfica.
• Espaciado.
• Especificaciones responsive.
• Notas de componentes.

Así el desarrollador la encuentra fácilmente, y el MCP puede leerla como contexto adicional al analizar el diseño.

De hecho, como vamos a ver ahora, también puedes pedirle a la IA que cree automáticamente todas estas anotaciones.

Automatizar tareas de revisión y documentación con Claude

Hay muchas tareas de preparación del archivo para handoff que se las podemos pedir a la IA, no tenemos que hacerlas a mano. 

Antes de entregar: revisar y mejorar el archivo

1. Que revise el archivo antes de entregarlo. Le puedes pedir que analice una selección o una pantalla completa y liste lo que falte: capas sin nombre, componentes que son copias en lugar de instancias, estados no definidos, variables no aplicadas o anotaciones insuficientes.

2. Que compare plantillas e identifique inconsistencias. Si tienes varias plantillas diseñadas, Claude puede cruzarlas y detectar diferencias que a ojo se escapan: un espaciado distinto entre secciones similares o una decisión tipográfica que no es consistente entre páginas.

3. Que detecte qué componentes deberían ser patrones reutilizables. A partir de las plantillas del archivo, puede identificar qué elementos aparecen en más de un contexto y deberían estar en la librería compartida como componentes para implementarse como patrones de WordPress, en lugar de repetirse como piezas independientes.

4. Que organice los componentes por secciones y documente sus variantes y estados. Si tienes componentes dispersos por el archivo o un poco desordenados (que suele ser lo normal cuando has estado trabajando mucho en un archivo complejo), Claude puede proponer una estructura de librería: qué agrupar en una sección de navegación, qué en formularios, qué en cards, qué en feedback. Y para cada componente, listar las variantes y estados que deberían existir.

5. Que genere los estados de los botones teniendo en cuenta el sistema de color. A partir de los tokens de color del archivo, puede proponer los valores concretos para cada estado: default, hover, focus, active, disabled. Claude puede usar los colores del sistema para crear todos los estados de los botones, que son un poco tediosos de diseñar y, además, se suele necesitar versión para escritorio y versión para móvil, así que es una tarea muy candidata a la automatización.

Para el handoff: documentación y especificaciones

6. Que genere la especificación técnica de un componente. Para cada componente puedes pedirle una ficha completa: estructura HTML sugerida, campos de contenido, estados, comportamiento responsive, tokens aplicados y consideraciones de implementación en WordPress.

7. Que especifique los patrones de adaptación responsive Escritorio → Móvil. Le puedes pedir que documente cómo debería comportarse cada sección al cambiar de breakpoint: qué columnas colapsan, qué elementos se ocultan, cómo cambia la escala de la tipografía, qué espaciados se reducen. Claude, a la vista de tus frames de escritorio y móvil, interpreta el patrón y lo redacta de manera comprensible para el desarrollador. Por ejemplo: «En escritorio, los contenidos se distribuyen en 2 columnas (de lado a lado). En móvil, esas columnas se apilan en 1 columna» o «En móvil, la imagen va siempre encima del texto, salvo excepción explícita».

8. Que documente el sistema de color con roles semánticos y valores CSS. A partir de las variables de color del archivo, puede generar una tabla completa con el nombre del token, su rol, el valor hexadecimal y la custom property CSS correspondiente. Lista para entregar a desarrollo o para escribir directamente el código para theme.json.

9. Que genere la escala tipográfica fluida con los valores de clamp(). Claude puede extraer los valores de tamaño de fuente y tamaño de frame de escritorio y móvil y con esos valores puede generar la escala completa con las fórmulas de clamp() para cada nivel: H1, H2, H3, body, caption, etc., lista para trasladar directamente a CSS o a theme.json.

10. Que documente la escala de espaciado con los valores en rem. A partir de las variables de espaciado del archivo, puede generar la tabla de tokens: nombre, valor en rem y custom property CSS. Con una nota sobre cómo aplicar cada nivel en el sistema de bloques de WordPress.

11. Que genere la estructura de theme.json o las custom properties. Con las variables del archivo bien definidas, puede proponer el bloque de settings de theme.json con los presets de color, tipografía y espaciado, o el conjunto de propiedades CSS del tema, como código funcional que el desarrollador puede revisar y usar directamente.

12. Que proponga la arquitectura de bloques o patrones para WordPress. A partir del diseño completo, puede sugerir qué partes deberían ser bloques nativos, qué debería convertirse en patrones sincronizados, qué en partes de plantilla y qué en bloques personalizados. Si le das el contexto de cómo se va a implementar la web, Claude puede hacer una lectura del diseño desde la arquitectura de WordPress. Por ejemplo, le tienes que indicar con qué tema o constructor visual se va implementar, con qué plugins, si es un tema a medida o si se va a utilizar un framework concreto, etc.

Diseñar para WordPress hasta el final

Preparar un archivo de Figma para desarrollo en WordPress consiste en dejar dentro del archivo la información que otra persona necesita para construir el diseño en WordPress. No hace falta documentarlo todo, pero sí lo que vaya a facilitar el trabajo de implementación.

En WordPress, esa claridad es especialmente importante porque el diseño no vive en pantallas estáticas. Se convierte en plantillas, bloques, patrones, estilos globales, contenido editable y componentes que tendrán que mantenerse en el tiempo.

Y cuando la IA entra en el proceso, es aún más importante que lo dejemos todo claro.

La IA puede completar huecos, pero lo hará a partir de patrones generales, no necesariamente desde las decisiones concretas de tu proyecto. Así que cuanto más claro sea el archivo, menos tendrá que adivinar y más útil será el resultado.

Nombrar capas, definir variables, estructurar componentes, usar Auto Layout, documentar plantillas y añadir anotaciones son tareas cruciales en el proceso de diseño.

Porque diseñar para WordPress también incluye allanar el terreno para que pueda construirse bien.