Figma Dev Mode y el reto de conectar diseño y desarrollo

Dev Mode, que Figma presentó en su conferencia Config el 21 de junio de 2023, parte de una idea razonable: que desarrollo pueda consultar los diseños en un espacio pensado para ello. Incluía medidas, recursos, código de referencia y una marca de “listo para desarrollo”, y llegó en beta junto a las variables, la versión de Figma de los design tokens.

No era el primer intento del sector de reducir la distancia entre diseño y desarrollo, ni será el último. Sirve para volver a una pregunta incómoda, la de qué se transfiere realmente cuando se pasa un diseño y cuánto de eso puede resolver una herramienta.

Lo que una herramienta resuelve bien

Hay una parte del traspaso que es mecánica y se presta a automatizar, como las medidas, los espaciados, los colores, las tipografías o los recursos exportables. Esa parte se resolvía con anotaciones manuales y archivos de especificaciones, y cada vez que se resuelve dentro de la propia herramienta se ahorran preguntas que nadie disfrutaba haciendo.

Las variables y los componentes añaden otra capa. Cuando una decisión de diseño, como un color de acción o un espaciado, se expresa con un nombre que existe tanto en el diseño como en el código, deja de ser un valor que copiar. Pasa a ser una referencia común. Es un avance real hacia un vocabulario compartido.

Lo que sigue perdiéndose

Lo que no se puede inspeccionar es la intención. Por qué se eligió esta solución y no otra, qué alternativas se descartaron, qué prioridad tiene cada parte y qué se está dispuesto a sacrificar si el tiempo aprieta. Tampoco viaja bien el comportamiento: qué ocurre cuando falla la carga, cuando faltan datos, cuando alguien no tiene permisos. Un archivo muestra los estados que alguien dibujó, no los que nadie pensó.

Y una marca de “listo para desarrollo” informa de que quien diseña considera el trabajo terminado, no de que quien va a construirlo lo haya entendido ni de que sea viable. Es una señal de estado, y conviene no confundirla con una conversación. Es la misma idea que está detrás de considerar los handoffs como deuda organizativa: cada traspaso transfiere información, pero rara vez el contexto completo.

Un lenguaje común solo si ambos lo mantienen

Los sistemas de diseño prometen ese vocabulario compartido, y funcionan cuando hay un componente en el archivo y otro equivalente en el código, con los mismos nombres y comportamientos. Cuando uno cambia y el otro no, aparece una discrepancia silenciosa que se descubre en revisión o, peor, en producción.

Mantener esa correspondencia requiere acuerdos que ninguna herramienta decide por sí sola. Quién modifica un componente y cómo se propaga el cambio. Qué ocurre cuando desarrollo necesita una variante que diseño no ha previsto. Cómo se nombran las cosas. Son cuestiones de gobierno y de colaboración, cercanas a lo que se plantea cuando se organiza el trabajo de diseño a escala.

Hablar sigue siendo necesario

Una herramienta mejor reduce el trabajo mecánico, y eso libera tiempo para la conversación que importa. Un repaso conjunto del diseño antes de construir, con preguntas sobre estados, casos extremos y coste, vale más que cualquier cantidad de anotaciones. Y esa conversación funciona mejor cuando desarrollo ha participado antes, que es lo que lleva a defender que diseño, negocio y desarrollo deberían hablar antes.

Escribo esto en 2026, y la herramienta ha seguido evolucionando desde entonces, pero el argumento no depende de ninguna función concreta. Las herramientas pueden facilitar el paso de diseño a desarrollo, pero no sustituyen el entendimiento compartido del problema y de las decisiones que se tomaron para resolverlo.

---

Nota retrospectiva: reflexión escrita en 2026 sobre el contexto de julio de 2023.

Las opiniones expresadas son personales y no representan la posición de ninguna organización.