Cuando un cliente o un diseñador entrega un PDF para desarrollar una página web, parece que el trabajo está perfectamente definido.
“Solo hay que pasarlo a HTML.”
La realidad es muy distinta.
Ojo, no se trata de restar mérito al trabajo de diseño. Al contrario: los diseñadores suelen hacer un trabajo excelente resolviendo jerarquía visual, composición y comunicación. El problema es que un diseño pensado para un lienzo fijo necesita aterrizarse a la realidad de la web, donde mandan la fluidez, la adaptabilidad y las limitaciones técnicas del medio.
Después de muchos proyectos he llegado a una conclusión:
Una maquetación profesional comienza mucho antes de escribir el primer
<div>.
Recientemente tuve que desarrollar una página cuyo diseño únicamente existía en un PDF generado desde un MacBook relativamente antiguo. Lo que parecía un trabajo sencillo terminó convirtiéndose en una investigación sobre resoluciones, escalados, densidad de píxeles y renderizado de tipografías.
Ese proyecto me recordó una lección importante: un diseño estático nunca representa exactamente cómo se verá una web en un navegador.
En este artículo quiero explicar cómo afronto este tipo de proyectos y qué herramientas utilizo.
El mayor error al maquetar: pensar que un PDF es una especificación técnica
Un PDF es únicamente una fotografía del diseño.
No contiene información sobre:
- comportamiento responsive
- componentes reutilizables
- jerarquía HTML
- Grid o Flexbox
- tamaños relativos
- variables de diseño
- estados hover
- animaciones
- interacción
Es decir, muestra cómo debería verse una pantalla concreta, pero no explica cómo debe comportarse una aplicación web.
Y luego están las animaciones y transiciones. Un PDF no puede mostrar un hover, un desplazamiento parallax, una entrada con fade-in o cómo se despliega un acordeón. Son comportamientos que hay que especificar aparte, porque cada desarrollador puede interpretarlos de forma distinta. Además, lo que funciona en escritorio con un hover quizá no tiene sentido en móvil con un tap. Si el diseño incluye efectos visuales, conviene documentarlos — aunque sea con una nota o un vídeo rápido — para que el resultado no dependa de la imaginación de quien maqueta.
Y esa diferencia es enorme.
Pero hay más. Maquetar no es solo traducir un diseño a HTML y CSS. A menudo el destino final es un CMS como WordPress, y toca interpretar además cómo se traduce el contenido a tipos de contenido personalizados, taxonomías y campos personalizados. Un PDF no te dice si ese listado de servicios debería ser un custom post type o una taxonomía, ni qué partes debe poder editar el cliente sin tocar código. Esa capa de estructura de contenidos también forma parte del trabajo de maquetación profesional.
¿Por qué el diseño no se ve igual en todas las pantallas?
Uno de los problemas más frecuentes aparece cuando el diseñador trabaja desde un equipo diferente al del desarrollador.
Por ejemplo:
- diseñador con un MacBook Retina
- desarrollador con un monitor 4K
- cliente revisando la web desde un portátil Windows
Los tres están viendo prácticamente el mismo diseño…
…pero no exactamente igual.
¿Por qué?
Porque intervienen muchos factores que normalmente nadie tiene en cuenta.
Resolución de pantalla vs viewport: el Device Pixel Ratio explicado
Antes de seguir, dos conceptos clave:
- Viewport: el área visible del navegador medida en píxeles CSS. Es el lienzo real sobre el que maquetas, no la resolución física del monitor.
- Device Pixel Ratio (DPR): la relación entre los píxeles físicos de la pantalla y los píxeles CSS. Un MacBook Retina tiene DPR 2, lo que significa que cada píxel CSS se pinta con 4 píxeles físicos (2×2).
Existe una idea muy extendida:
“Mi pantalla tiene 2560 píxeles de ancho.”
En realidad eso no significa que el navegador tenga un viewport de 2560 píxeles.
Especialmente en equipos Retina de Apple, la resolución física y el espacio CSS disponible son dos cosas completamente distintas.
Además intervienen:
- Device Pixel Ratio (DPR)
- Escalado del sistema operativo
- Zoom del navegador
- Resolución elegida por el usuario
Por eso una web nunca debería construirse intentando copiar exactamente una captura de pantalla.
Debe construirse para adaptarse. Técnicas como clamp() para tamaños de fuente y espaciados fluidos, unidades relativas (vw, %, rem) en lugar de píxeles fijos, o container queries para que los componentes respondan a su propio espacio disponible (no solo al ancho del viewport) marcan la diferencia entre un diseño que se rompe y uno que respira en cualquier pantalla.
Por qué el texto de una web nunca ocupa lo mismo que en el diseño
Este es probablemente el problema más frustrante.
Aunque utilices:
- la misma fuente
- el mismo tamaño
- el mismo peso
- el mismo interlineado
es posible que el texto ocupe una línea más.
¿Por qué?
Porque depende de:
- sistema operativo
- navegador
- motor de renderizado
- antialiasing
- hinting
- versión de la tipografía
Un simple salto de línea puede desplazar todo un bloque de contenido.
Y eso es completamente normal.
Checklist para maquetar: 5 comprobaciones antes de escribir HTML
Con el tiempo he desarrollado una pequeña lista de comprobaciones antes de empezar cualquier proyecto.
1. ¿Tienes el diseño original en Figma o solo el PDF?
Si solo recibo un PDF, pregunto si existe el archivo original de Figma. Si existe, prefiero trabajar desde él porque inspeccionar medidas, colores y componentes es mucho más rápido.
Dicho esto, trabajo con PDF perfectamente. De hecho, muchos de mis proyectos llegan únicamente con un PDF cerrado y el resultado es igual de preciso. La diferencia es que el PDF me obliga a dedicar más tiempo al análisis inicial: medir manualmente, extraer tipografías, calcular espaciados y rellenar los huecos que un PDF nunca documenta. Es más trabajo de interpretación, pero no es ningún problema.
2. ¿Cuál era el ancho del artboard?
No es lo mismo diseñar para:
- 1440 px
- 1600 px
- 1920 px
Ese dato cambia completamente la percepción del diseño.
3. ¿Qué tipografías y fuentes web necesita el diseño?
Compruebo:
- familia
- peso
- variable font
- licencia
- fuente web disponible
Muchas veces el PDF utiliza una fuente instalada localmente que luego no existe en la web.
4. ¿Tiene una escala de espaciados y márgenes coherente?
Intento descubrir una escala coherente.
Por ejemplo:
- 8 px
- 16 px
- 24 px
- 32 px
- 48 px
Esto facilita enormemente mantener la consistencia durante toda la maquetación.
Para la mayoría de proyectos utilizo TailwindCSS. Su escala de espaciado por defecto (basada en múltiplos de 4 px) funciona como un sistema de diseño ligero que estandariza tamaños, márgenes y paddings sin necesidad de definirlo todo desde cero. Además, si el proyecto lo requiere, se puede personalizar completamente desde la configuración para adaptarse a cualquier diseño.
5. ¿Qué componentes HTML reutilizables puedes identificar?
Antes de escribir HTML identifico:
- botones
- tarjetas
- cabeceras
- bloques
- formularios
Así construyo componentes reutilizables en lugar de repetir código.
Herramientas para convertir un diseño a HTML y CSS
Dependiendo del proyecto suelo utilizar una combinación de estas herramientas.
- Chrome DevTools: imprescindible para comprobar Grid, Flexbox, tamaños, márgenes y tipografías. Si quieres profundizar sin conocimientos técnicos, escribí una guía sobre cómo revisar una web con DevTools sin ser técnico.
- Figma: inspecciona medidas, colores y componentes mucho mejor que un PDF. Ideal si tienes acceso al diseño original.
- PerfectPixel: extensión para superponer el diseño sobre la página mientras desarrollas y detectar desviaciones importantes.
- VisBug: experimenta directamente sobre una página renderizada modificando tamaños, márgenes y tipografía antes de tocar el código.
- WhatFont: identifica al vuelo la tipografía de cualquier elemento de una página.
- PDF24: convierte páginas de un PDF a imágenes de alta calidad para comparar visualmente con el desarrollo.
Qué significa realmente el Pixel Perfect en maquetación web
El término pixel perfect tiene mala fama en algunos círculos, y con razón si se interpreta de forma literal: copiar un PDF píxel a píxel sin entender el medio.
Pero el concepto bien entendido es otra cosa. Una maquetación pixel perfect no es clonar una imagen estática. Es garantizar que el resultado en código respeta fielmente la intención del diseño: proporciones, espaciados, jerarquía tipográfica, pesos visuales y comportamiento responsive.
La diferencia está entre copiar y traducir.
Cuando hablo de maquetación web pixel perfect me refiero exactamente a eso: un resultado donde el diseño original se reconoce al instante, pero que además funciona en móvil, carga rápido, respeta la semántica HTML y está preparado para integrarse donde haga falta. Precisión sí. Copia ciega, no.
Si diseñas: cómo preparar un diseño en PDF para que la maquetación web sea más fiel
Unos consejos prácticos para diseñadores que quieren que su trabajo llegue mejor a producción:
- Diseña a una resolución estándar. 1440 px de ancho es lo más habitual. Si diseñas a 1920 px en un monitor grande, todo se verá más pequeño y espaciado de lo que imaginaste en pantallas más comunes.
- Define una escala de espaciados. Si usas 8 px, 12 px, 16 px, 24 px, 32 px… de forma consistente, el desarrollador puede replicar esa lógica sin adivinar.
- Especifica las tipografías web. No todas las fuentes de escritorio tienen versión web o licencia adecuada. Comprobar esto antes evita sustituciones de última hora.
- Piensa en móvil desde el principio. Aunque solo entregues la versión escritorio, tener una idea de cómo se comporta el diseño en estrecho evita decisiones que luego no escalan.
- Etiqueta componentes, no solo capas. Si llamas “Botón primario” en lugar de “Rectangle 42”, el desarrollador entiende la intención sin tener que interpretarla.
- Exporta los assets en el formato correcto. SVG para iconos e ilustraciones vectoriales. PNG o WebP con resolución @2x para imágenes. Nada de incrustar capturas enormes en un PDF si se pueden entregar aparte.
No se trata de convertir al diseñador en desarrollador. Se trata de que el diseño llegue con la información suficiente para que la traducción a código sea rápida y precisa.
Y hablando de assets, un apunte importante sobre imágenes: de poco sirve maquetar con precisión si luego la web carga lento porque las imágenes no están optimizadas. Una foto a 4000 px de ancho incrustada en un PDF puede pesar varios megas y no tiene sentido servirla así en web. Lo ideal es redimensionar al tamaño real de visualización, comprimir sin pérdida visible y usar formatos modernos como WebP o AVIF. Una buena maquetación también implica que la página se cargue rápido en cualquier dispositivo, y las imágenes suelen ser el primer lastre. Si tu web ya está publicada pero carga lento, tengo un servicio específico de optimización de velocidad web.
Conclusión: maquetar es interpretar el diseño, no copiarlo
Cada vez estoy más convencido de que una buena maquetación no consiste en escribir HTML y CSS.
Maquetar es interpretar un diseño, no copiarlo.
Eso implica entender qué partes son realmente importantes, cuáles pueden adaptarse y qué decisiones permitirán que la experiencia sea consistente en cientos de combinaciones de pantallas, navegadores y sistemas operativos.
Por eso, antes de escribir la primera línea de código, dedico tiempo a analizar el diseño, detectar posibles problemas y establecer una estrategia de implementación.
Ese tiempo inicial suele ahorrar muchas horas de correcciones más adelante.
Y, sobre todo, permite entregar una web que no solo se parece al diseño, sino que funciona como una aplicación web moderna debería hacerlo.
Si tienes un diseño cerrado y necesitas pasarlo a código, puedo ayudarte con mi servicio de maquetación web profesional.
