El handoff es la entrega del diseño al equipo de desarrollo: el archivo, los estilos, los recursos y las indicaciones necesarias para convertir un diseño en una web real. Cuando está bien preparado, la maquetación en WordPress es fiel, rápida y sin idas y vueltas. Cuando no lo está, quien maqueta tiene que interpretar, y ahí empiezan los problemas.
Por qué el handoff decide el resultado de la maquetación
Un diseño en Figma es una imagen estática de cómo debería verse la web en unas condiciones concretas. Una web real tiene que funcionar en decenas de tamaños de pantalla, con contenidos que cambian, con estados interactivos y con un gestor de contenidos que el cliente va a usar después. Todo lo que el diseño no define, alguien lo tendrá que decidir durante la maquetación.
Si esas decisiones las toma quien desarrolla sin criterio de diseño, o con prisa, el resultado se aleja del original. Si se resuelven a base de preguntas y correcciones, el proyecto se alarga y el presupuesto sufre.
Qué ocurre cuando el handoff es incompleto
- La versión móvil se improvisa durante la maquetación.
- Los espaciados y tamaños de texto varían de una página a otra.
- Faltan estados como hover, foco, errores de formulario o mensajes de confirmación.
- Los textos reales no caben en el espacio pensado para los textos de relleno.
- Las imágenes llegan en tamaños o formatos poco adecuados para web.
- Aparecen funcionalidades que nadie había previsto ni presupuestado.
Qué debe incluir un handoff de diseño para WordPress
Un buen handoff no se limita a compartir el enlace de Figma. Estos son los elementos que marcan la diferencia en una maquetación con WordPress y Elementor.
Un archivo de diseño ordenado
El primer requisito es que el archivo se pueda entender sin que el diseñador esté al lado explicándolo.
Páginas y frames con nombres claros
Cada página del diseño debe tener un nombre que coincida con la página de la web: Inicio, Servicios, Contacto, Entrada de blog. Las versiones descartadas, las pruebas y los borradores deben estar separados o eliminados, y debe quedar claro cuál es la versión aprobada.
Componentes y variantes
Botones, tarjetas, cabeceras, formularios y bloques que se repiten deben estar creados como componentes, con sus variantes. Esto facilita traducirlos después a widgets globales, plantillas guardadas o bloques reutilizables en WordPress, y evita que cada página tenga su propia versión ligeramente distinta del mismo elemento.
Un sistema de estilos globales
Es la parte que más horas ahorra durante la maquetación y la que más se descuida.
Tipografías
El diseño debe definir una escala tipográfica clara: tamaños, pesos e interlineados para cada nivel de encabezado, párrafos, botones y textos secundarios, tanto en escritorio como en móvil. También hay que confirmar que las fuentes tienen licencia para uso web y disponer de los archivos si no son de Google Fonts.
Colores
La paleta debe estar recogida como estilos con nombre, indicando su uso: color principal, secundario, fondos, textos, bordes, estados de éxito y error. Conviene revisar el contraste de las combinaciones texto-fondo antes de entregar, no después.
Espaciados y rejilla
El ancho máximo del contenido, las columnas, los márgenes laterales y una escala de espaciados coherente evitan que cada sección tenga medidas arbitrarias. En Elementor, estos valores se trasladan a los ajustes del sitio y a los contenedores, y se aplican de forma consistente en toda la web.
Versiones responsive
Como mínimo, el diseño debe incluir escritorio y móvil para cada plantilla de página, y tablet en los casos donde la composición cambie de forma relevante. Hay que definir cómo se comporta el menú, cómo se reordenan las columnas, qué elementos se ocultan y cómo se adaptan tablas y formularios. Para profundizar en este punto, revisa nuestra guía sobre usabilidad en dispositivos móviles y cómo optimizar el diseño.
Estados e interacciones
Un diseño estático no muestra cómo reacciona la interfaz. El handoff debe incluir, al menos:
- Estados hover y foco de botones, enlaces y tarjetas.
- Menú desplegado en escritorio y menú móvil abierto.
- Errores de validación, mensajes de éxito y estados de carga en formularios.
- Estados vacíos, como un listado sin resultados o un buscador sin coincidencias.
- Animaciones o transiciones, con una indicación de su comportamiento.
Contenidos reales o muy aproximados
Maquetar con textos de relleno es una de las principales fuentes de retrabajo. Un titular real puede ocupar el doble que el de ejemplo y romper una tarjeta o una cabecera. Lo ideal es entregar los textos definitivos. Si no es posible, al menos textos con una extensión realista y una jerarquía de encabezados ya decidida.
Recursos exportables
Imágenes, iconos, logotipos e ilustraciones deben estar disponibles en el formato adecuado:
- Logotipos e iconos en SVG, limpios y sin elementos ocultos.
- Fotografías en alta resolución para poder optimizarlas después en el tamaño y formato que necesite la web.
- Favicon e imagen para compartir en redes sociales.
- Indicación de qué imágenes son decorativas y cuáles necesitan texto alternativo.
Funcionalidades y comportamiento
Todo lo que no se ve en el diseño pero la web debe hacer tiene que quedar por escrito: a dónde se envían los formularios, qué campos son obligatorios, cómo se filtra un listado, qué contenido gestionará el cliente y cuál será fijo, o con qué herramientas debe conectarse la web. Esta información define la arquitectura técnica, y permite decidir qué resolver con desarrollo propio en lugar de acumular extensiones. Es el enfoque que explicamos en cómo adaptar WordPress a necesidades específicas sin depender de 20 plugins.
Requisitos de SEO
El diseño condiciona el SEO más de lo que parece. El handoff debe dejar clara la jerarquía de encabezados de cada página, la estructura de URLs, los textos que deben ser texto real y no imagen, y las páginas que necesitan datos estructurados. Para revisarlo durante la maquetación, puedes apoyarte en nuestro checklist de SEO técnico para webs con Elementor y WordPress.
Handoff mínimo frente a handoff completo
| Elemento | Handoff mínimo | Handoff completo |
|---|---|---|
| Archivo de diseño | Enlace a Figma | Archivo ordenado, con versión aprobada clara |
| Estilos | Se deducen inspeccionando | Tipografías, colores y espaciados como estilos globales |
| Componentes | Elementos sueltos en cada página | Componentes con variantes |
| Responsive | Solo escritorio | Escritorio, móvil y tablet cuando hace falta |
| Estados | No definidos | Hover, foco, errores, éxito, vacíos y menús |
| Contenidos | Texto de relleno | Textos reales y jerarquía de encabezados |
| Recursos | Se exportan sobre la marcha | SVG, imágenes en alta, favicon e indicaciones de texto alternativo |
| Funcionalidades | Se descubren durante el desarrollo | Documentadas antes de empezar |
| Resultado habitual | Interpretaciones, correcciones y retrasos | Maquetación fiel y plazos previsibles |
Cómo se traduce el handoff a WordPress y Elementor
Un handoff bien preparado no solo sirve para copiar medidas. Permite construir una web ordenada y fácil de mantener.
Estilos globales del constructor
Los colores y tipografías definidos en Figma se trasladan a los colores y fuentes globales de Elementor, o a los estilos globales del tema si se trabaja con bloques. Así, cualquier cambio posterior de marca se aplica desde un único lugar y no página por página.
Plantillas y elementos reutilizables
Los componentes del diseño se convierten en plantillas de cabecera, pie y entradas con el Theme Builder, o en bloques guardados y widgets globales. Cuanto más ordenado esté el sistema de componentes en Figma, más limpia será la estructura en WordPress.
Contenido dinámico
Cuando el diseño incluye listados como proyectos, servicios, equipo o casos de éxito, el handoff permite identificarlos y planificarlos como tipos de contenido personalizados con campos ACF. El cliente podrá añadir nuevos elementos sin tocar el diseño.
Si quieres ver este proceso aplicado en un proyecto real, te contamos cómo transformamos un diseño en Figma en una web a medida con WordPress y Elementor.
Errores habituales en el handoff
- Entregar solo el diseño de la home y esperar que el resto de páginas «se deduzcan».
- Diseñar con medidas sueltas, sin escala tipográfica ni de espaciados.
- Usar fuentes sin licencia web o efectos que no se pueden reproducir en navegador sin penalizar el rendimiento.
- Olvidar los textos legales, el banner de cookies o la página de error 404.
- Diseñar pensando en cómo se verá en un portfolio, no en cómo se usará.
- Cambiar el diseño una vez empezada la maquetación sin revisar el alcance.
El penúltimo punto merece atención. Un diseño espectacular en una presentación no garantiza una web que funcione, como explicamos en por qué una web bonita no siempre es una buena web.
Checklist de handoff antes de empezar a maquetar
- Versión aprobada del diseño identificada y archivo ordenado.
- Estilos de color y tipografía definidos como estilos globales.
- Escala de espaciados, ancho máximo y rejilla documentados.
- Componentes repetidos creados con sus variantes.
- Versiones móvil y, si hace falta, tablet de cada plantilla de página.
- Estados interactivos y mensajes de formulario diseñados.
- Textos reales o con extensión realista y jerarquía de encabezados.
- Recursos exportados en formatos adecuados y licencias de fuentes confirmadas.
- Funcionalidades, integraciones y contenidos editables documentados.
- Reunión de traspaso entre diseño y desarrollo para resolver dudas.
Cada hora invertida en preparar bien el handoff ahorra varias de correcciones durante la maquetación. Y, sobre todo, evita que el cliente reciba una web que no se parece a lo que aprobó.
Herramientas como el modo de inspección para desarrolladores de Figma facilitan consultar medidas y exportar recursos [ENLACE PENDIENTE: Figma, documentación de Dev Mode], pero no sustituyen a un archivo bien estructurado ni a las decisiones que el diseño debe dejar tomadas.
Preguntas frecuentes
¿Qué herramienta es mejor para hacer el handoff de diseño?
La herramienta importa menos que el orden del archivo. Figma es la más extendida porque permite inspeccionar medidas, exportar recursos y dejar comentarios en el propio diseño. Lo realmente decisivo es que los estilos, los componentes, las versiones responsive y las notas de comportamiento estén definidos y sean fáciles de encontrar.
¿Es obligatorio diseñar la versión móvil antes de maquetar?
No es obligatorio, pero sí muy recomendable. Si el diseño solo incluye escritorio, quien maqueta tendrá que decidir cómo se reorganizan columnas, menús, tablas o formularios en pantallas pequeñas. Esas decisiones afectan a la experiencia y a la conversión, así que conviene tomarlas en la fase de diseño.
¿Se puede maquetar con textos de relleno y cambiarlos después?
Se puede, pero suele generar retrabajo. Los textos reales cambian la longitud de los titulares, el alto de las tarjetas y el equilibrio de cada sección. Si el contenido definitivo no está listo, al menos conviene usar textos con una extensión parecida a la real y definir la jerarquía de encabezados.
¿Quién debe preparar el handoff, el diseñador o el desarrollador?
La responsabilidad principal es de quien diseña, pero el mejor resultado sale cuando ambos lo revisan juntos antes de empezar. Una reunión breve para recorrer el diseño, resolver dudas y detectar elementos difíciles de implementar en WordPress ahorra muchas horas de correcciones durante la maquetación.
¿Qué pasa si el diseño usa fuentes que no tienen licencia web?
Antes de maquetar hay que confirmar que la tipografía puede usarse en web y en qué condiciones. Si no tiene licencia web, habrá que comprarla o sustituirla por una alternativa similar. Lo ideal es alojar las fuentes en el propio servidor, en formato WOFF2, para mejorar rendimiento y privacidad.