Figma Make en 2026: cómo pasar del diseño a un prototipo funcional y al código
Figma Make ha cambiado la forma de pasar de un diseño de interfaz a algo que las personas realmente pueden utilizar, probar y evaluar. En 2026, puede tomar una descripción escrita, un frame existente de Figma o una combinación de referencias visuales y contexto del proyecto para generar un prototipo funcional o una aplicación web con interacciones operativas y código editable. Esto no elimina la necesidad del criterio de diseño ni de la revisión por parte de los desarrolladores, pero reduce considerablemente la distancia entre un concepto estático y una versión funcional. La forma más útil de trabajar con Make no consiste en tratarlo como un sustituto del trabajo de producto con un solo clic, sino como un entorno rápido para convertir una intención de diseño clara en comportamiento, comprobar ese comportamiento desde las primeras etapas y entregar a los desarrolladores un resultado mucho más concreto. El proceso funciona mejor cuando el diseño de origen está bien organizado, las instrucciones son específicas y cada ronda de cambios tiene un objetivo definido.
Qué puede hacer realmente Figma Make en 2026
Figma Make se basa en un chat con IA que genera código para prototipos funcionales, aplicaciones web e interfaces interactivas. Un proyecto puede comenzar con una instrucción en lenguaje natural, aunque el punto de partida más sólido suele ser una combinación de texto y contexto visual. Es posible adjuntar diseños de Figma, pegar frames directamente en el chat, incorporar estilos procedentes de bibliotecas publicadas en los planes de pago compatibles y añadir contexto externo mediante conectores MCP compatibles. Figma también ofrece el modo de planificación para usuarios de pago, que crea un plan estructurado antes de generar el código. Resulta especialmente útil en productos con varias pantallas, ya que permite corregir el flujo previsto antes de realizar una generación amplia. El objetivo es sencillo: proporcionar a Make información suficiente para que comprenda no solo cómo debe verse una pantalla, sino también qué debe hacer cada control importante y cómo se relacionan entre sí los diferentes estados.
El resultado generado es más que una maqueta en la que se puede hacer clic. Make escribe el código que sustenta la experiencia y muestra una vista previa interactiva una vez terminada la generación. A partir de ahí, se puede continuar la conversación, editar directamente la interfaz representada, modificar el código o volver a una versión anterior. Esto es importante porque la primera versión rara vez debe considerarse definitiva. Una tarjeta de producto puede tener un aspecto correcto pero comportarse mal en una pantalla estrecha, un campo de búsqueda puede carecer de un estado vacío o una ventana modal puede abrirse correctamente pero no devolver el foco al control que la activó. Make resulta más útil cuando estos problemas se consideran parte normal de la iteración y no una señal de que el primer prompt haya fracasado. En el trabajo real, la versión generada debe convertirse en un borrador comprobable que se refine con el mismo cuidado que cualquier otro prototipo.
La elección del modelo también adquirió mayor importancia en 2026. Figma añadió GPT-5.6 al selector de modelos de Make en julio, con especial atención a una mejor interfaz en la primera generación, diseños adaptables e interacciones. Sin embargo, el modelo es solo una parte del resultado. La calidad de la información de entrada sigue influyendo directamente en la calidad de lo que se genera. Una instrucción breve como «haz que esta pantalla sea interactiva» deja demasiadas decisiones sin definir. Una indicación mejor especifica la acción del usuario, la respuesta esperada, el cambio de estado visible y cualquier limitación. Por ejemplo, un diseñador puede indicar que, al seleccionar un filtro de productos, debe actualizarse el número de resultados, mostrarse un estado activo del filtro, conservarse el orden actual y ofrecerse una forma clara de restablecer la selección. Ese nivel de detalle proporciona al prototipo generado algo concreto que implementar y, al mismo tiempo, algo concreto que comprobar.
Empezar desde un diseño existente en lugar de un prompt vacío
Uno de los usos más sólidos de Figma Make consiste en convertir un frame existente de Figma Design en una experiencia funcional sin tener que reconstruir la interfaz desde cero. Figma recomienda adjuntar frames estructurados en lugar de depender únicamente de capturas de pantalla, ya que los frames contienen información que una imagen no puede transmitir con la misma fiabilidad, incluidas las relaciones de diseño y la estructura visual. Auto Layout resulta especialmente útil porque aporta a Make indicaciones más claras sobre cómo deben cambiar de tamaño y reorganizarse los elementos. Para una función pequeña, se puede adjuntar el frame correspondiente y explicar el comportamiento deseado. En un producto de mayor tamaño, es preferible trabajar pantalla por pantalla o con uno o dos diseños a la vez. De este modo, el contexto se mantiene centrado y resulta más fácil detectar cuándo el resultado generado ha interpretado mal un flujo, ha duplicado un componente o ha realizado una suposición que nunca formó parte del diseño.
Los Make kits añaden otra capa de coherencia para los equipos que ya cuentan con un sistema de diseño. Un kit puede incluir paquetes npm que aporten contexto de código, variables y estilos de bibliotecas publicadas de Figma Design, además de directrices escritas sobre cómo deben utilizarse los componentes, tokens y patrones. La ventaja práctica es que el prototipo generado puede comenzar mucho más cerca del producto real en lugar de inventar un nuevo lenguaje visual para cada experimento. Esto resulta especialmente útil en elementos habituales como botones, campos de entrada, tarjetas, reglas de espaciado y tipografía. El diseñador sigue teniendo que revisar el resultado, pero la cantidad de correcciones puede ser menor cuando Make recibe el mismo vocabulario que ya utiliza el equipo. En organizaciones que crean prototipos con frecuencia, un kit bien mantenido también reduce la necesidad de repetir las mismas reglas visuales en cada nuevo chat.
Los archivos adjuntos pueden aportar mucho más que referencias visuales. Figma introdujo los archivos adjuntos de Make en 2026 para que los prototipos puedan basarse en contenidos, datos y limitaciones específicos de cada proyecto. Esto significa que un prototipo para un área de cuenta puede utilizar contenido realista en lugar de texto de relleno, mientras que una interfaz con mucho contenido puede construirse en torno a los tipos de información que realmente debe mostrar. La regla útil consiste en adjuntar únicamente aquello que vaya a cambiar el resultado. Un archivo breve con directrices, una referencia de componentes reales y un pequeño conjunto de datos representativos suelen ser más valiosos que una gran cantidad de archivos poco relacionados entre sí. La información sensible no debe pegarse en el chat. Las propias recomendaciones de Figma advierten de que no se deben incluir claves API, datos personales, direcciones ni otros secretos similares en los prompts; la gestión segura de los datos debe realizarse en el backend o en otra parte controlada de la implementación.
Cómo crear un prototipo funcional paso a paso
El flujo de trabajo más fiable con Figma Make comienza por el diseño y el recorrido del usuario antes de añadir todas las interacciones avanzadas. En primer lugar, hay que adjuntar o pegar el diseño principal y explicar para qué sirve la pantalla, quién la utilizará y qué se considera un resultado correcto. Después, conviene definir las acciones principales en lenguaje sencillo. Por ejemplo, un prototipo de proceso de compra no debería empezar con una instrucción extensa que intente cubrir todos los posibles estados de pago, animaciones y reglas de validación. Es mejor comenzar por el recorrido principal: seleccionar la entrega, introducir los datos de contacto, avanzar al pago y confirmar el pedido. Cuando ese recorrido funcione correctamente, se pueden añadir los estados que falten uno a uno. Este enfoque por etapas coincide con las recomendaciones de Figma de centrarse primero en el diseño, después en la funcionalidad y construir los proyectos complejos en pasos más pequeños. También facilita la detección de errores porque cada modificación tiene una causa clara.
Un buen prompt debe combinar tarea, contexto y restricciones. La tarea indica a Make qué debe crear; el contexto explica el producto y la situación del usuario; las restricciones evitan suposiciones no deseadas. Si se está convirtiendo el diseño de un panel de control, por ejemplo, se puede indicar que el frame de escritorio existente es la referencia visual, que la tabla debe seguir siendo legible en anchuras reducidas, que los filtros deben actualizar las filas visibles y que no deben añadirse nuevos elementos de navegación. Esto resulta más útil que llenar el prompt de adjetivos sobre diseño. Además, proporciona una lista de comprobación sencilla para revisar el resultado generado. ¿La tabla se reorganiza según lo solicitado? ¿Funcionan los filtros? ¿Se ha conservado la arquitectura de la información? ¿Ha añadido Make algo que no se pidió? Cuanto más claro sea el encargo, más fácil será evaluar el resultado sin depender de impresiones poco precisas.
En proyectos de mayor tamaño, el modo de planificación puede reducir las generaciones innecesarias. Antes de escribir el código, Make puede preparar un plan estructurado que se revisa y perfecciona. Esto resulta útil cuando una función incluye varias pantallas, dependencias o estados de datos, porque el error más costoso no suele ser un color o un valor de espaciado incorrectos, sino una interpretación equivocada del flujo del producto. Un plan puede revelar que el modelo pretende crear un paso adicional para la cuenta, interpretar un filtro como navegación o fusionar dos estados que deberían permanecer separados. Corregir estos problemas en una fase temprana es mucho más sencillo que reparar el mismo error después de que se haya extendido por el código. Cuando el plan es correcto, la generación parte de un objetivo más claro. El resultado todavía puede necesitar ajustes, pero el trabajo comienza a partir de una estructura revisada en lugar de una larga instrucción que nadie ha validado como especificación.
Cómo perfeccionar las interacciones sin rehacerlo todo
Las herramientas de edición de Figma Make en 2026 están pensadas para hacer pequeños cambios con mayor precisión. En los nuevos archivos de Make, el panel de propiedades permite seleccionar un elemento y ajustar parámetros visuales habituales como espaciado, tipografía, disposición, opacidad, bordes y otras propiedades relacionadas. Estos cambios se preparan antes de aplicarse, por lo que es posible revisar las modificaciones previstas sin confirmar inmediatamente cada ajuste. Esto suele ser mejor que escribir una instrucción general como «haz que la tarjeta sea más compacta», que podría llevar al modelo a modificar varias partes de la interfaz que no deberían cambiar. La edición directa proporciona a Make un objetivo concreto. Resulta especialmente útil en las fases finales, cuando el diseño general ya es correcto y el trabajo pendiente se centra en alineación, jerarquía, tamaño de componentes u otros detalles que son más fáciles de valorar visualmente que de explicar en un párrafo.
Las anotaciones permiten gestionar cambios que son más difíciles de expresar únicamente mediante propiedades visuales. Se pueden marcar uno o varios elementos directamente en la vista previa y asociar una instrucción a esos puntos concretos. Un diseñador puede, por ejemplo, señalar una miniatura y pedir un pequeño aumento al pasar el cursor, marcar el activador de un menú y solicitar una superposición a pantalla completa o identificar varios controles relacionados que necesitan la misma regla de interacción. Como la instrucción está vinculada al elemento real, Make tiene menos margen para interpretar de forma incorrecta qué parte de la interfaz debe cambiar. Esto resulta especialmente útil en pantallas densas donde hay varios botones o componentes repetidos con etiquetas similares. En lugar de enviar otro prompt para toda la pantalla, se señala el objetivo exacto, se describe el comportamiento y se revisa el resultado. Figma indica que el panel de propiedades y las anotaciones consumen créditos de IA cuando se aplican los cambios.
El historial de versiones y la edición directa del código ofrecen otras dos formas de mantener la iteración bajo control. Si un prompt mejora una parte del prototipo pero perjudica otra, volver a una versión anterior puede ser más rápido que intentar reparar una cadena de cambios no deseados. La edición directa del código resulta útil cuando un desarrollador o un diseñador con conocimientos de programación puede detectar y corregir un pequeño problema en el código fuente más rápidamente que mediante otra solicitud a la IA. Lo importante es elegir el método de edición que corresponda al tipo de problema. Conviene utilizar el panel de propiedades para cambios visuales concretos, las anotaciones para comportamientos vinculados a una zona determinada, los prompts para modificaciones más amplias del producto y el código para los cambios que resulta más sencillo expresar directamente. De este modo se evita el error habitual de utilizar instrucciones conversacionales para todas las tareas, incluso cuando existe una herramienta más precisa. También ayuda a ahorrar créditos al reducir el número de generaciones innecesarias.
Del prototipo al código editable y a la publicación
Cuando el prototipo ya funciona, Figma Make ofrece varias formas de continuar. El código generado puede revisarse y editarse dentro del propio archivo de Make, y los proyectos pueden enviarse a GitHub. La integración actual de Figma con GitHub puede crear un repositorio para un archivo de Make y enviar posteriormente nuevas actualizaciones al mismo repositorio. Es importante conocer las limitaciones de este proceso: la transferencia habitual se realiza en una sola dirección, de Make a GitHub, y los cambios realizados posteriormente en GitHub no regresan automáticamente a Make. Figma también señala que Make envía el código al repositorio creado para ese archivo, en lugar de permitir seleccionar cualquier repositorio existente. Para los equipos, esto convierte GitHub en una herramienta útil para la entrega, la copia de seguridad y la continuación del desarrollo, pero no debe confundirse con una sincronización bidireccional completa del código. El proceso de desarrollo sigue necesitando una asignación clara de responsabilidades cuando los ingenieros comienzan a trabajar fuera de Make.
Figma también ha probado durante 2026 un flujo de trabajo más estrechamente relacionado con el código de producción. La beta limitada anunciada en mayo permite a determinados usuarios conectar un código base real, crear una rama, realizar cambios visuales o mediante prompts sobre ese código, revisar commits y continuar el proceso hasta una pull request. Este escenario es diferente de enviar un proyecto independiente de Make a un nuevo repositorio de GitHub. Acerca al diseñador al código real del producto y puede revelar dependencias que un diseño estático no muestra, como un componente compartido que se utiliza en varias pantallas. El acceso ha estado restringido durante la fase beta, y Figma lo limitó inicialmente a determinados usuarios de la aplicación Beta de escritorio para Mac. Por ello, los equipos deben comprobar el acceso disponible en sus cuentas antes de organizar un flujo de trabajo en torno a esta función, en lugar de asumir que la beta con código de producción está disponible para todos los usuarios.
Cuando un prototipo debe compartirse públicamente en lugar de transferirse inmediatamente al equipo de desarrollo, Make permite publicar un prototipo funcional o una aplicación web en Internet con su propia URL. El contenido publicado puede actualizarse posteriormente, retirarse cuando deje de ser necesario y asociarse a un dominio personalizado cuando el plan de la cuenta lo permita. Esto resulta útil para sesiones de pruebas de usabilidad, revisiones con responsables del proyecto, demostraciones comerciales o pruebas controladas en las que los participantes necesitan un enlace real en lugar de acceso al archivo de diseño. La publicación no convierte automáticamente el código generado en código listo para producción. Antes de una publicación pública, el equipo debe revisar los derechos sobre el contenido, el tratamiento de datos, la accesibilidad, el rendimiento, el comportamiento adaptable y los servicios externos utilizados. Una demostración convincente puede ocultar un tratamiento deficiente de los errores o supuestos poco realistas sobre los datos, por lo que la revisión final debe comprobar tanto los escenarios problemáticos como el recorrido ideal.
Dónde sigue siendo necesaria la revisión humana en Figma Make
La principal limitación de Figma Make es la misma que aparece en la mayoría de las herramientas de desarrollo asistidas por IA: un resultado convincente puede parecer terminado antes de haber sido revisado correctamente. Un botón puede funcionar en el recorrido ideal pero fallar con una etiqueta larga, la navegación con teclado puede estar incompleta, el diseño móvil puede requerir más atención que la versión de escritorio o el contenido generado puede no cumplir los requisitos legales y editoriales. Las recomendaciones actuales de Figma indican que los resultados para escritorio y pantalla completa siguen siendo más sólidos que los móviles en determinados casos, por lo que el comportamiento adaptable debe comprobarse de forma deliberada. Los diseñadores deberían revisar el diseño en anchuras reales, la expansión del texto, los estados de foco, la carga, los estados vacíos, los errores y el contenido repetido. Los desarrolladores, por su parte, deben revisar la estructura del código, las dependencias y las implicaciones de seguridad. El prototipo aporta más valor cuando permite detectar estas cuestiones pronto, no cuando se interpreta como una prueba de que ya no es necesario plantearlas.
También existe una diferencia importante entre disponer de código generado que se puede editar y tener código que un equipo esté dispuesto a mantener durante años. Make puede crear un punto de partida sólido, especialmente cuando recibe un contexto de diseño preciso, un prompt claro y acceso a las reglas de componentes adecuadas. Sin embargo, el código de producción debe seguir adaptándose a la arquitectura del proyecto, los estándares de pruebas, las prácticas de seguridad, las convenciones de nombres y el proceso de lanzamiento. Si un equipo ya dispone de componentes compartidos, un sustituto generado puede provocar duplicaciones innecesarias. Si la aplicación depende de autenticación, API privadas o datos regulados, la implementación necesita una revisión especializada antes de que intervengan usuarios reales. Por tanto, una entrega razonable no consiste en pensar «la IA lo ha escrito, así que puede publicarse», sino en entender que «el comportamiento ya está definido de forma concreta, el código existe y el equipo puede revisar una propuesta mucho más específica». Esto reduce de manera significativa la ambigüedad sin dar por hecho que la responsabilidad técnica ha desaparecido.
Por este motivo, el mejor flujo de trabajo con Figma Make en 2026 es un ciclo continuo y no un único salto desde un frame hasta un producto terminado. Conviene comenzar con un diseño bien estructurado o un encargo claro, proporcionar a Make suficiente contexto para conservar el sistema previsto, generar la parte útil más pequeña, probarla y después perfeccionarla mediante el método de edición más preciso disponible. Los Make kits son adecuados cuando la coherencia es importante, mientras que los archivos adjuntos ayudan cuando el contenido real o determinadas restricciones afectan al comportamiento. GitHub o la beta de código de producción deben utilizarse cuando la versión ya esté preparada para una revisión técnica. En el caso de los prototipos públicos, la publicación debe realizarse únicamente después de comprobar derechos, privacidad y casos límite. Utilizado de esta manera, Figma Make puede convertir la intención de diseño en algo comprobable mucho antes dentro del proceso. Su valor real no consiste en eliminar el trabajo entre diseño y código, sino en hacer que ese trabajo sea visible antes y en una forma que diseñadores, responsables de producto y desarrolladores puedan revisar conjuntamente.
