El handoff en la era de la IA: del diseño al código sin perder la intención
El handoff de diseño cambia cuando un agente de IA construye desde el diseño. Qué debe llevar, cómo marcar lo listo y qué sigue siendo tu responsabilidad.
¿Qué es el handoff y qué debe llevar?
El handoff es el momento en que un diseño deja de ser una propuesta y se convierte en instrucciones. Tradicionalmente incluye medidas, colores, tipografías, estados y notas sobre el comportamiento. Lo que casi nunca se documenta es la intención: por qué ese botón es primario y no secundario, o qué pasa cuando la lista está vacía.
Un handoff completo responde cuatro preguntas: qué se construye, cómo se ve en cada estado, qué reglas la rigen y dónde está la fuente de verdad. Esta última es la que más se olvida, y es la que un agente necesita para no inventar.
¿Qué cambia con un agente?
Antes, el handoff iba a una persona que podía preguntar en un chat. Ahora una parte del trabajo va a un agente que solo lee lo que tiene. Eso cambia dos cosas:
- Lo implícito se vuelve invisible. Una regla que está solo en tu cabeza no llega al agente. Una anotación en el frame, sí.
- El error se multiplica. Un agente puede repetir un mismo problema en veinte pantallas antes de que alguien lo note.
El servidor MCP de Figma le da al agente herramientas para leer el contexto de un diseño: get_design_context devuelve código y contexto de una capa, get_variable_defs lista las variables y estilos usados, y search_design_system busca componentes y variables en las bibliotecas conectadas. Más detalle en De Figma a código con MCP. Todo eso solo sirve si el archivo está bien estructurado.
¿Cómo se prepara un archivo para que lo lea un agente?
La documentación de Figma para su servidor MCP recomienda siete prácticas:
- Usa componentes para todo lo que se repite (botones, tarjetas, campos), así el agente reutiliza el mismo código en cada instancia.
- Conecta los componentes al código con Code Connect. Sin él, el agente tiene que adivinar qué componente de código corresponde a cada componente de diseño.
- Usa variables para espaciado, color, radio de borde y tipografía, para que el agente cite tus tokens y no valores fijos.
- Da nombres claros a capas y componentes. Reemplaza “Frame1268” o “Group5” por nombres que expliquen su función.
- Usa auto layout. Muestra cómo responde el diseño a distintos tamaños y evita el posicionamiento absoluto. Redimensiona el frame antes de generar código para comprobarlo.
- Agrega anotaciones para explicar comportamiento, alineación o responsividad difíciles de ver.
- Agrega recursos de desarrollo en Dev Mode: enlaces a documentación, código o tickets.
¿Qué herramientas de handoff existen en Figma?
Según la ayuda oficial de Figma, Dev Mode incluye:
- Panel de inspección: nombre, tipo y fecha de última actualización de la capa, información del componente (variantes y propiedades), estilos y variables aplicados, y descarga de recursos.
- Fragmentos de código: código para una capa, con lenguaje y unidades seleccionables.
- Code Connect: reemplaza el código autogenerado por el código real de tu sistema.
- Anotaciones y medidas: notas de texto y especificaciones añadidas por el diseñador.
- Enlaces de recursos: GitHub, Jira, Storybook o VS Code vinculados a la capa.
- Estados de desarrollo: Ready for dev marca secciones, frames o componentes como listos para revisión e implementación. Completed marca el trabajo de desarrollo como terminado. Changed se aplica solo cuando se edita algo ya marcado.
Dev Mode está disponible en los planes Professional, Education, Organization, Government y Enterprise. Ready for dev se incluye en todos ellos; Completed solo en planes superiores. Quien marca los estados necesita un asiento Full o Dev, y las notificaciones llegan a quienes ya abrieron el archivo en Dev Mode.
¿Qué sigue siendo tu responsabilidad?
- Decidir qué está listo. Marcar Ready for dev con un estado incompleto le dice al agente que el diseño está terminado.
- Mantener el estado al día. Si cambias un diseño ya marcado, Figma lo marca como Changed. Vuelve a seleccionar Ready for dev y escribe el motivo del cambio para que quien construye lo reciba.
- Documentar los estados. Error, vacío, carga, deshabilitado y responsive. Son los que el agente más suele inventar.
- Mantener la fuente de verdad. Si el código tiene tokens o componentes, el handoff debe apuntar a ellos.
- Revisar el resultado. Compara lo construido contra el diseño con una lista. Ver revisar la fidelidad visual.
¿Cuándo NO conviene un handoff detallado?
- Cuando el prototipo va a tirarse. Un handoff de cincuenta páginas para una prueba de un día es trabajo perdido.
- Cuando el equipo de ingeniería ya co-diseña con el equipo de producto. A veces el handoff es una conversación de diez minutos.
- Cuando el diseño cambia cada hora. Marcar “listo” en algo que va a cambiar genera retrabajo.
Ejemplo
Ejemplo ilustrativo: un diseñador termina un flujo de tres pantallas para pedir un reembolso. En Figma marca las pantallas como Ready for dev, agrega una anotación en el botón de confirmación (“Deshabilitado hasta que se acepten los términos”) y enlaza el componente ConfirmDialog con su historia en Storybook como recurso de desarrollo. Le pasa el archivo a un agente con instrucciones para usar los componentes existentes.
El agente construye las tres pantallas. El diseñador revisa el botón deshabilitado, que el agente había dejado activo, y lo corrige con la anotación como referencia. Sin la anotación, el error habría pasado a producción.
Errores comunes
- Marcar “listo” antes de tener los estados.
- Dejar las reglas en un documento aparte que nadie enlaza en el archivo.
- Usar nombres genéricos de capas, como “Frame 427”, que el agente no puede interpretar.
- Posicionar todo de forma absoluta en lugar de usar auto layout, lo que produce código frágil.
- Asumir que el código generado es el código final del equipo.
- Hacer el handoff por mensaje y no en el archivo. Lo que no queda en el archivo se pierde.