De wireframe a las cuatro pantallas que importan
El esqueleto, la vista de lista, el panel interno y el flujo completo de acceso a confirmación.
Marca inventada para el ejercicio: Ejercicio sin marca: es el esqueleto, no la piel. No es un cliente, y ninguna cifra de esta página es un resultado medido.
Antes de escribir una línea de código hay que estar de acuerdo en qué pantallas existen y qué hace cada una. El ejercicio produce ese acuerdo: la estructura de una app de reservas, sin colores de marca ni textos definitivos, para discutir el esqueleto sin que nadie se distraiga con el tono del azul.
Cómo se hizo
El mismo recorrido que seguiría tu proyecto, en el mismo orden.
- 01
El esqueleto primero
Una pantalla de producto con su rejilla de tarjetas y su barra lateral. Sin contenido real: solo dónde va cada cosa y cuánto espacio ocupa.
- 02
La vista que el usuario usa a diario
La lista en el celular. Es la pantalla que se abre veinte veces al día, así que es la que decide si la app se siente rápida o pesada.
- 03
El panel que nadie enseña
La tabla interna en modo oscuro, con filtros y estados. Toda app tiene una trastienda donde alguien resuelve los problemas, y suele ser lo último que se diseña y lo primero que se usa.
- 04
El flujo entero, de una vez
Acceso, feed, detalle, confirmación. Puestas en fila se ve lo que no se ve pantalla a pantalla: si sobran pasos, si falta una confirmación, si el usuario sabe dónde está.
Lo que la IA no resolvió sola
Tú tienes la misma IA que nosotros. Esto es lo que hay entre el primer resultado y algo que se puede publicar.
- Estas piezas están en gris a propósito, y esa es la decisión de fondo. Un wireframe con colores de marca y textos definitivos se discute por el color; uno en gris se discute por la estructura, que es lo que hay que decidir en este momento.
- El primer intento salió con texto simulado en cada tarjeta —lorem ipsum y palabras que no existen— y era peor que no poner nada: obliga a leer para descubrir que no dice nada. Las barras grises admiten de entrada que ahí va contenido que todavía no está escrito.
- La cuarta pieza existe porque las otras tres no bastaban. Tres pantallas sueltas no dicen si el recorrido funciona; puestas en secuencia, sí.
- El panel interno se diseñó en la misma tanda que las pantallas de cliente, no después. Dejarlo para el final es la razón por la que tantas herramientas internas parecen de otra época.
Lo que salió
- Nano Banana Pro (Gemini 3 Pro Image)
- Next.js y TypeScript para lo que se construye
- Criterio humano
La app funcionando. Esto es la fase de acuerdo, no la entrega. Si quieres ver software nuestro en marcha, el portal de clientes de esta misma web lo es: lo construimos nosotros y es donde seguirás tu proyecto.