Figma Make llegó para responder una pregunta que el diseño tradicional dejaba en manos de desarrollo demasiado pronto: «¿y si esto se comportara de verdad?». No es un sustituto del archivo de diseño ni del código de producción. Es una capa intermedia donde el equipo valida flujos, microcopy y jerarquía con algo que se siente más cercano al producto final.

Dónde lo usamos en proyectos de marca y web

  • Probar landings y secciones clave antes de comprometer sprint de desarrollo.
  • Mostrar a cliente una navegación real, no solo frames estáticos.
  • Iterar CTAs, formularios y estados vacíos con feedback temprano.
  • Conectar componentes del design system para que el prototipo herede tokens, no hex aleatorios.

En Ingenia., el homepage y las rutas interiores tienen fuente de verdad en código (`home-page.tsx`, tokens en `globals.css`). Figma Make entra cuando hay que explorar variantes o demostrar interacción sin tocar aún el repo — o cuando un cliente necesita ver movimiento y estados que un PDF no transmite.

Límites que conviene asumir desde el día uno

  • El output de Make no es el entregable final: hay que traducir decisiones a componentes y rutas reales.
  • Sin design system en Figma, Make amplifica inconsistencias en lugar de corregirlas.
  • Accesibilidad, rendimiento y SEO siguen siendo trabajo de implementación, no del prompt.

Un prototipo útil reduce reuniones. Un prototipo bonito pero desconectado del sistema solo genera otra ronda de «en producción se ve distinto».

Qué hace falta tener antes de abrir Make

Un prototipo generado es tan bueno como el material con el que se alimenta. Antes de empezar conviene tener claro qué se quiere comprobar: no «cómo se vería la web», sino algo más concreto, como si una persona entiende el flujo de contacto sin ayuda o si la jerarquía de una página de servicios guía la lectura hacia el siguiente paso. Con una pregunta definida, el prototipo se diseña para responderla y deja de ser una demostración vistosa.

  • Un sistema de diseño con tipografías, colores y componentes nombrados, para que el prototipo herede reglas y no invente estilos.
  • Textos reales o muy cercanos a los reales; el relleno falsea la jerarquía.
  • Una lista corta de flujos a probar, con el resultado esperado de cada uno.
  • Alguien que decida qué comentarios se incorporan y cuáles se descartan.

Cómo usarlo en una revisión con el cliente

Un prototipo navegable cambia la naturaleza de la conversación. En lugar de comentar pantallas estáticas y debatir cómo «se supone que» funcionaría cada botón, el cliente hace clic y descubre por sí mismo lo que le resulta claro y lo que no. Las observaciones se vuelven más concretas: «aquí no sé qué pasa si me equivoco», «esto debería llevarme a otro sitio». Son comentarios que se pueden convertir en decisiones, no en gustos.

Conviene acotar la revisión: pedir que se recorra un flujo concreto y que se anote dónde se duda, en lugar de abrir la puerta a cambios de estilo en cada pantalla. Si el cliente propone un cambio mayor, es mejor documentarlo, valorar su impacto y decidir con calma si entra en este ciclo o en el siguiente.

Del prototipo al código sin perder decisiones

El riesgo habitual es que el prototipo aprobado se convierta en una referencia visual que desarrollo reinterpreta. Para evitarlo, las decisiones que se validaron —estructura, textos, estados, comportamiento— se anotan junto al prototipo y se traducen a componentes reales con la misma nomenclatura que el sistema de diseño. Así, cuando alguien pregunta por qué un botón se comporta de cierta manera, existe una respuesta escrita y no una memoria colectiva.

Y una última advertencia: un prototipo no incluye todo lo que un sitio real necesita. Faltan los estados de error, la accesibilidad, el rendimiento, el SEO, los datos reales y los casos extremos. Considerarlo un adelanto de la experiencia, y no una versión casi terminada, evita expectativas de plazo que luego no se cumplen.

Si tu proyecto mezcla identidad, web y validación con stakeholders, tiene sentido plantear una fase Make entre el sistema visual y el build. Así el desarrollo hereda decisiones ya probadas, no suposiciones.