Handoff con desarrollo: de Figma a código

El handoff es el momento en que el diseño pasa al equipo de desarrollo para ser implementado. Es también el momento donde más valor se puede perder si no está bien preparado.

Un handoff no es “compartir el enlace de Figma”. Es un proceso de comunicación que busca que la implementación sea fiel al diseño sin necesitar reuniones de aclaración constantes.

Lo que desarrollo necesita (y rara vez recibe)

Cuando un desarrollador recibe un diseño para implementar, las preguntas que tiene que poder responder sin preguntar son:

• ¿Qué es cada elemento y cómo se llama en el Design System?
• ¿Cuáles son los espaciados exactos entre los elementos?
• ¿Qué pasa con este componente cuando está en estado hover, focus, disabled, error o cargando?
• ¿Qué texto alternativo tiene esa imagen?
• ¿Cuándo aparece este elemento y cuándo desaparece?
• ¿Qué tipo de animación tiene esta transición?
• ¿Qué breakpoints cambian este layout y cómo?
• ¿Qué atributos de accesibilidad necesita este componente?

Un buen handoff responde todas estas preguntas antes de que se hagan.

Prepare el archivo de Figma para handoff

Nomenclatura consistente

Nombra todos los frames, capas y componentes de forma descriptiva. “Frame 1”, “Group 3” y “Rectangle 7” no sirven para desarrollo.

Convención recomendada:

[pantalla]/[estado]
ej: checkout/step-2-payment
    checkout/step-2-payment--error

[componente]/[variante]/[estado]
ej: button/primary/default
    button/primary/hover
    button/primary/disabled

Usa componentes del Design System

Construye los diseños con los componentes de la librería, no con elementos sueltos. Cuando desarrollo ve un componente de Figma enlazado a la librería, sabe exactamente qué elemento de código corresponde.

Si usas un componente de la librería con ligeras modificaciones, documenta explícitamente qué cambió y por qué, o mejor aún: amplía el componente en la librería.

Anotaciones

Las anotaciones son notas contextuales dentro del diseño que explican lo que la imagen no puede transmitir por sí sola.

Qué anotar:

• Comportamiento condicional: “Este bloque solo aparece cuando el usuario tiene perfil de administrador.”
• Lógica de validación: “El botón está desactivado hasta que todos los campos requeridos estén completos.”
• Animaciones y transiciones: “La tarjeta entra desde abajo con ease-out en 200ms.”
• Accesibilidad: “El label del input es ‘Dirección de correo electrónico’. El placeholder solo es informativo.”
• Contenido dinámico: “El nombre del usuario se trunca a 24 caracteres con ellipsis si es más largo.”

No sobreanotes: anota lo que no es obvio. Lo que está claro no necesita explicación.

Especificar todos los estados

Cada componente interactivo necesita todos sus estados en el mismo archivo, claramente organizados y fáciles de encontrar.

Estructura recomendada por componente:

Card de proyecto
├── Default
├── Hover
├── Focus (desde teclado)
├── Selected
├── Loading
└── Error (si aplica)

Los estados no son opcionales. Si no están en el diseño, el desarrollador los implementará a su criterio.

Breakpoints y comportamiento responsive

Para cada pantalla, documenta cómo cambia el layout en los breakpoints relevantes del producto. No asumas que el desarrollador va a adivinar cómo colapsa un grid de tres columnas en móvil.

Convención habitual:

• mobile: < 768px
• tablet: 768px - 1024px
• desktop: > 1024px

En cada breakpoint especifica: número de columnas, qué elementos se ocultan, cómo cambia la navegación y qué componentes tienen una variante móvil diferente.

El Inspect Panel de Figma

El Inspect Panel (panel lateral derecho en modo Dev) muestra automáticamente:

• Dimensiones y posición de cada elemento.
• Colores en HEX, RGB o HSL.
• Tipografía: familia, tamaño, peso, altura de línea, espaciado.
• Estilos aplicados y su nombre si están en la librería.
• Código de exportación CSS básico para cada elemento.

Con tokens sincronizados entre Figma y el código (usando Tokens Studio + Style Dictionary), el Inspect Panel puede mostrar los nombres de los tokens en lugar de los valores crudos. Esto es lo que hace que el handoff sea verdaderamente eficiente.

Dev Mode en Figma

Figma Dev Mode es el entorno específico para desarrollo dentro de Figma. Permite a los desarrolladores:

• Navegar el archivo en modo solo-lectura optimizado para implementación.
• Ver las anotaciones marcadas en modo Dev.
• Comparar el diseño con la implementación real (Figma + extensión de navegador).
• Acceder a las especificaciones de componentes de la librería directamente.

Si tu equipo tiene acceso a Dev Mode, úsalo. Marca las anotaciones de handoff específicamente como anotaciones de Dev para que sean más fáciles de encontrar.

La conversación del handoff

Un handoff bien preparado reduce las preguntas, pero no las elimina. La forma en que gestiones la comunicación durante la implementación importa tanto como el entregable.

Principios para la comunicación de handoff:

• Sé accesible, no disponible 24/7. Define un canal (Slack, comentarios de Figma) y responde dentro de un tiempo razonable.
• Responde con referencia al diseño. No respondas “debería funcionar así” con palabras. Comparte el frame exacto, el componente o la anotación donde está la respuesta.
• Documenta las decisiones que tomes en el momento. Si en una conversación de Slack acuerdas que el modal no necesita overlay en móvil, añade esa anotación al diseño. Las decisiones verbales se pierden.
• Haz una review de la implementación. Cuando desarrollo termina una pantalla, revísala antes de que pase a QA. Las discrepancias son más baratas de corregir aquí que en producción.

Checklist de handoff

Antes de marcar un diseño como listo para desarrollo, verifica:

• Todos los frames tienen nombre descriptivo.
• Todos los componentes son de librería, o las desviaciones están anotadas.
• Todos los estados interactivos están diseñados.
• Los breakpoints y comportamiento responsive están especificados.
• Las anotaciones de comportamiento condicional están presentes.
• Los textos alternativos están especificados para imágenes informativas.
• Los labels de formularios están explícitos.
• Las animaciones y transiciones están descritas.
• Los tokens están aplicados (no valores crudos sueltos).
• El prototipo navegable cubre el flujo principal del handoff.

¿Qué hemos aprendido?

• El handoff es un proceso de comunicación, no un evento de entrega.
• Desarrollo necesita: nombre de componentes, todos los estados, comportamiento responsive, lógica condicional y especificaciones de accesibilidad.
• Las anotaciones explican lo que el diseño visual no puede transmitir solo.
• La revisión de la implementación es parte del proceso de diseño, no trabajo extra.

Siguiente paso

En la última lección veremos Métricas y mejora continua: cómo saber si lo que diseñaste funcionó y cómo estructurar un ciclo de mejora basado en datos.