Problema
El debate «Figma primero o código primero» convierte una decisión de aprendizaje en una preferencia de herramienta. Un equipo abre el canvas porque siempre lo ha hecho. Otro genera una aplicación porque ahora puede. Ambos pueden producir algo convincente y seguir sin responder la pregunta que bloquea el producto.
La fidelidad visual ayuda poco si la duda está en la latencia, el estado o los permisos. Un prototipo funcional también puede ser excesivo si el equipo aún no comparte jerarquía, tono o dirección. La velocidad solo crea progreso cuando el artefacto reproduce la parte del problema que se necesita observar.
Figma describe Figma Make como una capacidad prompt-to-app para explorar, editar y convertir diseños en experiencias interactivas. Eso difumina la vieja frontera entre canvas y ejecución; no elimina la necesidad de elegir qué incertidumbre probar.
Tesis
No empieces por Figma ni por código generado. Empieza por la incertidumbre más cara.
El prototipo correcto es el artefacto mínimo que hace visible esa duda sin introducir realismo innecesario. Si hay que comparar jerarquía y lenguaje visual, el canvas permite amplitud y manipulación directa. Si hay que observar comportamiento, datos, estados o integración, una experiencia ejecutable ofrece una señal más fiel. Si la duda es de negocio, quizá ninguno: una prueba manual o una conversación estructurada pueden ser suficientes.
La nueva ventaja no es saltarse diseño. Es cambiar de representación sin reconstruir desde cero cada vez que cambia la pregunta.
Framework
Clasifica primero el riesgo que impide decidir:
| Incertidumbre | Pregunta | Artefacto mínimo útil |
|---|---|---|
| problema | ¿merece resolverse? | guion, entrevista o prueba manual |
| visual | ¿se entiende la jerarquía y la marca? | frames y variantes en canvas |
| interacción | ¿el flujo se aprende al usarlo? | prototipo navegable |
| comportamiento | ¿responde bien a estados y datos? | prototipo generado funcional |
| técnica | ¿la integración cabe en el sistema? | spike sobre código real |
| operativa | ¿puede mantenerse, medirse y gobernarse? | piloto limitado |
La documentación de Figma Make permite adjuntar diseños y componentes, editar con propiedades y código, colaborar, probar datos, añadir backend y publicar una experiencia. También advierte de que una aplicación puede incorporar contenido de terceros y que quien publica debe comprobar sus derechos. Esa amplitud confirma la tesis: «generado» no describe un único nivel de fidelidad ni garantiza que el resultado esté listo para operar.
Antes de construir, escribe una frase verificable: «Necesitamos saber si una persona identifica el siguiente paso cuando el dato aún no existe». Esa frase define el estado que debe aparecer y la conducta que se observa. «Necesitamos ver cómo queda» no define aprendizaje; solo pide output.
Después limita la prueba. Un prototipo de onboarding no necesita reproducir toda la cuenta. Un flujo de importación quizá sí necesita datos, espera, cancelación, error y recuperación. La fidelidad debe concentrarse donde vive la incertidumbre.
Por qué importa ahora
Las herramientas generativas pueden convertir frames en experiencias funcionales y devolver snapshots al canvas. El traspaso deja de ser una frontera rígida, pero aparece un riesgo nuevo: que cada iteración gane superficie antes de ganar evidencia.
Un resultado ejecutable tiene gravedad. El equipo empieza a discutir arquitectura, copy y detalles de producción porque ya existen, aunque fueran decisiones provisionales del generador. Cuanto más completo parece el artefacto, más difícil resulta eliminarlo cuando la hipótesis falla.
El criterio debe proteger la reversibilidad. Una exploración visual puede abrir muchas direcciones. Un prototipo funcional debe estrechar una pregunta. Un spike técnico debe aislar un riesgo. Cuando un único artefacto intenta hacer las tres cosas, mezcla opiniones, comportamiento y viabilidad en una revisión imposible de leer.
También cambia el handoff. Ya no basta con entregar pantallas; hay que indicar qué aprendió el prototipo, qué decisiones siguen abiertas y qué partes del código son desechables. Sin esa etiqueta, una prueba rápida entra en backlog como arquitectura accidental.
Anti-ejemplo
Un equipo quiere reducir abandono en registro. Genera una aplicación completa con login, dashboard y animaciones. En la demo todos comentan la calidad visual, pero nadie ha probado por qué las personas abandonan ni qué dato les frena.
El prototipo ha respondido «¿podemos construir algo?» cuando la pregunta era «¿qué deberíamos pedir y cuándo?». Añadir más fidelidad solo hace más costosa la confusión.
El anti-ejemplo inverso también existe: diseñar una interacción dependiente de datos como una secuencia perfecta de frames. El flujo parece claro porque nunca aparece espera, conflicto, permiso denegado ni recuperación. El canvas no falla; se le ha pedido representar una incertidumbre que exige ejecución.
Protocolo (3 pasos)
- Nombra la incertidumbre. Formula una pregunta observable y decide qué evidencia permite avanzar o descartar.
- Elige fidelidad selectiva. Reproduce con precisión solo la parte que condiciona la respuesta; simula el resto.
- Cierra con una decisión. Registra qué se aprendió, qué queda abierto y qué artefactos o código no deben heredarse.
| Revisión | Pregunta obligatoria | Salida |
|---|---|---|
| antes | ¿qué no sabemos? | hipótesis |
| durante | ¿qué conducta observamos? | evidencia |
| después | ¿qué cambia? | decisión |
Relacionado
- Output no es diseño: proteger la búsqueda antes de generar
- Figma Design Agent: el canvas como sistema operativo de producto
- Brief In, System Out: por qué la interfaz está dejando de ser el producto
Fuentes consultadas
Próximo paso
En la próxima iniciativa, prohíbe empezar con el nombre de una herramienta. Escribe primero la incertidumbre, el comportamiento que debe observarse y la decisión que seguirá. Después elige canvas, prototipo generado, spike o prueba manual. La mejor herramienta será la que permita aprender y desechar con menos coste.