De Figma a WordPress: cómo se convierte un diseño en una web que funciona

Un diseño en Figma se ve perfecto. Cada espacio está medido, el texto cabe justo y las imágenes tienen la proporción exacta. Luego llega a WordPress y empiezan las preguntas: ¿qué pasa si el título del cliente ocupa tres líneas en vez de dos? ¿Cómo se ve esto en un móvil que no está en el archivo? ¿Quién va a editar esta sección dentro de seis meses?

Llevo años pasando diseños de Figma a WordPress, y casi todos los problemas que veo vienen de lo mismo: se trata la web como una captura de pantalla que hay que copiar, cuando en realidad es algo vivo que va a cambiar. Esto es lo que he aprendido sobre cómo hacerlo bien.

Una web no es un PDF

Figma muestra una página con un contenido concreto, en un ancho concreto. WordPress va a recibir contenido que cambia, textos más largos o más cortos, imágenes de otras proporciones y personas que no son diseñadoras tocando todo.

Por eso “fiel al diseño” no significa copiar píxeles. Significa respetar el sistema: las tipografías, los espaciados, los colores, la jerarquía, el carácter de la marca. Y que ese sistema aguante cuando la realidad no se parece a la maqueta.

Qué ayuda mucho que traiga el archivo de Figma

Si eres diseñador o agencia, estas cosas me ahorran idas y venidas (y a ti también):

• Versión móvil, como mínimo. Si solo hay escritorio, alguien tendrá que inventar el móvil, y casi siempre ese alguien acaba siendo quien desarrolla. Mejor que lo decida quien diseñó.
• Estilos y componentes bien nombrados. Colores, tipografías y botones definidos una vez y reutilizados. Si cada botón es una variante dibujada a mano, hay que adivinar cuál es el bueno.
• Estados de los elementos. Cómo se ve un botón al pasar el ratón, un campo con error, un menú abierto. Lo que no está en el archivo se improvisa.
• Contenido real, o lo más parecido. Un “Lorem ipsum” corto engaña. Un título de verdad, largo, deja ver si el diseño aguanta.
• Imágenes e iconos exportables, con su licencia clara si no son tuyos.

No hace falta que todo esté perfecto. Pero cuanto más completo sea el archivo, menos decisiones se toman a ciegas.

Qué pasa en el camino

Primero se revisa el diseño, antes de tocar WordPress

Antes de desarrollar, recorro el archivo entero: páginas, componentes, versiones responsive. Anoto lo que falta, lo que es ambiguo y lo que será difícil de editar. Es mucho más barato resolverlo en esta fase que con la web a medio montar.

Se construye con un constructor, pero con criterio

Trabajo sobre todo con Bricks Builder y Elementor. Los dos permiten reproducir un diseño con bastante precisión, y la diferencia está en cómo se usan: clases y estilos globales en vez de ajustes sueltos en cada elemento, secciones reutilizables, estructura limpia. Una web hecha así se puede editar sin que se rompa nada. Una hecha a base de parches, no.

Lo que casi siempre se ajusta

Hay cosas que cambian entre Figma y la web, y está bien que cambien:

• Los tamaños intermedios. Figma suele tener un escritorio grande y un móvil. La web existe también en tablets, portátiles pequeños y pantallas enormes. Hay que decidir cómo se comporta el diseño entre esos puntos.
• Los textos largos. Si un título crece, el diseño tiene que aguantarlo sin romperse.
• Las animaciones. Un prototipo de Figma puede insinuar movimientos que en la web hay que traducir con cuidado, para no sacrificar velocidad.
• Lo que debe poder editar el cliente. Un texto que en el diseño es “parte de la imagen” quizá deba ser texto real, editable y legible para Google.

Se compara con el diseño en varios tamaños

Al final pongo el resultado al lado de Figma y lo reviso en distintas anchuras de pantalla, no solo en las dos del archivo. Es ahí donde aparecen los detalles que ninguna maqueta recoge.

Errores que veo una y otra vez

1. Implementar sin revisar el diseño. Los problemas aparecen igual, pero más tarde y más caros.
2. Ajustar todo a mano. Un margen cambiado aquí, otro allá, y a los tres meses nadie sabe por qué la web se comporta raro.
3. Ignorar el rendimiento. Una web que se ve igual que el diseño pero tarda cinco segundos en cargar no ha cumplido su trabajo. Imágenes bien dimensionadas y poco código sobrante importan tanto como la fidelidad visual. Si te interesa ese tema, te cuento más en por qué una web WordPress es lenta.
4. No pensar en quién la va a editar. Si el cliente necesita llamar al desarrollador para cambiar un teléfono, algo se hizo mal.
5. Añadir cambios de diseño por el camino sin hablarlo. Pasa, y es normal, pero conviene decidir si entran en el alcance o se tratan aparte.

¿Cuánto cuesta?

Depende de cuántas páginas haya, de lo complejas que sean y de cuánto trabajo de interacción, formularios o contenido dinámico lleven. Trabajo a precio fijo: tras revisar el archivo te propongo un importe cerrado por escrito, para que sepas desde el principio lo que vas a pagar. Si quieres una idea orientativa antes de escribirme, tienes los rangos y un simulador de presupuesto en la página de precios.

Un ejemplo real

En Eatonville Rising desarrollé en Elementor los diseños en Figma de una agencia. Puedes ver cómo quedó la web publicada junto con capturas del archivo original.

Si ya tienes el diseño

Si tienes un archivo de Figma y quieres llevarlo a WordPress, cuéntame en qué punto está y, si puedes, pásame el enlace. Lo reviso antes de responderte y te digo con franqueza qué veo, qué falta y cuánto costaría. Puedes ver cómo trabajo en la página de Figma a WordPress.