Cómo pasar un diseño en JPG a una web pixel perfect en WordPress

La mayoría de los tutoriales de «diseño a WordPress» asumen que el diseñador te entrega un archivo de Figma con capas, medidas y tipografías. En la práctica, muchas veces lo que llega es una imagen. Coloriza Barrio Seguro, un programa de arte urbano para jóvenes de Lima Norte, nos entregó su web así: un JPG largo con todo el diseño, y la expectativa razonable de que la web se viera igual. Este es el proceso que seguimos para que así fuera, con los problemas reales que aparecieron y las reglas que nos quedaron para la próxima.

Primero entender qué hay en la imagen

Un JPG no tiene medidas, ni colores exactos, ni nombres de fuente. Lo primero fue leerlo como lo leería un desarrollador: secciones, jerarquía de títulos, qué elementos se repiten y cuáles son únicos. En el diseño de Coloriza había cinco bloques: un hero con collage de fotos y cifras, el ciclo de valor del programa en tres tarjetas, la convocatoria con fecha de cierre, los planes para apadrinar talento y una sección de preguntas frecuentes.

De la imagen salieron tres cosas que luego fueron decisiones:

• La paleta: amarillo que degrada a naranja sobre negro, extraída del propio archivo con una herramienta de muestreo, no «más o menos amarillo».
• Las tipografías: tres familias distintas según el rol, titulares redondeados, títulos de sección en negrita pesada y cuerpo legible. Hubo que identificarlas y confirmar que estuvieran disponibles como fuentes web.
• Los recursos: logos, collage, mural y 10 logos de aliados que no existían como archivos sueltos. Se recortaron del JPG uno por uno, con un script, a su tamaño real.

Segundo: una versión en HTML antes de tocar WordPress

Puede sonar a doble trabajo y es lo contrario. Construir primero una página estática en HTML y CSS, comparándola lado a lado con el JPG hasta que coincidan, separa dos problemas: el de reproducir el diseño y el de hacerlo funcionar en WordPress. Si los mezclas, cada vez que algo no se ve igual no sabes si es el diseño o el constructor.

En esa versión se resolvieron las decisiones finas: márgenes reales, cómo se comportan las tarjetas en celular, qué textos son títulos y cuáles son etiquetas, y los degradados radiales de las tarjetas, que son fáciles en CSS y no existen en la interfaz de Bricks.

Tercero: convertir el HTML a la estructura de Bricks, con un generador

Construimos en WordPress con Bricks, y Bricks permite pegar secciones enteras desde un archivo de texto con una estructura definida. En lugar de rehacer el diseño a mano arrastrando elementos, escribimos un pequeño programa que lee el HTML y genera esa estructura: la página completa con sus cinco secciones y 200 elementos, más la cabecera y el pie como plantillas globales.

Esto tiene dos ventajas que un cliente no ve pero paga: la conversión es exacta porque sale del mismo HTML que ya coincidía con el JPG, y si el cliente pide un cambio de base, se corrige en el generador y se vuelve a producir todo en segundos. Explicamos por qué usamos este constructor en Bricks vs Elementor vs Gutenberg.

Lo que se rompió, y la regla que dejó

• Los degradados radiales de las tarjetas no existen en Bricks. Regla: lo que el constructor no ofrece va a una clase de CSS global, con un color sólido de respaldo en el elemento. Si alguien olvida pegar el CSS, la web se ve correcta, solo sin el brillo.
• Los degradados en el texto tampoco. Palabras como «talento» o «frecuentes» llevaban un degradado. Se resolvieron con un color de acento en el texto, y el degradado real quedó como opción por clase.
• Las fuentes no cargaban. Nombrar una fuente en el estilo no la instala. Regla: las tipografías se cargan en los ajustes del constructor antes de pegar nada, o todo cae a la fuente por defecto y el parecido se pierde.
• Las imágenes apuntaban a una ruta provisional. Regla: primero se suben las 16 imágenes a la biblioteca de medios de WordPress, después se reemplaza la ruta base y recién entonces se pega.

Una regla más, aprendida en otro proyecto de este mismo tipo: los identificadores internos de cada elemento tienen que generarse automáticamente, nunca escribirse a mano, porque el constructor los regenera al pegar y con identificadores mal formados descarta elementos anidados en silencio.

Cuarto: el sistema de diseño, para que el cliente no lo rompa

Una web pixel perfect dura hasta que alguien edita un título con otro tamaño. Para evitarlo, además de la página se entregó el estilo del tema: la escala tipográfica completa de H1 a H6 con sus tamaños, la paleta como colores globales y las clases de CSS documentadas. Así, cuando el cliente crea una página nueva, hereda el diseño sin tener que recordar que el H2 mide 40 píxeles.

Qué cambia para ti si vas a encargar una web desde un diseño

• Entregar un JPG no es un problema, pero añade trabajo de interpretación. Si puedes, pasa también los colores exactos, los nombres de las fuentes y los logos sueltos: ahorras horas y evitas aproximaciones.
• Pide ver la versión en HTML o una comparación lado a lado antes de que la web esté en WordPress. Es el momento barato de corregir.
• Pregunta si la web lleva estilo de tema y paleta global. Es lo que hace que la segunda página se vea como la primera.
• Pixel perfect no significa idéntico en todos los celulares. Significa fiel al diseño y adaptado con criterio donde la pantalla obliga a cambiar. Pide ver la versión móvil, no solo la de escritorio.

Si estás decidiendo con quién hacerla, qué pedir en la cotización de una web te da la lista completa.

Preguntas frecuentes

¿Se puede hacer una web pixel perfect desde un JPG?

Sí, con un paso intermedio de interpretación: extraer paleta, fuentes y recursos de la imagen, y construir primero una versión estática que se compare con el diseño antes de llevarla a WordPress.

¿Es mejor entregar el diseño en Figma?

Sí, porque trae medidas, colores y tipografías exactos y los recursos exportables. Pero un JPG bien hecho se puede convertir igual; cuesta más horas de interpretación.

¿Qué significa pixel perfect en una web?

Que la web reproduce el diseño con fidelidad en la pantalla para la que se diseñó, y que en otras pantallas se adapta siguiendo el mismo criterio visual. No significa que cada píxel coincida en todos los dispositivos, que es imposible.

¿Por qué construir primero en HTML si al final va a ser WordPress?

Para separar dos problemas: reproducir el diseño y hacerlo funcionar en el constructor. Así, cuando algo no se ve igual, sabes de inmediato de cuál de los dos viene.

¿Cuánto tarda convertir un diseño a WordPress?

Una landing de cinco secciones como esta, entre una y dos semanas incluyendo la interpretación del JPG, la versión HTML, la conversión y las pruebas en celular. Con un diseño en Figma y recursos sueltos, menos.

Conclusión

Convertir un diseño en JPG a una web pixel perfect en WordPress es un proceso de cuatro pasos: leer la imagen y extraer lo que no trae, construir una versión HTML que coincida, convertirla al constructor con un generador en vez de a mano, y entregar un sistema de diseño para que la fidelidad sobreviva a la primera edición del cliente. En Coloriza funcionó así, y las reglas que dejaron los tropiezos son las que ahora aplicamos desde el primer día.

Pasar del diseño al código es solo una parte del trabajo de una web: el resto está en nuestros servicios de marketing digital. La plataforma sobre la que montamos cada diseño la explicamos en por qué hacemos las webs en WordPress.

En Lucuma Agency hacemos desarrollo web en WordPress a partir de tu diseño, venga en Figma, en PDF o en una imagen. Agenda una consultoría gratis y te decimos qué falta en tu archivo para que la web salga igual.