Parte 1: de la idea al primer diseño research, planificación y UI

---

Diseñar una app solía requerir tres cosas que casi nadie tiene al empezar: presupuesto para un diseñador, conocimientos de Figma y tiempo. En abril de 2026 ese muro se ha caído.

Con un LLM para estructurar la idea y Stitch de Google que en marzo de 2026 recibió la actualización Stitch 2.0 que lo convierte en un canvas AI-native capaz de generar hasta 5 pantallas interconectadas a la vez — cualquiera puede pasar de una idea vaga a un prototipo navegable en una tarde. Y todo gratis: Stitch ofrece 350 generaciones al mes en modo estándar sin pedir tarjeta.

Este es el primer artículo de una serie de dos. En este cubrimos las tres fases previas a la construcción: investigación del mercado, planificación de funcionalidades y diseño de interfaz. En el segundo pasaremos del diseño de Stitch al código funcional con vibe coding.

Para que el tutorial sea aplicable, lo vamos a hilar con un ejemplo concreto: una app de portfolio móvil para estudiantes creativos que quieren conseguir prácticas en agencias. Un caso real donde el dolor está claro (LinkedIn no muestra trabajo creativo, Behance no lo usan los juniors, los PDFs no los abre nadie) y donde el diseño móvil-first importa mucho.

Por qué el diseño móvil-first no es una opción: los datos

Antes de abrir Stitch, hay que entender por qué cada decisión de diseño que vamos a tomar está orientada a móvil. No es preferencia estética: los datos son contundentes.

El contexto global y español

Dato	Cifra	Fuente
Usuarios de móvil en el mundo	5,78 mil millones (70,5% población mundial)	DataReportal, 2025
Tráfico web desde móvil	63% (dic 2024)	DataReportal, 2025
Inversión publicitaria digital en móvil	65,3% del total	Statista, 2024
Acceso a redes sociales desde móvil en España	98%	IAB Spain, 2024
Penetración de WhatsApp en móvil España	91%	IAB Spain, 2024
Tiempo diario en redes (18-24 años España)	1h 29min	IAB Spain, 2024

En España, como resume el estudio del IAB, el móvil no es preferido es prácticamente el único canal. Si la app no funciona en móvil, no funciona.

Los datos que definen cada decisión de UI

Estos son los datos que justifican cada decisión que vamos a tomar al diseñar. Cada uno tiene consecuencias directas en cómo construimos la interfaz:

Thumb zone: dónde colocar los botones Según el estudio de Steven Hoober publicado en UXmatters (2013, con 1.333 observaciones), el 75% de las interacciones móviles se hacen con el pulgar. Nielsen Norman Group (2023) cuantificó la precisión por zona: 96% en la zona verde (parte baja central), 84% en la amarilla (media) y 61% en la roja (esquinas superiores). Consecuencia: los CTAs principales van siempre abajo.

Velocidad: el umbral de los 3 segundos Google (2023) documenta que el 53% de las visitas móviles se abandonan si la página tarda más de 3 segundos en cargar. Aberdeen Group (2023) añade que cada segundo de retraso reduce las conversiones un 7%. La media actual en móvil según Tooltester (2024) es 8,6 segundos — la mayoría de apps están muy por encima del umbral crítico.

Tamaño de los botones: el mínimo no es negociable Apple Human Interface Guidelines (2024) marca 44×44 puntos como mínimo. Google Material Design (2024) marca 48×48 dp. W3C WCAG 2.2 (2023) exige al menos 24×24 CSS pixels para cumplir nivel AA. Design Monks (2025) documenta que 50 píxeles (unos 10×10 mm) es el tamaño más cómodo porque coincide con la punta del dedo medio.

Simplicidad: la regla de los 8 segundos Nielsen Norman Group (2024) establece que un usuario da aproximadamente 8 segundos a una interfaz antes de abandonar. El caso Airbnb documentado por Medium (2025) mostró que rediseñar la navegación siguiendo la thumb zone aumentó la interacción con features un 38% — no porque las features fueran nuevas, sino porque eran más fáciles de alcanzar.

Formularios: el cuello de botella Typeform (2025) reporta que los formularios móviles tienen menos del 50% de completion rate. El estudio clásico de Luke Wroblewski (2009, sigue vigente) sobre inline validation documenta: +22% success rate, -42% tiempo de completion y -47% fijaciones visuales con validación en línea. Google (2024) añade que el autofill completa formularios un 30% más rápido.

Feedback inmediato: el silencio mata la app Instabug (2022) documenta que el 90% de los usuarios ha dejado de usar una app por mala performance. Cada acción necesita respuesta visible: cambio de color al pulsar (0-100ms), micro-animaciones (200-300ms), feedback háptico en acciones importantes.

La realidad del App Store: retención

Dato	Cifra	Fuente
Tiempo diario en apps (iOS)	4,2 horas	AppsCre8ve, 2025
Usuarios que abren apps 11+ veces al día	49%	AppsCre8ve, 2025
Apps que retienen usuarios tras 30 días	30%	AppsCre8ve, 2025
Churn tras el primer uso	25%	Rentamac, 2025
Churn en 90 días	71%	Rentamac, 2025
Facturación desarrolladores App Store 2024	1,3 trillones USD	Apple Newsroom, 2026

La frase que resume todo esto: «Getting downloaded is easy. Staying on someone’s phone is hard.» (Rentamac, 2025).

El diseño de la primera pantalla y las primeras interacciones decide si entras en ese 30% que retiene o en el 71% que churna. Por eso este tutorial empieza por investigación y planificación antes de tocar Stitch.

El workflow completo: de la idea al primer prototipo

El flujo que vamos a seguir combina cuatro piezas, todas gratuitas:

1. Un LLM (Claude, ChatGPT o Gemini) para investigar, estructurar la idea y generar prompts de diseño
2. Stitch de Google (stitch.withgoogle.com) para generar las pantallas UI
3. Los datos de diseño móvil-first para justificar cada decisión
4. Un artículo de research previo — si no has investigado antes de diseñar, estás construyendo sobre humo. Para esto remito al tutorial que ya tenemos en AiShotLab sobre investigación con agentes de IA

Nota sobre los LLMs: Claude sigue siendo el que mejor gestiona prompts estructurados complejos, pero los créditos gratuitos se gastan antes. ChatGPT y Gemini funcionan bien para la fase de ideación. Stitch 2.0 usa Gemini 2.5 Pro por detrás, así que si vas a mantener todo en el ecosistema Google, Gemini tiene sentido para el brief.

Nuestro caso práctico: Portfolio móvil para juniors creativos

Vamos a diseñar una app que resuelve un dolor real: los estudiantes de publicidad, diseño y comunicación necesitan enseñar su trabajo para conseguir prácticas, pero las opciones actuales son malas. LinkedIn no muestra trabajo creativo, Behance está pensado para seniors, el portfolio en PDF nadie lo abre, y las agencias pierden tiempo buscando junior talent sin filtros útiles.

La propuesta: una app móvil donde los estudiantes construyen su portfolio en vertical, optimizado para scroll en el móvil, y las agencias pueden descubrir talento filtrando por skills (copy, art direction, estrategia, social, UX) y universidad.

Fase 1: Investigación del mercado

Antes de empezar a pensar en pantallas, necesitas datos reales sobre: el mercado, los competidores, el comportamiento del usuario y las tendencias de diseño del vertical. Saltarse esta fase es la razón número uno por la que las apps terminan en el 71% de churn a 90 días.

El artículo de AiShotLab sobre research con agentes de IA cubre el método completo. Aquí me centro en lo mínimo imprescindible que necesitas antes de diseñar.

Meta-prompt para investigación inicial del mercado

Pasa este prompt a tu LLM (con capacidad de búsqueda web activada — en Claude, ChatGPT o Gemini):

Actúa como analista de mercado especializado en producto digital y apps móviles.

Voy a diseñar una app con esta propuesta inicial:
- Nombre tentativo: [NOMBRE_APP]
- Problema que resuelve: [PROBLEMA]
- Usuarios objetivo: [USUARIO_PRIMARIO] y [USUARIO_SECUNDARIO]
- Mercado: [PAIS/REGION]

Información del equipo (clave para el éxito del proyecto):
- Skills técnicos del equipo: [QUÉ_SABE_HACER_EL_EQUIPO]
- Contactos o red relevante: [SECTORES_Y_PERSONAS_A_LAS_QUE_TENEMOS_ACCESO]
- Recursos disponibles: [TIEMPO_DINERO_HERRAMIENTAS]
- Experiencia previa en el vertical: [AÑOS_O_PROYECTOS_RELACIONADOS]

Necesito que investigues con búsqueda web y me devuelvas:

1. Tamaño y crecimiento del mercado (datos recientes 2024-2026)
2. Top 5 competidores directos e indirectos, con sus puntos fuertes 
   y débiles
3. Comentarios reales de usuarios sobre los competidores: busca en 
   App Store, Google Play, Reddit, Trustpilot, X y foros 
   especializados. Lo que MÁS les gusta y lo que MÁS les frustra. 
   Este es el insight más valioso de todo el research — los 
   reviews negativos de competidores son oro puro para encontrar 
   oportunidades.
4. Comportamiento del usuario: patrones de uso, frustraciones 
   documentadas, demografía
5. Tendencias de diseño actuales en este vertical
6. Oportunidades claras de diferenciación
7. ROAST ME: ataca los vectores débiles del proyecto. Sé brutal 
   y específico. Analiza:
   - Debilidades del concepto: ¿por qué podría fracasar?
   - Debilidades del equipo para ejecutar esto concreto: ¿qué no 
     sabemos hacer?, ¿qué contactos no tenemos?, ¿qué recursos 
     faltan?
   - Competidores que podrían aplastarnos en 3 meses si copian la 
     idea
   - Supuestos no validados en los que nos estamos apoyando
   - Problemas de monetización, legales o de unit economics
   Este punto es crítico. No seas amable, sé honesto.
8. AMPLIFICADORES: cómo las ventajas competitivas del equipo 
   (técnicas, contactos, financiación, red, experiencia) pueden 
   amplificar esta idea concreta. ¿Qué hacemos nosotros que los 
   competidores no pueden? Una idea mediocre con amplificadores 
   fuertes le gana siempre a una idea brillante sin ellos.

FORMATO DE RESPUESTA:

Devuelve CADA sección en su PROPIO bloque de código JSON 
independiente. NO agrupes todo en un solo bloque. Cada sección 
debe ir en su propio bloque ```json ``` separado, para que pueda 
copiarlo individualmente.

Cada bloque debe seguir esta estructura:

{
  "seccion": "mercado|competidores|reviews_usuarios|comportamiento|tendencias|oportunidades|roast_me|amplificadores",
  "hallazgos": [
    {
      "dato": "hallazgo concreto",
      "fuente": "fuente real con año (URL si aplica)",
      "implicacion_diseño": "qué significa para el diseño o la estrategia"
    }
  ],
  "insight_clave": "la conclusión más importante de esta sección"
}

Formato esperado:

Sección 1 - Mercado:
```json
{ ...objeto JSON de mercado... }

Sección 2 – Competidores:

{ ...objeto JSON de competidores... }

(y así sucesivamente hasta las 8 secciones)

IMPORTANTE: Solo incluye datos que puedas verificar con fuentes reales. Si no encuentras un dato, indícalo explícitamente en lugar de inventar cifras. Nunca fabriques fuentes. En reviews de usuarios, cita la review concreta con plataforma de origen.

¿Por qué pedir JSON aquí? Porque el research arroja muchos datos de distinta naturaleza (cifras, citas, fuentes, insights) y necesitas poder filtrarlos, comparar secciones y retomar el análisis días después. El JSON te permite abrir un bloque concreto (por ejemplo, solo «roast_me») sin tener que releer todo. Además, si más adelante quieres pedirle al LLM que profundice en una sección, le pasas solo ese objeto JSON como input y sigues iterando sobre datos estructurados, no sobre texto corrido.

Qué hacer con los resultados del research

No necesitas leer cada dato a fondo. Lo que estás buscando son cinco cosas concretas:

1. Un hueco real de mercado — no algo que ya resuelvan 10 apps
2. Un patrón de frustración documentado en reviews reales — reviews de App Store/Google Play con menos de 3 estrellas, threads de Reddit quejándose, posts de foros. Estas frustraciones son la hoja de ruta de tu app
3. Una convención de diseño que puedes romper conscientemente — si todos los portfolios se enseñan en grid horizontal, hacer vertical puede ser tu diferenciador
4. Los puntos del ROAST ME que son reales — no los ignores. Si el análisis dice «no tenéis contactos en agencias», o haces algo para conseguirlos o cambias de idea. Los proyectos que fracasan son los que ven el roast-me y lo archivan
5. Los amplificadores que encajan con la idea — si tienes un contacto en una agencia grande, o un skill técnico concreto, o experiencia en el vertical, la idea debe aprovechar eso explícitamente. Una idea mediocre amplificada gana a una idea brillante sin amplificar

En el caso de nuestra app de portfolios para juniors, el research debería arrojar cosas como: Behance tiene alta reputación pero mala UX móvil, LinkedIn domina pero no tiene forma de mostrar trabajo creativo, las agencias tienen procesos de hiring junior muy poco estructurados, los estudiantes usan Instagram como portfolio improvisado. Y del roast-me: ¿tenemos contactos reales en agencias que prueben la app?, ¿sabemos cómo validar que un junior es bueno sin ser nosotros directores creativos?, ¿qué pasa cuando LinkedIn copie esta feature?

Fase 2: Planificación de funcionalidades

Aquí es donde la mayoría se equivoca: empieza a listar features sin priorizar, acaba con 40 funcionalidades en el MVP y la app no sale nunca.

El método que vamos a usar combina dos marcos probados: Jobs-to-be-Done para entender qué está intentando conseguir el usuario (no qué features quiere), y MoSCoW para priorizar qué entra en el MVP.

Paso 1: Definir los Jobs-to-be-Done

El framework JTBD parte de esta idea: los usuarios no quieren usar tu app, quieren resolver un «trabajo» en su vida. Una feature que no sirve a ningún job es ruido.

Meta-prompt para definir Jobs-to-be-Done

Actúa como product strategist especializado en Jobs-to-be-Done 
framework.

Con la información de mi app:
- Propuesta: [PROPUESTA_DE_VALOR]
- Usuario primario: [USUARIO_PRIMARIO]
- Usuario secundario: [USUARIO_SECUNDARIO] (si aplica)
- Contexto: [DONDE_CUANDO_SE_USA_LA_APP]

Genera los Jobs-to-be-Done principales que la app debe resolver, 
redactados según la fórmula:

"Cuando [situación], quiero [motivación], para poder [resultado 
esperado]."

Genera:
- 5 jobs del usuario primario
- 3 jobs del usuario secundario (si aplica)

FORMATO DE RESPUESTA:

Devuelve CADA job en su PROPIO bloque de código JSON independiente. 
NO agrupes todos los jobs en un solo bloque. Cada bloque debe ir en 
su propio ```json ``` separado.

Estructura de cada objeto:

{
  "id": 1,
  "tipo_usuario": "primario|secundario",
  "job": "Cuando X, quiero Y, para poder Z.",
  "categoria": "funcional|emocional|social",
  "frecuencia": "alta|media|baja",
  "criticidad": "critica|importante|nice_to_have",
  "evidencia": "de dónde viene este job (research, competidor, 
                entrevista)"
}

Formato esperado:

Job 1:
```json
{ ...objeto JSON... }
```

Job 2:
```json
{ ...objeto JSON... }
```

(y así sucesivamente)

Solo objetos JSON, sin texto adicional entre bloques más allá del 
título "Job N:".

Paso 2: Listar features y priorizar con MoSCoW

Una vez tienes los jobs claros, listas las features y las priorizas. MoSCoW divide en cuatro categorías:

• Must have — sin esto la app no funciona, no resuelve el job principal
• Should have — importante pero la app funciona sin ello en V1
• Could have — mejoras que añaden valor pero no son críticas
• Won’t have (esta vez) — ideas a descartar del MVP

Meta-prompt para priorización MoSCow

Actúa como product manager senior especializado en priorización 
de features para MVPs móviles.

Tengo estos Jobs-to-be-Done para mi app [NOMBRE_APP]:

[PEGA AQUÍ LOS JOBS DEL PASO ANTERIOR]

Y esta lista inicial de features que estoy considerando:

[LISTA_DE_FEATURES_EN_BRUTO]

Genera una priorización MoSCoW con foco en MVP móvil viable en 
4-6 semanas de desarrollo.

Principios de priorización que debes aplicar:
- Si una feature no sirve a ningún job, va a Won't have
- Si dos features sirven al mismo job, quédate con la más simple
- Must have solo si es imprescindible para que la app funcione
- Piensa en móvil primero: cada feature consume espacio de pantalla
- Considera el dato de Nielsen Norman Group 2024: los usuarios dan 
  ~8 segundos a una app antes de abandonar, por lo que el MVP debe 
  resolver el job principal de forma inmediata

FORMATO DE RESPUESTA:

Devuelve CADA feature en su PROPIO bloque de código JSON 
independiente. NO agrupes todas las features en un solo bloque. 
Cada bloque en su propio ```json ``` separado.

Estructura:

{
  "id": 1,
  "nombre_feature": "nombre corto de la feature",
  "prioridad_moscow": "must|should|could|wont",
  "job_al_que_sirve": "ID del job o 'ninguno'",
  "descripcion": "qué hace y por qué",
  "complejidad_dev": "baja|media|alta",
  "impacto_usuario": "bajo|medio|alto",
  "incluir_en_mvp": true,
  "justificacion_prioridad": "por qué está en esta categoría"
}

Formato esperado:

Feature 1:
```json
{ ...objeto JSON... }
```

Feature 2:
```json
{ ...objeto JSON... }
```

Al final, añade un bloque resumen:

Resumen MVP:
```json
{
  "total_features_analizadas": X,
  "must_have": X,
  "should_have": X,
  "could_have": X,
  "wont_have_mvp": X,
  "estimacion_semanas_dev": X,
  "riesgos_principales": ["riesgo 1", "riesgo 2"]
}
```

Paso 3: Mapear los flujos principales

Antes de entrar en Stitch necesitas saber qué flujos va a tener la app. Un flujo es una secuencia de pantallas que cubre un job completo. Por ejemplo, en la app de portfolio: «descubrir talento junior» es un flujo (login agencia → filtros → grid perfiles → detalle perfil → contacto), distinto del flujo «construir mi portfolio» del lado del estudiante.

Stitch 2.0 genera hasta 5 pantallas interconectadas en una sola operación, así que este paso determina cómo vas a agrupar tus peticiones.

Meta-prompt para mapeo de flujos

Actúa como UX designer especializado en flujos de usuario para 
apps móviles.

Con estas features Must-have y Should-have de mi MVP:

[PEGA LAS FEATURES MUST + SHOULD DEL PASO ANTERIOR]

Y estos Jobs-to-be-Done principales:

[PEGA LOS JOBS MÁS CRÍTICOS]

Agrupa las features en flujos de usuario coherentes. Cada flujo 
debe tener entre 3 y 5 pantallas (para aprovechar la generación 
multi-pantalla de Stitch 2.0).

Principios de diseño a respetar en cada flujo:
- Thumb zone: CTAs primarios en la zona inferior (Nielsen Norman 
  Group, 2023: 96% de precisión vs 61% en la zona superior)
- Una acción primaria por pantalla máximo (Nielsen Norman Group, 
  2024)
- Máximo 5-6 secciones en navegación principal (Nielsen Norman 
  Group, 2023)
- Formularios en columna única, un campo por pantalla cuando sea 
  posible (Typeform, 2025: <50% completion rate en forms largos)

FORMATO DE RESPUESTA:

Devuelve CADA flujo en su PROPIO bloque de código JSON independiente.

Estructura:

{
  "id_flujo": 1,
  "nombre_flujo": "nombre descriptivo",
  "job_que_cubre": "ID del job principal",
  "tipo_usuario": "primario|secundario",
  "prioridad": "critico|importante",
  "pantallas": [
    {
      "numero": 1,
      "nombre": "nombre de la pantalla",
      "proposito": "para qué sirve",
      "accion_primaria": "cuál es el único CTA principal",
      "accion_primaria_posicion": "zona_inferior|centro|superior",
      "elementos_clave": ["elemento 1", "elemento 2"]
    }
  ],
  "transicion_entre_pantallas": "cómo se pasa de una a otra"
}

Formato esperado:

Flujo 1:
```json
{ ...objeto JSON... }
```

Flujo 2:
```json
{ ...objeto JSON... }
```

Solo objetos JSON, cada uno en su bloque.

Paso 4 (bonus): Visualizar los flujos antes de diseñar

Este paso es opcional pero muy recomendable. Antes de meter nada en Stitch, es útil tener un esquema visual de cada flujo — sin diseño, sin estilo, solo cajas, flechas y texto — que puedas compartir con el equipo, imprimir o tener a mano mientras trabajas.

Para esto usamos Nano Banana 2 en Flow (mismo flujo que explicamos en nuestro tutorial de key visuals con Nano Banana 2), pero pidiéndole esquemas de flujo en lugar de imágenes realistas. Esto te da una vista cenital de tu app en 10 minutos.

Meta-prompt para diagramas de flujo visuales

Actúa como UX strategist especializado en visualización de flujos 
de usuario.

Con estos flujos definidos para mi app [NOMBRE_APP]:

[PEGA LOS FLUJOS DEL PASO ANTERIOR]

Genera 6 prompts para Nano Banana 2 que creen diagramas de flujo 
esquematizados de cada flujo principal. NO son mockups de diseño 
— son diagramas conceptuales tipo whiteboard con cajas, flechas, 
texto simple y colores básicos.

Cada prompt debe producir:
- Cajas rectangulares simples representando cada pantalla
- Flechas claras indicando la navegación entre pantallas
- Texto corto dentro de cada caja con el nombre de la pantalla 
  y su acción principal
- Máximo 3-4 colores (1 para el flujo principal, 1 para acciones 
  críticas, 1 para estados finales, 1 fondo neutro)
- Sin elementos decorativos ni renders realistas
- Estilo tipo diagrama de Miro / Whimsical / whiteboard limpio
- Fondo blanco o muy claro para máxima legibilidad

Distribuye los 6 prompts:
- 4 prompts: uno por cada flujo principal del usuario primario
- 2 prompts: flujos del usuario secundario o alternativos

FORMATO DE RESPUESTA:

Devuelve CADA prompt en su propio bloque JSON separado.

{
  "id": 1,
  "flujo_que_representa": "nombre del flujo",
  "tipo_usuario": "primario|secundario",
  "num_pantallas_en_diagrama": X,
  "prompt_en": "prompt completo en inglés listo para Nano Banana 2",
  "negative_prompt": "3d render, cgi, realistic photo, hyperrealistic, 
                      complex illustration, decorative elements",
  "uso_recomendado": "cuándo y cómo usar este diagrama"
}

Formato esperado:

Diagrama 1:
```json
{ ... }
```

Diagrama 2:
```json
{ ... }
```

(hasta diagrama 6)

IMPORTANTE: Los prompts deben pedir explícitamente estilo 
"schematic diagram", "flat vector wireframe flow", "minimal 
whiteboard style". NO pidas fotorrealismo. NO uses "4K", "8K" 
o "hyperrealistic" (siguen activando CGI bias como explicamos 
en el tutorial de fotos de producto).

Por qué este paso merece la pena: tener los 4-6 flujos impresos en A4 al lado del portátil mientras trabajas en Stitch evita que pierdas el contexto cuando llevas 2 horas iterando en una pantalla. Además es el tipo de entregable que funciona muy bien para validar con no-diseñadores (cliente, profesores, inversores, team) antes de meter tiempo en el diseño final.

Fase 3: Diseño de la interfaz con Stitch

Con los flujos claros, ahora vamos a generar los diseños en Stitch. La clave no es describir cada pantalla a Stitch de memoria: es construir un prompt estructurado que incluya contexto de marca, principios de diseño móvil-first y la especificación clara del flujo.

Antes de abrir Stitch: el brief visual

Stitch 2.0 permite subir imágenes como contexto (screenshots de competidores, moodboards, sketches). También ha incorporado un concepto de design system donde puedes definir colores, tipografía y tokens que se mantienen coherentes entre las 5 pantallas que genera.

Antes de generar nada, define con el LLM tu brief visual:

Meta-prompt para brief visual de la app

Actúa como art director especializado en diseño móvil y branding 
de apps.

Con esta información de mi app:
- Nombre: [NOMBRE_APP]
- Propuesta de valor: [PROPUESTA]
- Usuario primario: [USUARIO]
- Tono deseado: [PROFESIONAL/JOVEN/MINIMALISTA/JUGUETON/etc.]
- Competidores de referencia: [COMPETIDORES_QUE_ME_GUSTAN_VISUALMENTE]
- Competidores a evitar visualmente: [COMPETIDORES_FEOS_O_SATURADOS]

Genera un brief visual completo que voy a usar como contexto 
en Stitch de Google.

Incluye:
- Paleta de colores (primario, secundario, acento, neutros, 
  semánticos) con códigos HEX
- Sistema tipográfico (familia display, familia body, 2-3 tamaños 
  máximo por pantalla - W3C: mínimo 16px para texto legible)
- Corner radius (tokens)
- Espaciado (grid base 4 u 8 pt)
- Estilo visual general (plano, con profundidad, neo-morphism, etc.)
- Principios de contraste (WCAG 2.2: mínimo 4.5:1 para texto)
- Tamaños mínimos de touch targets (Apple: 44pt, Google: 48dp, 
  ideal: 50px según Design Monks 2025)

FORMATO DE RESPUESTA:

Un único bloque JSON con todo el design system:

```json
{
  "app_name": "...",
  "design_tokens": {
    "colors": {
      "primary": "#HEX",
      "primary_dark": "#HEX",
      "secondary": "#HEX",
      "accent": "#HEX",
      "background": "#HEX",
      "surface": "#HEX",
      "text_primary": "#HEX",
      "text_secondary": "#HEX",
      "success": "#HEX",
      "error": "#HEX",
      "warning": "#HEX"
    },
    "typography": {
      "display_font": "nombre",
      "body_font": "nombre",
      "heading_size": "32px",
      "subheading_size": "20px",
      "body_size": "16px",
      "caption_size": "14px"
    },
    "spacing_base": "8px",
    "corner_radius": {
      "small": "8px",
      "medium": "16px",
      "large": "24px"
    },
    "touch_targets": {
      "minimum": "44px",
      "comfortable": "48px",
      "ideal": "50px"
    },
    "contrast_minimum": "4.5:1"
  },
  "visual_style": "descripción en 2-3 frases del estilo general",
  "tone_keywords": ["palabra1", "palabra2", "palabra3"],
  "reference_apps": ["app de referencia 1", "app de referencia 2"]
}
```

Meta-prompt para generar pantallas en Stitch

Este es el prompt que le pasarás a Stitch. Está diseñado para aprovechar la generación multi-pantalla de Stitch 2.0.

Actúa como senior mobile UI designer especializado en apps móviles.

Voy a generar pantallas en Stitch de Google. Dame el prompt final 
en inglés, listo para pegar en Stitch, para este flujo:

Flujo: [NOMBRE_FLUJO]
Pantallas: [NUMERO_PANTALLAS entre 3 y 5]
Design system: [PEGA EL BRIEF VISUAL DEL PASO ANTERIOR]
Descripción de cada pantalla:
1. [DESCRIPCION_PANTALLA_1]
2. [DESCRIPCION_PANTALLA_2]
3. [DESCRIPCION_PANTALLA_3]
(etc.)

El prompt final debe incluir:
- Descripción clara de cada pantalla y su propósito
- Especificación de la acción primaria de cada pantalla y su 
  posición (siempre en zona inferior para CTAs principales)
- Tokens de diseño concretos (colores HEX, tipografía, radios)
- Tamaños de touch targets (mínimo 44-48px)
- Espaciado consistente (base 8pt)
- Estilo general coherente con el brief
- Principio explícito: "one primary action per screen"
- Formato móvil portrait (iPhone-like proportions)

FORMATO DE RESPUESTA:

Devuelve TRES bloques JSON separados:

Bloque 1 - Prompt para Stitch:
```json
{
  "stitch_prompt_en": "el prompt completo en inglés listo para 
   pegar en Stitch, muy detallado"
}
```

Bloque 2 - Checklist de validación:
```json
{
  "checklist_post_generacion": [
    "item 1 a verificar en el output de Stitch",
    "item 2",
    "..."
  ]
}
```

Bloque 3 - Variaciones de prueba:
```json
{
  "variaciones_recomendadas": [
    {
      "variacion": "qué cambiar",
      "por_que": "qué quieres testear"
    }
  ]
}
```

Cómo usar Stitch paso a paso

Una vez tienes el prompt final, esto es lo que haces en stitch.withgoogle.com:

1. Abre Stitch y selecciona «New canvas» La versión 2.0 te lleva al canvas AI-native, no a una interfaz de prompt simple. El canvas es infinito: vas a poder generar varias iteraciones en paralelo.

2. Pega el prompt en el campo de generación Stitch acepta prompts largos. No tengas miedo de pasarle todo el contexto: design tokens, descripción de pantallas, principios de diseño. Cuanto más específico, mejor output. Puedes también usar voice input si prefieres dictar.

3. Sube imágenes de referencia (opcional pero recomendado) Si tienes screenshots de apps que visualmente te inspiran, arrástralas al canvas. Stitch las usa como contexto. Esto es especialmente útil para guiar el estilo visual sin tener que describirlo todo con palabras.

4. Genera el flujo completo En modo Standard (Gemini 2.5 Flash) genera rápido y tienes 350 generaciones al mes. En modo Experimental (Gemini 2.5 Pro) la calidad es más alta pero consumes más y hay 50 al mes. Para iterar rápido empieza en Standard; para finales en Experimental.

5. Itera en el canvas Cada generación se queda en el canvas. No la sobrescribe. Puedes generar variaciones, compararlas y mezclar elementos de distintas iteraciones. Este flujo de trabajo es nuevo en Stitch 2.0 y cambia mucho la dinámica respecto a la versión original.

6. Usa la función Annotate para afinar Si algo no te gusta, puedes dibujar o escribir directamente sobre la pantalla generada. Stitch interpreta la anotación (con Gemini por detrás) y aplica el cambio contextualmente. Mucho más rápido que regenerar todo desde cero.

7. Ajusta el theme global El panel lateral de Theme te permite cambiar colores, tipografía, corner radius y toggle de dark mode sobre todo el flujo de una vez. Esto mantiene la consistencia entre pantallas, que es uno de los puntos fuertes de Stitch 2.0.

8. Exporta Cuando el diseño está listo: paste a Figma para refinar (mantiene capas y Auto Layout), o exporta el código HTML/CSS/Tailwind/Flutter. También hay export directo a Firebase Studio para pasar a desarrollo en el ecosistema Google.

Checklist de validación post-generación

Stitch genera UI convincente, pero no siempre respeta los principios móvil-first al 100%. Revisa cada pantalla contra este checklist antes de dar por bueno el diseño:

• CTAs principales en la zona inferior (thumb zone verde, 96% precisión)
• Ningún CTA crítico en esquinas superiores (zona roja, 61% precisión)
• Touch targets mínimo 44-48px en todos los elementos interactivos
• Gap mínimo de 8-12px entre botones adyacentes
• Una sola acción primaria visible por pantalla
• Máximo 5-6 items en navegación bottom
• Texto body mínimo 16px
• Contraste texto/fondo mínimo 4.5:1 (nivel WCAG AA)
• Máximo 2-3 tamaños de fuente por pantalla
• Máximo 2-3 colores principales (sin contar neutros)
• Formularios en columna única
• Progress indicator visible en flujos multi-paso
• Estados de feedback definidos (normal/pressed/loading/success)
• Consistencia entre las pantallas del flujo

Si alguna pantalla falla el checklist, usa Annotate directamente sobre esa pantalla indicando qué cambiar, o ajusta el prompt y regenera solo ese flujo.

Refinado iterativo: el segundo pase

Después del primer pase, casi siempre hay cosas que mejorar. En lugar de tirar todo y regenerar, usa este prompt de refinado.

Meta-prompt de refinado de diseño

Tengo generadas estas pantallas en Stitch para mi app [NOMBRE_APP]:

[DESCRIBE QUÉ PANTALLAS TIENES Y QUÉ FLUJO CUBREN]

Quiero refinar los siguientes aspectos:

Aspectos que SÍ me gustan y quiero mantener:
- [ASPECTO_1]
- [ASPECTO_2]

Aspectos a mejorar:
- [PROBLEMA_1]
- [PROBLEMA_2]

Genera 3 prompts de refinado para Stitch, cada uno atacando un 
enfoque distinto:
- Prompt 1: cambios mínimos (solo arreglar los problemas concretos)
- Prompt 2: cambios medios (aprovechar para mejorar 1-2 elementos 
  visuales adicionales)
- Prompt 3: rediseño parcial (mantener estructura pero explorar 
  dirección visual alternativa)

Principios a respetar en todos los prompts:
- Thumb zone (CTAs abajo)
- Touch targets mínimo 44-48px
- Contraste 4.5:1
- Una acción primaria por pantalla
- Consistencia visual con el resto del flujo

FORMATO DE RESPUESTA:

Devuelve CADA prompt de refinado en su PROPIO bloque JSON separado:

Refinado 1 - Cambios mínimos:
```json
{
  "tipo_refinado": "cambios_minimos",
  "stitch_prompt_en": "prompt en inglés listo para Stitch",
  "cambios_esperados": ["cambio 1", "cambio 2"]
}
```

Refinado 2 - Cambios medios:
```json
{ ... }
```

Refinado 3 - Rediseño parcial:
```json
{ ... }
```

Errores comunes al diseñar apps con IA

Estos son los patrones de fallo que vemos una y otra vez. Tenerlos delante ayuda a no caer en ellos:

1. Saltarse la investigación y la planificación El atractivo de Stitch es que genera UI bonita en segundos. La tentación es ir directo. El resultado: una app visualmente impecable que no resuelve ningún job real. Termina en el 71% de churn de Rentamac (2025).

2. Prompt vago = output genérico «Design a portfolio app» devuelve una app de portfolio de 2018. «Design a portfolio app for junior creative students targeting advertising agencies, vertical scroll, dark mode primary, thumb-zone CTAs, minimum 44px touch targets, maximum 3 colors» devuelve algo utilizable.

3. Ignorar la thumb zone Es el error más común. La IA tiende a colocar CTAs en la parte superior porque visualmente «quedan mejor». Consecuencia: el 35% de diferencia de precisión entre la zona verde (96%) y la roja (61%) según Nielsen Norman Group (2023). Corrige siempre en el prompt.

4. Demasiadas features en el MVP Sin MoSCoW, cada feature parece «must have». El MVP se hincha, el desarrollo se retrasa, la app nunca sale. Si tienes más de 8 features en Must-have, vuelve a priorizar.

5. Contraste insuficiente Especialmente en modo oscuro, la IA genera a veces texto gris sobre fondo gris. No cumple WCAG 2.2. El 1 de cada 6 personas con alguna forma de discapacidad (W3C WAI, 2024) no puede usar tu app.

6. Formularios largos en pantalla única Stitch a veces junta 6 campos en una pantalla. Con <50% completion rate en forms móviles según Typeform (2025), divide siempre en pasos.

7. No usar el canvas de Stitch 2.0 Si tratas Stitch como «generador de pantalla única», estás desaprovechando lo más potente del update de marzo 2026. Genera variaciones en paralelo, compara, mezcla.

Priorización: qué fase te importa más según tu situación

Si vas justo de tiempo, este es el orden de impacto de cada fase:

Prioridad	Fase	Impacto si la saltas
1	Investigación	Construyes sobre humo. 71% de churn en 90 días
2	Jobs-to-be-Done	Features sin propósito. Usuarios confundidos
3	MoSCoW priorización	MVP hinchado. Nunca sale
4	Brief visual	Inconsistencia. Percepción amateur
5	Diseño en Stitch	Último paso, sin lo anterior no sirve

La tentación es empezar por el 5. La app que funciona empieza siempre por el 1.

Bloque final: todos los meta-prompts recopilados

1) Meta-prompt para investigación inicial del mercado

Actúa como analista de mercado especializado en producto digital 
y apps móviles.

Voy a diseñar una app con esta propuesta inicial:
- Nombre tentativo: [NOMBRE_APP]
- Problema que resuelve: [PROBLEMA]
- Usuarios objetivo: [USUARIO_PRIMARIO] y [USUARIO_SECUNDARIO]
- Mercado: [PAIS/REGION]

Información del equipo (clave para el éxito):
- Skills técnicos: [QUÉ_SABE_HACER_EL_EQUIPO]
- Contactos o red relevante: [SECTORES_Y_PERSONAS]
- Recursos disponibles: [TIEMPO_DINERO_HERRAMIENTAS]
- Experiencia previa: [AÑOS_O_PROYECTOS]

Necesito que investigues con búsqueda web y me devuelvas:

1. Tamaño y crecimiento del mercado (datos 2024-2026)
2. Top 5 competidores directos e indirectos
3. Comentarios REALES de usuarios sobre competidores: busca en 
   App Store, Google Play, Reddit, Trustpilot, X y foros. Lo que 
   MÁS les gusta y lo que MÁS les frustra. Este es el insight más 
   valioso del research.
4. Comportamiento del usuario: patrones, frustraciones, demografía
5. Tendencias de diseño actuales en el vertical
6. Oportunidades de diferenciación
7. ROAST ME: ataca los vectores débiles del proyecto. Sé brutal:
   - Debilidades del concepto
   - Debilidades del equipo para ejecutar ESTO concreto
   - Competidores que podrían aplastarnos en 3 meses si copian
   - Supuestos no validados
   - Problemas de monetización, legales o unit economics
   No seas amable, sé honesto.
8. AMPLIFICADORES: cómo las ventajas del equipo (técnicas, 
   contactos, financiación, red, experiencia) pueden amplificar 
   esta idea. ¿Qué hacemos nosotros que los competidores no pueden?

FORMATO DE RESPUESTA:

Devuelve CADA sección en su propio bloque JSON separado.

{
  "seccion": "mercado|competidores|reviews_usuarios|comportamiento|tendencias|oportunidades|roast_me|amplificadores",
  "hallazgos": [
    {
      "dato": "hallazgo concreto",
      "fuente": "fuente real con año (URL si aplica)",
      "implicacion_diseño": "qué significa"
    }
  ],
  "insight_clave": "la conclusión más importante"
}

Formato: "Sección N - Nombre:" + bloque ```json```

IMPORTANTE: Solo datos verificables. Si no encuentras un dato, 
indícalo. Nunca fabriques fuentes. En reviews, cita la review 
concreta con plataforma.

2) Meta-prompt para Jobs-to-be-Done

Actúa como product strategist especializado en Jobs-to-be-Done 
framework.

Con la información de mi app:
- Propuesta: [PROPUESTA_DE_VALOR]
- Usuario primario: [USUARIO_PRIMARIO]
- Usuario secundario: [USUARIO_SECUNDARIO]
- Contexto: [CUANDO_Y_DONDE_SE_USA]

Genera los Jobs-to-be-Done, fórmula:
"Cuando [situación], quiero [motivación], para poder [resultado]."

- 5 jobs del usuario primario
- 3 jobs del usuario secundario

FORMATO DE RESPUESTA:

Devuelve CADA job en su propio bloque JSON separado.

{
  "id": 1,
  "tipo_usuario": "primario|secundario",
  "job": "Cuando X, quiero Y, para poder Z.",
  "categoria": "funcional|emocional|social",
  "frecuencia": "alta|media|baja",
  "criticidad": "critica|importante|nice_to_have",
  "evidencia": "de dónde viene este job"
}

Formato: "Job N:" + bloque ```json```

3) Meta-prompt para priorización MoSCoW

Actúa como product manager senior especializado en priorización 
de features para MVPs móviles.

Jobs-to-be-Done de mi app [NOMBRE_APP]:

[PEGA LOS JOBS]

Lista de features candidatas:

[LISTA_DE_FEATURES]

Prioriza con MoSCoW para MVP de 4-6 semanas de desarrollo.

Principios:
- Si una feature no sirve a ningún job → Won't have
- Si dos features sirven al mismo job → quédate con la más simple
- Must have solo si es imprescindible
- Regla de los 8 segundos (Nielsen Norman Group, 2024): el MVP 
  debe resolver el job principal inmediatamente

FORMATO DE RESPUESTA:

Devuelve CADA feature en su propio bloque JSON separado.

{
  "id": 1,
  "nombre_feature": "...",
  "prioridad_moscow": "must|should|could|wont",
  "job_al_que_sirve": "ID del job",
  "descripcion": "...",
  "complejidad_dev": "baja|media|alta",
  "impacto_usuario": "bajo|medio|alto",
  "incluir_en_mvp": true,
  "justificacion_prioridad": "..."
}

Al final, bloque resumen:

Resumen MVP:
```json
{
  "total_features_analizadas": X,
  "must_have": X,
  "should_have": X,
  "could_have": X,
  "wont_have_mvp": X,
  "estimacion_semanas_dev": X,
  "riesgos_principales": ["..."]
}
```

4) Meta-prompt para mapeo de flujos

Actúa como UX designer especializado en flujos de usuario móvil.

Features Must + Should del MVP:
[PEGA LAS FEATURES]

Jobs críticos:
[PEGA LOS JOBS]

Agrupa en flujos de 3-5 pantallas (para generación multi-pantalla 
de Stitch 2.0).

Principios:
- CTAs primarios en zona inferior (Nielsen Norman Group, 2023)
- Una acción primaria por pantalla
- Máx 5-6 secciones en nav principal
- Forms en columna única (Typeform, 2025)

FORMATO DE RESPUESTA:

Devuelve CADA flujo en su propio bloque JSON separado.

{
  "id_flujo": 1,
  "nombre_flujo": "...",
  "job_que_cubre": "ID",
  "tipo_usuario": "primario|secundario",
  "prioridad": "critico|importante",
  "pantallas": [
    {
      "numero": 1,
      "nombre": "...",
      "proposito": "...",
      "accion_primaria": "...",
      "accion_primaria_posicion": "zona_inferior|centro|superior",
      "elementos_clave": ["..."]
    }
  ],
  "transicion_entre_pantallas": "..."
}

5) Meta-prompt para diagramas de flujo visuales (Nano Banana 2)

Actúa como UX strategist especializado en visualización de flujos.

Flujos definidos para [NOMBRE_APP]:

[PEGA LOS FLUJOS DEL META-PROMPT 4]

Genera 6 prompts para Nano Banana 2 que creen diagramas de flujo 
esquematizados. NO son mockups de diseño — son diagramas tipo 
whiteboard con cajas, flechas, texto simple y colores básicos.

Cada prompt debe producir:
- Cajas rectangulares simples por pantalla
- Flechas claras indicando navegación
- Texto corto con nombre de pantalla + acción principal
- Máximo 3-4 colores
- Sin elementos decorativos ni renders realistas
- Estilo Miro / Whimsical / whiteboard limpio
- Fondo blanco

Distribuye los 6 prompts:
- 4 flujos del usuario primario
- 2 flujos del usuario secundario o alternativos

FORMATO: CADA prompt en su propio bloque JSON.

{
  "id": 1,
  "flujo_que_representa": "nombre del flujo",
  "tipo_usuario": "primario|secundario",
  "num_pantallas_en_diagrama": X,
  "prompt_en": "prompt en inglés para Nano Banana 2",
  "negative_prompt": "3d render, cgi, realistic photo, hyperrealistic, 
                      decorative elements",
  "uso_recomendado": "cuándo y cómo usar este diagrama"
}

Formato: "Diagrama N:" + bloque ```json```

IMPORTANTE: Usa términos "schematic diagram", "flat vector 
wireframe flow", "minimal whiteboard style". NO uses "4K", "8K" 
ni "hyperrealistic".

6) Meta-prompt para brief visual de la app

Actúa como art director especializado en diseño móvil.

Información app:
- Nombre: [NOMBRE_APP]
- Propuesta: [PROPUESTA]
- Usuario: [USUARIO]
- Tono: [PROFESIONAL/JOVEN/MINIMALISTA/etc.]
- Referencias visuales: [COMPETIDORES_QUE_GUSTAN]
- A evitar: [COMPETIDORES_FEOS]

Genera un design system completo.

Incluye: paleta (primario, secundario, acento, neutros, semánticos), 
tipografía (mín 16px body, W3C), corner radius, spacing base, 
contraste mínimo 4.5:1 (WCAG), touch targets (44pt Apple / 48dp 
Google / 50px ideal).

FORMATO: un único bloque JSON.

```json
{
  "app_name": "...",
  "design_tokens": {
    "colors": { "primary": "#HEX", ... },
    "typography": { ... },
    "spacing_base": "8px",
    "corner_radius": { ... },
    "touch_targets": { ... },
    "contrast_minimum": "4.5:1"
  },
  "visual_style": "...",
  "tone_keywords": ["..."],
  "reference_apps": ["..."]
}
```

7) Meta-prompt para generar pantallas en Stitch

Actúa como senior mobile UI designer.

Genera el prompt final en inglés para Stitch.

Flujo: [NOMBRE_FLUJO]
Pantallas: [NUMERO entre 3 y 5]
Design system: [PEGA BRIEF VISUAL]
Descripción de cada pantalla:
1. [...]
2. [...]

Incluir:
- Descripción clara de cada pantalla
- Acción primaria de cada pantalla y posición (CTAs en zona 
  inferior)
- Tokens concretos (HEX, tipo, radius)
- Touch targets mínimo 44-48px
- Spacing base 8pt
- Formato mobile portrait
- "one primary action per screen"

FORMATO: TRES bloques JSON separados.

Bloque 1 - Prompt Stitch:
```json
{ "stitch_prompt_en": "prompt completo en inglés" }
```

Bloque 2 - Checklist validación:
```json
{ "checklist_post_generacion": ["..."] }
```

Bloque 3 - Variaciones:
```json
{ "variaciones_recomendadas": [...] }
```

8) Meta-prompt de refinado de diseño

Tengo estas pantallas generadas en Stitch:
[DESCRIBE PANTALLAS]

Mantener:
- [ASPECTO_1]

Mejorar:
- [PROBLEMA_1]

Genera 3 prompts de refinado:
- Prompt 1: cambios mínimos
- Prompt 2: cambios medios
- Prompt 3: rediseño parcial

Principios: thumb zone, 44-48px targets, contraste 4.5:1, una 
acción primaria por pantalla.

FORMATO: CADA prompt en su propio bloque JSON.

Refinado 1 - Cambios mínimos:
```json
{
  "tipo_refinado": "cambios_minimos",
  "stitch_prompt_en": "prompt en inglés",
  "cambios_esperados": [...]
}
```

Refinado 2 - Cambios medios:
```json
{ ... }
```

Refinado 3 - Rediseño parcial:
```json
{ ... }
```

Cuándo necesitas ir más allá de las herramientas gratuitas

Este workflow te lleva de una idea a un prototipo completo navegable. Pero hay casos en los que la IA gratuita se queda corta:

• Apps con sistemas de diseño complejos (design system corporativo extenso, múltiples temas, necesidades de accesibilidad avanzadas)
• Productos con muchos tipos de usuario y flujos interconectados (marketplaces con 3+ roles, por ejemplo)
• Conexiones estables entre muchos usuarios con roles diferentes dentro de la plataforma — plataformas donde creadores, consumidores, moderadores y administradores interactúan en tiempo real requieren diseño de estados, permisos y sincronización que va mucho más allá de lo que un prototipo estático puede validar
• Validación real con usuarios antes de construir — user testing, entrevistas, quant research
• Integración real con backend y lógica de negocio más allá del prototipo visual

Para estos casos, una agencia creativa especializada en AI-first puede acelerar la producción sin perder control. Si estás en ese punto, puedes contactarnos.

Próximo paso: del diseño al código

Ya tienes el prototipo validado en Stitch. El siguiente artículo de esta serie cubre cómo pasar del diseño al código real usando vibe coding con IA: export a Firebase Studio, uso de los snippets HTML/CSS/Flutter que genera Stitch, y conexión con Claude Code o Cursor para llevar el prototipo a un MVP funcional.

Recomendación final

No uses Stitch como si fuera una máquina de pantallas bonitas. Úsalo como el último paso de un proceso que empieza en research y pasa por Jobs-to-be-Done, MoSCoW y brief visual.

La razón por la que el 71% de apps pierde a sus usuarios en 90 días (Rentamac, 2025) no es falta de diseño visual — es falta de claridad sobre qué problema resuelven y para quién. La IA te da ese diseño en minutos. El trabajo difícil sigue siendo el mismo de siempre: entender al usuario antes de construir.

Con este workflow tienes las dos partes cubiertas: la estructura mental para llegar a un producto con sentido, y la herramienta para materializarlo sin inversión inicial.