De Figma a producción: cómo funciona nuestro handoff de diseño a desarrollo

Llevo diseñando interfaces desde antes de que 5e existiera. La peor parte del trabajo nunca fue el diseño en sí. Fue el handoff.

Pasás dos semanas armando un mockup pixel-perfect en Figma. Exportás un PDF. Escribís un documento de specs. Se lo entregás al equipo de desarrollo. Lo construyen. Abrís el link de staging. El spacing está mal. Los estados de hover faltan. El peso de fuente está incorrecto. Los breakpoints responsive están adivinados, no diseñados.

Reportás bugs. Arreglan algunos. Discuten otros. Dos semanas de ida y vuelta después, tenés algo suficientemente cercano para entregar pero no suficientemente cercano para sentirte orgulloso.

Ese ciclo está roto por diseño (juego de palabras intencional) en 5e. Así funciona.

El problema no es el documento de handoff. Es el handoff.

La mayoría de agencias tratan diseño y desarrollo como fases secuenciales. Diseño termina, desarrollo empieza. El handoff es un momento en el tiempo: una reunión, un PDF, un link de Figma tirado por encima de la pared.

Nosotros eliminamos la pared. Nuestros diseñadores y developers trabajan en el mismo ciclo de sprint, en el mismo canal de Slack, mirando el mismo archivo de Figma. Cuando armo un componente, el developer que lo va a construir ya está viendo. Cuando tiene una pregunta sobre estados de interacción, comenta en Figma y yo respondo en minutos, no en días.

No es nada del otro mundo. Es simplemente cómo siempre lo hemos hecho porque somos un equipo, no dos.

Cómo se ve el archivo de Figma

Nuestros archivos de diseño no son solo pantallas bonitas. Son artefactos listos para construir.

Variantes de componentes para cada estado. Default, hover, active, disabled, error, loading. Si un botón puede estar en ese estado, está en el archivo. Los developers no adivinan.

Auto-layout en todo. El spacing no se estima a ojo. Está definido en el layout. Un developer inspecciona el archivo de Figma y ve los valores exactos de padding, gap y alignment. No necesita documento de specs.

Design tokens. Colores, tamaños de fuente, border radii, sombras, todo definido como estilos y variables de Figma. Se mapean directamente a variables CSS o config de Tailwind. El developer no elige un color hex del mockup. Referencia un token.

Variantes responsive. Diseñamos al menos tres breakpoints: desktop, tablet, móvil. Cada página tiene los tres. Los developers ven exactamente cómo cambia el layout, no solo la versión desktop con una nota que dice “hacelo responsive.”

Lo que ve el developer

Nuestros developers frontend usan el dev mode de Figma. Hacen clic en cualquier elemento y ven:

• Dimensiones exactas, padding, margin
• El design token (nombre de color, no hex)
• Familia de fuente, peso, tamaño, line height
• Dirección y gaps de auto-layout
• Nombre del componente y variante

No necesitan un spec aparte. El archivo de Figma es el spec. Lo inspeccionan directamente, igual que inspeccionarían un elemento en las dev tools del navegador.

Cómo cambia los tiempos

En un flujo de agencia tradicional:

• Fase de diseño: 2 semanas
• Reunión de handoff: 1 día
• Desarrollo: 2 semanas
• Revisión de diseño y fix de bugs: 1 semana
• Total: unas 5 semanas

En nuestro flujo:

• Diseño y desarrollo se solapan en el mismo sprint
• El diseñador arma componentes en semana 1, el developer empieza a construir en semana 1
• Preguntas respondidas el mismo día por Slack/comentarios de Figma
• Revisión de diseño es continua, no una fase
• Total: unas 3 semanas para el mismo feature

Dos semanas ahorradas en un solo feature. A lo largo de un proyecto completo, eso se acumula.

Funciona porque somos el mismo equipo

Quiero ser claro: esto no es un proceso que podés atornillar a cualquier agencia. Funciona porque nuestros diseñadores y developers han trabajado juntos por años. Conocen los patrones del otro. El developer sabe que siempre pongo tokens de spacing en auto-layout. Yo sé que el developer va a revisar Figma antes de hacerme una pregunta.

Ese contexto compartido es algo que se construye con el tiempo. También es algo de lo que nuestros clientes se benefician de inmediato, porque no necesitan construirlo ellos mismos.

Si estás cansado de que el ciclo de handoff te cueste semanas, o si alguna vez abriste un link de staging y te dieron ganas de cerrar los ojos, esto es cómo se ve la alternativa.