Figma → WordPress: dónde falla la implementación y qué devuelvo PM
Wordpress
Viernes por la tarde. El project manager escribe contento: «¡El cliente ha aprobado el diseño! El archivo de Figma es perfecto, puedes empezar a maquetar. Es todo sencillo».
Abro el enlace, echo un vistazo a las páginas y lo entiendo: aún falta mucho para la primera línea de código. Un diseño perfecto para el cliente suele estar lleno de agujeros técnicos.
Como desarrollador WordPress, podría inventar lo que falta sobre la marcha o entregar «lo que salga». Ese enfoque siempre acaba en revisiones infinitas y en salirse del presupuesto. En su lugar, detengo el proceso y devuelvo el archivo al PM con feedback detallado.
Estos son los 4 puntos donde más se rompe el paso de Figma a WordPress, y las preguntas que hago antes de empezar.
1. Falta de estados (States)
A los diseñadores les gusta dibujar el «camino feliz» (happy path), donde todo se ve estático e ideal. Pero un sitio web es un organismo vivo.
Lo que suele olvidarse:
¿Cómo se ve un botón en hover, active o disabled?
¿Cómo se ve un campo si el usuario introduce datos incorrectos (error state)?
¿Qué ocurre con un menú desplegable (dropdown) cuando está abierto?
¿Cómo se ve un formulario tras enviarlo si falla la validación?
Lo que escribo al PM:
«Por favor, pide al diseñador un UI kit con estados de botones y formularios, para que yo no invente los colores durante la maquetación. Si no, en testing saldrán sorpresas que habrá que corregir con prisas».
2. Versión móvil: «Bueno, ahí los bloques van uno debajo de otro»
La adaptabilidad no es solo estrechar la pantalla. Los problemas más frecuentes aparecen entre el escritorio (1440px) y el móvil (375px), es decir, en tablets (768px–1024px).
Pero incluso en la versión móvil suelen esconderse sorpresas:
Menú móvil (hamburguesa). Hay un icono de hamburguesa, pero no hay diseño del menú abierto. ¿Ocupa toda la pantalla? ¿Dónde están los contactos? ¿Qué animación de apertura tiene?
Tablas. Una tabla enorme de precios en escritorio. ¿Cómo debe hacer scroll o transformarse en el móvil? ¿Hay una vista alternativa (tarjetas en lugar de filas)?
Cabecera fija (sticky header). ¿Se queda la cabecera al hacer scroll en móvil? Si es así, ¿no se come media pantalla?
Lo que escribo al PM:
«En el archivo falta una versión móvil completa de los bloques clave. Necesito ver al menos los estados principales a 768px y 375px; si no, inventaré el comportamiento yo y luego lo corregiremos juntos en testing».
3. Caos en márgenes y tipografía (falta de sistema)
La calidad de un diseño se comprueba fácil mirando cómo se usan los estilos. Si en el archivo hay 15 tamaños distintos de texto normal (14px, 15px, 16px, 17px…) — eso no es un design system, es caos.
Lo mismo con los márgenes. Si entre bloques iguales el espacio salta de 23px a 27px, el desarrollador tiene dos opciones:
Escribir CSS único para cada bloque (lo que hincha el código y ralentiza el sitio).
Unificar todo en un sistema (por ejemplo a 24px), pero entonces el resultado no será «pixel-perfect».
Lo que escribo al PM:
«En el archivo no hay una rejilla ni estilos de texto unificados. Voy a estandarizar márgenes y tipografía en múltiplos de 4/8px para optimizar el rendimiento. Avísale al cliente: visualmente la diferencia será mínima, y el sitio irá más rápido y estable».
4. Páginas ocultas y lógica olvidada
Los clientes compran la home y las páginas de servicios, pero olvidan lo sistémico, sin lo cual un sitio WordPress no puede vivir del todo.
Lo que busco y a menudo no encuentro:
Página 404. ¿Adónde llega el usuario si sigue un enlace roto?
Thank You Page / pop-ups. ¿Qué ve alguien tras enviar un formulario con éxito?
Empty states (estados vacíos). ¿Cómo se ve el blog si aún no hay artículos? ¿O los resultados de búsqueda si no hay nada?
Páginas de error del sistema. ¿Qué mostramos si el servidor no responde o algo falla al cargar?
Lo que escribo al PM:
«En el archivo faltan páginas de sistema y estados vacíos. Sin ellas el sitio funcionará a nivel técnico, pero en testing y tras el lanzamiento habrá preguntas de usuarios y de buscadores. Encarguemos ya estos diseños».
Qué le devuelvo al PM tras auditar el diseño
Cuando digo «devuelvo el archivo», no es solo «hay problemas». Preparo un feedback estructurado para que el PM y el cliente decidan qué dejar, qué simplificar y qué sacar a fases aparte.
1. Lista de riesgos y «cuellos de botella»
Detalle puntos concretos donde la implementación puede salirse del plan:
Bloques difíciles de editar en WordPress sin herramientas extra.
Escenarios sin estados responsive o de error.
Elementos que requieren lógica custom (filtros no estándar, calculadoras complejas).
No es «crítica al diseño», sino un mapa de riesgos para que el PM hable prioridades con el cliente: dónde conviene pagar por la complejidad y dónde es mejor simplificar.
2. Propuestas de simplificación sin perder la idea
A menudo se puede mantener la intención visual y hacer la entrega más simple:
En lugar de 10 secciones únicas — 3–4 bloques plantilla con distintos ajustes.
En lugar de una animación compleja — una microinteracción ligera que no se rompe al cambiar el contenido.
En lugar de una rejilla única por página — un solo sistema de márgenes y columnas.
Muestro cómo afecta a:
Presupuesto — menos horas de maquetación e integración.
Mantenimiento — más fácil añadir contenido nuevo sin desarrollador.
Estabilidad — menos código custom que retestear en cada actualización.
3. Qué se edita fácil en WP y qué conviene dejar fijo
Una de las partes más importantes del feedback es el límite:
Fácil de editar: textos, imágenes, bloques simples (ventajas, reseñas, casos, secciones básicas de servicios).
Mejor fijo: bloques técnicos complejos, integraciones concretas, cosas que el cliente casi seguro no cambiará solo.
Así se evita que el cliente espere «cambiarlo todo como en un constructor» cuando la mitad del sitio sigue necesitando un desarrollador.
Ejemplo de un proyecto real
Como ilustración — un escenario típico de tienda/catálogo, similar a proyectos con los que trabajo.
Qué había en el diseño:
Tarjetas de producto con nombres y descripciones idénticos.
Filtros mostrados solo en estado «relleno».
Rejilla de productos dibujada para 8–12 tarjetas, sin escenarios «muchos / pocos productos».
Qué apareció al implementarlo:
Los nombres reales eran mucho más largos y rompían la rejilla.
Los filtros vacíos parecían un «error», porque no estaba definido qué mostrar si no hay nada seleccionado.
Algunos bloques del catálogo eran únicos por categoría, cuando 1–2 plantillas habrían bastado.
Qué propuse:
Unificar la tarjeta de producto: una estructura, distinto contenido, límites claros de título y descripción.
Definir estados de filtros: vacío, «nada encontrado» y 1–2 parámetros seleccionados.
En lugar de 5 plantillas únicas de categoría — 2 variantes principales (con y sin columna de filtros) que cubren ~90% de los casos.
Resultado: menos plantillas únicas, mantenimiento más simple, y el cliente puede añadir categorías sin llamar al desarrollador cada vez.
Checklist «Figma before handoff»
Tras la auditoría preparo un checklist corto para diseñador/PM, para que los siguientes archivos sean más fáciles de implementar.
Componentes:
Todos los bloques repetidos están como componentes/variantes.
Los nombres son claros («Product Card», «Service Block», «FAQ Item»).
Responsive:
Hay variantes para escritorio, tablet y móvil.
Se muestran los puntos de ruptura clave (menú, rejillas de tarjetas, formularios).
Estados de contenido:
Títulos largos/cortos, distinto número de tarjetas.
Estados vacíos (sin productos/servicios), errores, carga.
Lógica de bloques:
Queda claro qué bloques son plantilla y cuáles únicos.
Hay límites: longitud máxima de texto, número de elementos, tamaños de imagen.
Ese checklist ahorra tiempo a ambos lados: menos rondas de «vamos a redibujar esto».
Por qué mi «no» es cuidado del proyecto (y del presupuesto)
Devolver al PM un archivo con preguntas puede parecer un retraso. En realidad ahorra decenas de horas en la fase de testing.
Cuando la implementación se rompe por diseños incompletos, siempre hay:
Horas extra acordando «cómo debe funcionar esto».
Más iteraciones de maquetación, inventando estados sobre la marcha.
Riesgo de tirar parte del trabajo cuando el cliente ve el contenido real y pide rehacerlo.
Cuantas más preguntas hace el desarrollador «antes de entrar al agua», menos bugs e inconsistencias llegan a producción. No trabajo como un ejecutor ciego: trabajo como ingeniero, para que el sitio de marketing sea no solo bonito, sino también estable, rápido y fácil de mantener.
¿Listo para convertir tu diseño en un sitio rápido y fiable?
Si ya tienes un archivo en Figma, envíamelo. Revisaré gratis su preparación técnica para WordPress y te daré una estimación honesta del alcance.
No te obliga a colaborar — pero sí ayuda a evitar gastos inesperados y correcciones de sorpresa cuando el desarrollo ya ha empezado.
Preguntas habituales sobre trabajo en WordPress y soporte continuo.
¿Es necesario tener un kit de interfaz de usuario completo con estados antes de comenzar el diseño?
Idealmente, sí. Si no hay un kit de interfaz de usuario, puedo empezar, pero tendré que inventar algunos estados (al pasar el ratón por encima, activo, error) y podrían surgir imprevistos durante la fase de pruebas. Por lo tanto, es mejor pedirle al diseñador que añada al menos los estados básicos de los botones y formularios; esto ahorra tiempo y ediciones posteriores.
¿Qué ocurre si el cliente no quiere crear una versión móvil de todos los bloques?
Lo mínimo indispensable es: página de inicio, páginas de destino/servicios clave, formularios y catálogo (si lo hay). Sin esto, habrá problemas en dispositivos móviles que deberán corregirse con urgencia. Si el presupuesto es limitado, es mejor crear menos páginas, pero completas, que todas incompletas.
¿Estás preparado para trabajar con diseños donde no haya páginas del sistema (404, Gracias, estados vacíos)?
Sí, pero te advierto de inmediato sobre los riesgos. Sin una página de error 404, una página de agradecimiento ni páginas vacías, el sitio funcionará técnicamente, pero durante las pruebas y después del lanzamiento surgirán dudas por parte de los usuarios y los motores de búsqueda. Por lo tanto, recomiendo solicitar al menos las versiones básicas de estas páginas de inmediato, aunque sean sencillas.
¿Significa su auditoría que el diseño es "malo"?
No. Una auditoría no es una evaluación de "bueno/malo", sino una verificación de la preparación técnica para la implementación. El diseño puede ser visualmente excelente, pero sin estados predefinidos, adaptabilidad y lógica de bloques, su implementación será costosa e inconveniente. Mi tarea consiste en identificar los riesgos y cómo mitigarlos antes de comenzar el desarrollo.
¿Con qué tipos de sitios WordPress trabajas?
Trabajo con sitios WordPress para negocios, tiendas WooCommerce y proyectos que necesitan crecer paso a paso, sin complejidad innecesaria ni soluciones frágiles. Sirve tanto para lanzamientos nuevos como para sitios existentes que necesitan mejoras, soporte o actualizaciones técnicas cuidadosas.
¿Puedes mejorar un sitio existente sin un rediseño completo?
Sí. La mayoría de tareas implican sitios ya en producción: nuevas secciones, mejoras funcionales, cambios en WooCommerce, optimización del rendimiento o correcciones técnicas. La idea es que el sitio siga siendo estable, manejable y fácil de desarrollar.
¿Qué tipos de tareas asumes con más frecuencia?
Lo más habitual es desarrollo WordPress a medida, implementación de diseño desde Figma, mejoras en WooCommerce, soporte de sitios en producción, corrección de problemas técnicos y mejoras prácticas con el tiempo. En casos seleccionados también ayudo con automatizaciones ligeras con IA para contenido, consultas o flujos internos de administración.
¿Trabajas en la velocidad y el rendimiento de WordPress?
Sí. La optimización de WordPress suele incluir revisar el tema, los plugins, las imágenes, las fuentes, la estructura de las páginas y la pulcritud técnica general del sitio. El objetivo no es un «botón mágico», sino cambios prácticos que hagan el sitio más rápido y más fácil de mantener.
¿Utilizas IA en el trabajo con sitios WordPress?
Sí, pero solo donde realmente ayuda al proceso. La IA funciona mejor para borradores de contenido, asistentes de FAQ o soporte, gestión de consultas y pequeñas automatizaciones en torno a un sitio WordPress existente. El enfoque es simple: la IA debe reducir la rutina, no complicar el sitio.
¿Qué necesito preparar para hablar de una tarea o proyecto?
Por lo general basta con una breve descripción del sitio, la tarea, el resultado deseado y, si los hay, ejemplos o limitaciones técnicas. Si el proyecto ya está en marcha, también ayuda mostrar el sitio actual o un entorno de pruebas; así es más fácil entender el alcance del trabajo.
¿Puedo contactarte no para un sitio nuevo, sino para soporte o mejoras puntuales?
Sí. Trabajo no solo en nuevas instalaciones, sino también en sitios en producción que necesitan mantenimiento, correcciones y mejoras graduales. Puede tratarse de páginas nuevas, cambios en el panel de administración, mejoras en WooCommerce, pequeños ajustes de UX o mantenimiento técnico.
¿Necesitas ayuda con un proyecto WordPress?
Si necesitas desarrollo WordPress a medida, implementación de diseño o soporte para un sitio existente, revisaré el proyecto con gusto.
