El prototipo se ve bien en la llamada. Todo el mundo pulsa, asiente, pide un ajuste de margen. Dos meses después el desarrollo pregunta por estados vacíos, errores, tokens y qué pasa en móvil cuando el menú no cabe. El archivo no responde. Nadie lo había diseñado: solo se había podido hacer clic.
Un prototipo clicable Figma no es el producto. Es un ensayo de flujo. Sirve para validar recorrido, jerarquía y conversación. No sirve para construir si lo tratas como especificación. La diferencia no es de herramienta. Es de qué decides cerrar en cada fase —y qué aceptas perder si te quedas en el click-through.
Este artículo marca cuándo basta el prototipo, cuándo hay que diseñar a componentes y producción, y cómo no confundir las dos cosas en un proyecto de diseño UX/UI. El criterio que usamos en Truman cuando el archivo tiene que aguantar código, no solo una demo.
Qué es un prototipo clicable Figma (y qué no es)
Un prototipo clicable en Figma es un conjunto de frames enlazados para recorrer un flujo: home a ficha, onboarding a permiso, checkout a confirmación. Su trabajo es que alguien que no es diseñador pueda pulsar y decir «aquí me pierdo» o «aquí no pediría eso». Eso es validación. No es producción.
Producción es el diseño que un front puede implementar sin inventar: componentes con variantes, tokens, estados (hover, disabled, error, loading, vacío), comportamiento en breakpoints y copy que no es lorem. Si el archivo solo tiene el camino feliz en desktop, tienes un prototipo. Aunque tenga auto-layout y una librería a medias.
Las dos cosas son útiles. El error es usar la primera como si fuera la segunda —o exigir la segunda para una decisión que todavía es de flujo. En Truman no «terminamos el Figma» y luego pensamos. Decidimos qué nivel de fidelidad pide cada pregunta. Validar un onboarding no pide el design system. Construir una tienda, sí.
Cuándo basta el click-through
Basta cuando la pregunta es de recorrido o de conversación, no de sistema. ¿El usuario entiende el siguiente paso? ¿Sobran pantallas? ¿El menú esconde lo que importa? ¿El checkout pide un dato que nadie tiene a mano? Eso se ve en un prototipo de fidelidad media, con copy real en los puntos de fricción. No hace falta el componente Button/Primary/Hover.
También basta al principio de un producto nuevo, cuando el flujo todavía puede morir. En Weddle —app social alrededor de una boda— había que validar el viaje (quién invita, qué se comparte, qué se deja fuera) antes de convertir cada pantalla en un sistema. Pintar componentes demasiado pronto habría congelado un flujo que aún se estaba discutiendo.
| Pregunta que tienes | Nivel | Qué entregas |
|---|---|---|
| ¿Se entiende el flujo? | Prototipo clicable | Frames enlazados, copy real en CTAs y errores gordos |
| ¿Hay que recortar pantallas? | Prototipo clicable | Click-through + una sesión con 3–5 usuarios o el equipo de negocio |
| ¿El look convence al comité? | Cuidado | Una home pulida no valida el producto. No la uses como evidencia de UX |
| ¿Se puede construir sin inventar? | No basta el prototipo | Componentes, tokens, estados, responsive |
| ¿El front y el diseño hablan igual? | Hace falta producción | Librería + criterio de handoff, no un enlace de prototype |
Un prototipo barato y bien usado ahorra semanas. Un prototipo eterno las come. La regla: cuando las preguntas de flujo están cerradas, dejas de enlazar frames y empiezas a extraer componentes. Si sigues «mejorando el prototipo» es que no quieres decidir.
Cuándo hay que diseñar a producción
Cuando el flujo ya no se discute y el riesgo se mueve al detalle que el clic no enseña. Una ficha de producto con variantes, un panel con roles, un checkout, un sistema de reservas: ahí el empty state, el error de pasarela y el comportamiento del filtro son el producto. Si no están diseñados, el front los inventa —o no existen.
En Ceylan el trabajo de UX/UI no era un click-through de lookbook. Era fichas, catálogo y un criterio de interfaz que se pudiera repetir. Un prototipo de home bonita no construye una tienda. Una librería de componentes, sí. El mismo salto aparece cuando pasas de «validamos el funnel» a «esto va a producción el mes que viene».
Componentes con variantes
Tokens, no hex sueltos
Estados y responsive
Diseñar a producción es también un trabajo de tokens. Color, tipo, espacio y radio dejan de ser «lo que se ve en este frame» y pasan a ser nombres que el código puede usar. Si te interesa ese puente, está en design tokens de Figma a código. Sin tokens, cada pantalla es un one-off. El prototipo lo disimula porque todas se ven en el mismo archivo.
Qué se pierde si te quedas en el click-through
Se pierde el borde del producto. El prototipo no tiene usuario sin datos, no tiene permiso denegado, no tiene timeout, no tiene el texto largo que rompe la card. En producción eso es el 40% de las pantallas que el usuario sí ve. Si no lo diseñaste, no es que «el front lo complete»: es que el producto sale cojo y alguien lo parchea con un alert nativo.
Se pierde consistencia. El botón de la home no es el de la ficha porque nunca fue un componente. Se pierde accesibilidad: el prototipo no tabula, no anuncia errores a un lector, no tiene foco. Se pierde el handoff: las herramientas de Figma a código no arreglan un archivo que no está pensado para implementarse. El mapa de ese territorio está en herramientas de Figma to code en 2026. La herramienta no sustituye el sistema.
Si mañana un front solo tuviera tu Figma y no pudiera preguntarte, ¿construiría el empty state, el error y el móvil —o te escribiría a las dos horas?
Validar no es solo pulsar: tests que sí caben
El prototipo sirve si lo pones delante de alguien con una tarea. «Mira qué bonito» no es un test. «Encuentra el tratamiento y pide cita» sí lo es. No hace falta un lab: cinco sesiones cortas, tarea escrita, silencio de quien diseñó. Métodos que caben en un presupuesto de estudio están en tests de usabilidad baratos. El prototipo clicable es el soporte. El test es el criterio.
Lo que no hagas: usar el prototipo para vender look al comité y llamarlo research. Una home en alta fidelidad convence a dirección y oculta el flujo. Si validas look y flujo en el mismo archivo, el comentario será de color. Separa. Primero recorrido. Después piel. Después sistema.
Cómo decidimos el nivel en Truman
En un proyecto de diseño UX/UI no hay un único Figma «terminado». Hay un umbral por fase. Discovery y flujo: prototipo, copy real en fricción, tests cortos. Cierre de interfaz: componentes, tokens, estados. Handoff: el front no tiene que adivinar. Si el cliente pide «solo un prototipo» para una tienda o un panel, se lo decimos: puedes validar así; no puedes construir así.
El prototipo demuestra que el viaje se entiende. No demuestra que se puede construir. Si confundes las dos cosas, el clic te da una falsa sensación de acabado —y el front paga la diferencia.
Antes de llamar «cerrado» a un Figma
- ¿La pregunta que cierras es de flujo o de implementación? El nivel del archivo tiene que coincidir.
- ¿El prototipo tiene copy real en CTAs, errores y vacíos —o solo lorem en el camino feliz?
- ¿Has validado con una tarea, no con un «qué os parece»?
- ¿Existen componentes con variantes, o cada pantalla es un collage?
- ¿Hay tokens (color, tipo, espacio) o hex sueltos en cada frame?
- ¿Están diseñados empty, error, loading y al menos un breakpoint móvil?
- ¿Un front podría construir una ruta completa sin escribirte?
- ¿Has dejado de pulir el prototipo cuando el flujo ya no se discute?
Preguntas frecuentes sobre prototipo clicable y diseño a producción
¿Qué es un prototipo clicable en Figma?
Un conjunto de pantallas enlazadas para recorrer un flujo como si fuera la interfaz. Sirve para validar recorrido y conversación. No incluye, por sí solo, el sistema de componentes ni los estados que el desarrollo necesita.
¿Cuándo no basta un prototipo clicable?
Cuando el siguiente paso es construir: ecommerce, paneles, apps con roles, cualquier interfaz que se va a repetir. Ahí hace falta diseño a producción. El prototipo puede seguir existiendo encima, como demo de flujo.
¿Hay que hacer las dos cosas siempre?
No. Un test de propuesta o un recorte de MVP puede vivir en prototipo. Una web o un producto que se va a mantener no. El criterio es la pregunta, no el hábito de «siempre prototipamos» o «siempre design system».
¿El prototipo de alta fidelidad sustituye el design system?
No. Alta fidelidad es piel. El sistema es reutilización y estados. Puedes tener una home hiperrealista y cero componentes. El front lo nota en la segunda página.
