Los siete errores más comunes al maquetar un diseño de Figma son: espaciado inconsistente, tipografías mal cargadas, imágenes pesadas sin optimizar, maquetado rígido sin breakpoints, estados ignorados, motion improvisado y handoff sin checklist. Todos comparten el mismo patrón: en el viewport del diseñador el resultado «se ve casi igual», pero en dispositivos reales el diseño se degrada —texto que salta, layout que se rompe, animaciones que bloquean el scroll—. Cada error se listado abajo con síntoma, causa y arreglo concreto, ordenado por frecuencia en proyectos Figma a WordPress. Si el archivo llega bien preparado, la mayoría ni siquiera aparece: para eso está nuestra checklist de entrega de Figma a WordPress.
Los 7 errores al maquetar de Figma a código
Los errores no son culpa del desarrollador ni del diseñador por separado: son huecos de proceso. Los siete siguientes aparecen una y otra vez en revisiones de handoff; reconocerlos a tiempo ahorra días de idas y vueltas.
1. Espaciado inconsistente
Síntoma: huecos que no coinciden entre secciones, botones con padding distinto entre pantallas y márgenes «a ojo» que cambian sin motivo. El cliente no sabe explicar qué falla, solo dice que «algo se ve raro», y en código aparecen decenas de clases únicas de 13, 17, 22 y 27 píxeles.
Causa: no existe escala de espaciado ni variables de Figma: cada pantalla se maqueta con valores libres y cada quien elige el número que le parece bien. Al exportar, el desarrollador copia los valores tal cual y el sistema que nadie definió se reconstruye a mano en CSS.
Fix: declara una escala fija (4, 8, 12, 16, 24, 32, 48, 64) como variables de espaciado en Figma y como tokens en CSS; usa gap en flex y grid en lugar de márgenes sueltos; audita el archivo buscando valores fuera de escala antes del handoff. El mismo criterio forma el tercer punto de nuestro checklist de handoff para desarrolladores.
2. Tipografías mal cargadas
Síntoma: texto invisible o parpadeante al abrir la página, párrafos que cambian de alto mientras cargan, títulos que se parten en puntos raros y pesos que se ven idénticos: el 600 se renderiza como el 400 y la jerarquía desaparece.
Causa: se cargan todas las variantes de la familia (doce archivos que casi nadie usa), no se declaran solo los pesos reales, el interlineado y el espaciado de letras difieren entre Figma y CSS, y la fuente viene de un tercero que añade una petición de red en el camino crítico de render.
Fix: autoaloja los WOFF2 con subconjunto del alfabeto usado, declara font-display con swap, precarga únicamente la variable principal de titulares, traduce la escala tipográfica a clamp() para títulos fluidos y revisa interlineado en todos los estilos, no solo en el párrafo base. Coherencia tipográfica es la mitad de la fidelidad píxel a píxel que prometes al convertir Figma a WordPress.
3. Imágenes pesadas sin optimizar
Síntoma: LCP lento en móvil, contenido que salta mientras aparece, archivos de tres a ocho megabytes —capturas de interfaz en PNG, fotografías sin comprimir— e iconos rasterizados donde debía ir vector.
Causa: el export por defecto de Figma, sin dimensiones declaradas, sin formato moderno, sin variantes por ancho y sin texto alternativo: la imagen gigante viaja siempre, aunque el usuario termine viéndola a cuatrocientos píxeles.
Fix: SVG para iconos y gráficos de interfaz; raster en WebP o AVIF con versiones por ancho, atributos width y height desde el primer commit y texto alternativo definido en diseño. La referencia técnica de la que conviene partir está en el elemento img de MDN: lo que no declare ahí el navegador lo rellena con saltos de layout.
4. Maquetado rígido sin breakpoints
Síntoma: scroll horizontal en tablet, tipografía gigantesca en móvil, contenedores desbordados y maquetados que solo se ven bien a 1440 píxeles de ancho.
Causa: frames con ancho fijo, autolayout ausente o a medias, un único breakpoint exportado, comportamiento responsive sin anotar y contenedores sin máximo. El diseñador revisó en su pantalla grande y el mundo no vive ahí.
Fix: autolayout en todos los frames, max-width en contenedores, breakpoints definidos de verdad con anotaciones de qué se apila, qué se oculta y qué cambia de orden, y pruebas en 320, 768, 1024 y 1440 antes de aprobar el handoff. Si el diseño solo existe a un ancho, el desarrollador está obligado a inventar y cada invento es una futura revisión.
5. Estados de interfaz ignorados
Síntoma: hover que no existe en código, foco de teclado invisible —lo que rompe accesibilidad y QA—, estados vacíos y errores de formulario inventados por el desarrollador a su gusto y un botón de carga que nunca se diseñó.
Causa: el diseño solo muestra el estado por defecto. El desarrollo rellena los huecos con criterio propio, nadie los especificó y el QA tampoco los cubre, porque no existen en ningún documento.
Fix: documenta por componente default, hover, focus, active, disabled, error y loading; diseña empty states y mensajes de error como piezas del sistema; incluye los estados en el handoff con el mismo rigor que el color y el tipo. Dieciocho puntos más de revisión están en el checklist de entrega para equipos.
6. Motion improvisado
Síntoma: animaciones que erizan el scroll, transiciones de página que disparan el INP, movimiento en cada sección sin jerarquía visual y ninguna que respete la preferencia de movimiento reducido del usuario.
Causa: no hay especificación de motion: nadie definió qué se mueve, cuándo, cuánto tiempo ni con qué easing. Se animan propiedades de layout como top o height —que obligan al navegador a recalcular— y la herramienta se elige a mitad del código, cuando ya es tarde para el presupuesto de rendimiento.
Fix: motion brief antes de codificar (disparador, duración entre 200 y 600 ms, easing, propiedades transform y opacity), presupuesto de movimiento por página, desactivación con prefers-reduced-motion —documentada en la guía de MDN— y decisión CSS contra GSAP tomada con matriz, no por costumbre.
7. Handoff caótico sin checklist
Síntoma: capas sin nombre, estilos locales duplicados, variables de color ignoradas, el desarrollador adivinando qué es componente y qué no, y cada ronda de revisión reabriendo decisiones que ya estaban cerradas.
Causa: nadie trató el handoff como entregable. El archivo llega «como está» y el conocimiento vive solo en la cabeza del diseñador, que no está en cada pull request para responder dudas.
Fix: convierte el handoff en una fase con checklist, tokens exportados, nomenclatura acordada, notas por capa y una sesión corta de traspaso entre diseño y desarrollo. Con ese protocolo el build avanza sin idas y vueltas y el archivo de diseño queda como fuente de verdad, no como boceto sospechoso. Es el punto de partida que usamos con agencias en cada entrega.
Cómo evitarlos en el próximo proyecto
Los siete errores se previenen con dos rituales. Antes del build: una sesión de revisión del archivo contra checklist —espaciado, tipografía, imágenes, breakpoints, estados y motion— con dueño y fecha en cada punto pendiente. Durante el build: definición de «terminado» que incluya presupuesto de peso de imagen, prueba en dos anchos reales y revisión de estados de foco. Ninguno de los dos rituales cuesta más de media hora por entregable; ninguno de los siete errores se corrige en media hora cuando ya está en producción bajo la marca de tu cliente. Por eso medimos dos veces y maquetamos una.
Preguntas frecuentes
¿Cuánto cuesta corregir estos errores después del build?
El doble o el triple que corregirlos antes del handoff. Un sistema de espaciado malo se reconstruye en todas las plantillas; una tipografía mal cargada obliga a rehacer estilos globales; las imágenes pesadas se pagan en cada visita.
¿Quién debe corregirlos: diseño o desarrollo?
Diseño corrige espaciado, tipografía, estados y motion spec; desarrollo corrige carga de assets, breakpoints en CSS y presupuesto de rendimiento. Los dos lados firman el checklist antes de que el proyecto salga a producción.
¿Sirve esta lista para proyectos white label?
Más todavía: cuando el cliente final solo ve tu marca, cada error visual es tu error. El checklist compartido entre tu equipo y el partner es el mismo, con dueños y plazos claros.
¿Cómo evito que el motion dañe el rendimiento?
Con motion brief, propiedades transform y opacity, presupuesto de página y medición de LCP, INP y CLS antes y después. Si la animación no cabe en el presupuesto, no se publica.
Guías relacionadas: Cuánto cuesta una página web en México en 2026 (precios reales) · Diseño web en CDMX para negocios
Sigue leyendo: