Figma a código: el handoff que evita el retrabajo
El handoff no es exportar
Cuando un diseño pasa de Figma a código, la conversación suele empezar en el lugar equivocado: "¿está igual?". La pregunta útil es otra: ¿cuánto de lo que se decidió en Figma se puede implementar sin reinterpretarlo?
Un handoff sano no es un archivo con pantallas. Es un conjunto de decisiones compartidas: qué es un token, qué es un componente, cómo se comporta en mobile y qué pasa cuando el contenido es más largo de lo previsto.
Las cinco decisiones que se pagan en código
1. Tokens antes que valores
Colores, tipografías, espaciados, radios y sombras deberían existir como variables, no como valores repetidos en cada frame. Cuando el token existe, un cambio de marca se implementa una vez. Cuando no existe, se implementa en cada componente y se olvida en tres lugares.
2. Componentes, no pantallas
Un archivo con cuarenta pantallas dice poco sobre el sistema. Un archivo con doce componentes y sus variantes dice casi todo: card de producto, botón, campo de formulario, alerta, selector de cuotas.
Si el diseño no está componentizado, el equipo de desarrollo va a componentizar igual, pero por su cuenta. Y ahí empieza la deriva.
3. Estados completos
Los estados son la mitad del trabajo real y la mitad que rara vez aparece en el diseño:
- Hover, focus y active, especialmente en desktop con teclado.
- Error, éxito y advertencia en formularios.
- Loading y esqueleto mientras llegan los datos.
- Vacío: qué se muestra cuando no hay resultados, no hay stock, no hay pedidos.
- Deshabilitado y por qué está deshabilitado.
Diseñar solo el estado ideal obliga a improvisar en producción, y en producción se improvisa mal.
4. Responsive como comportamiento
Tres artboards con anchos fijos no explican cómo se comporta la interfaz. Lo que se necesita:
- Qué pasa entre breakpoints, no solo en los extremos.
- Cómo se reordena el contenido en mobile.
- Qué elementos se ocultan y cuáles nunca deberían ocultarse.
- Cómo se comportan tablas y filtros en pantallas chicas.
5. Contenido realista
Un botón que dice "Continuar" ocupa menos que "Continuar con la compra". Un nombre de producto de dos líneas rompe la grilla. Diseñar con contenido real —largos, imágenes, nombres de categoría— evita la mitad de los ajustes de última hora.
Accesibilidad: se decide en el diseño
No es un paso posterior. En Figma se define:
- Contraste de texto y de estados, incluyendo el gris de los placeholders.
- Tamaño de área táctil de botones e íconos.
- Foco visible, que necesita un estilo propio.
- Jerarquía de encabezados, que se traduce directo al HTML.
- Texto alternativo para imágenes informativas.
Un componente accesible cuesta minutos en diseño y horas en refactor.
El "pixel perfect" mal entendido
La fidelidad al diseño importa en lo que el usuario percibe como estructura: proporciones, jerarquía, espaciado, color. No importa en diferencias de rendering entre navegadores que nadie va a notar.
El objetivo razonable es que tokens y componentes coincidan exactamente, y que el resultado visual sea consistente en los navegadores soportados. Perseguir el píxel exacto en cada motor de render es una forma cara de no avanzar.
El proceso que funciona
- Auditoría del archivo antes de estimar: componentes duplicados, estilos sueltos, pantallas huérfanas.
- Definición del sistema: tokens, componentes base, estados.
- Estimación por componente, no por pantalla.
- Implementación con Storybook o catálogo equivalente, para revisar cada componente aislado.
- QA visual comparando diseño y build en los mismos anchos, con contenido real.
- Documentación de uso: cuándo usar cada variante, qué no hacer.
Los errores que más retrabajo generan
- Tipografía no disponible como webfont o con pesos que no existen, lo que obliga a simular negritas.
- Imágenes sin medidas definidas, que producen saltos de layout y arruinan el CLS.
- Espaciados inconsistentes entre pantallas que parecen iguales.
- Componentes que cambian por dentro según la pantalla, imposibles de reutilizar.
- Diseño aprobado sin contenido real y ajustes infinitos al cargar el catálogo.
Cómo medir la calidad del handoff
- Cantidad de consultas de diseño durante la implementación: deberían ser pocas y de criterio, no de medidas.
- Retrabajo por componente: cuántas veces se rehace algo ya aprobado.
- Consistencia visual entre pantallas del mismo tipo.
- Core Web Vitals del resultado, sobre todo CLS.
El próximo paso
Un buen handoff es ingeniería de interfaz, no un trámite entre áreas. En Codit Digital trabajamos Figma a código pixel-perfect con design tokens, componentes documentados y QA visual, tanto en proyectos propios como en modo white label para agencias. Podés ver el enfoque en desarrollo web a medida y UX/UI o en desarrollo white label para agencias y escribirnos para revisar tu archivo antes de estimar.
