Para quién es este tutorial: Estudiantes que han completado su Press Release y Mapa de Empatía y quieren convertirlos en un prototipo funcional sin escribir código. El objetivo es que asuman el rol de Product Owner (PO) estratégico: toman decisiones de producto basadas en el usuario, y usan la IA como ejecutora de esas decisiones.
Antes de abrir cualquier herramienta, asegúrese de tener listos:
| Documento | ¿Qué contiene? | ¿Para qué se usa en el prototipo? |
|---|---|---|
| Press Release completo | Titular, subtítulo, problema, solución, cita del líder | Define el tono, el valor central y el flujo de navegación principal |
| Mapa de Empatía Móvil | Dolores, ganancias, contextos del usuario | Determina qué pantallas NO incluir y cuáles son críticas |
| FAQs internas y externas | Riesgos, diferenciales, métricas de éxito | Filtra funcionalidades del prototipo y define los criterios de QA |
Regla de oro: Si no puede encontrar en cuál de estos tres documentos se justifica una pantalla o funcionalidad, esa pantalla no debe estar en el PoC.
Party Rock (partyrock.aws) es la herramienta gratuita de AWS para crear experiencias de IA sin código. Para este paso, la usarán como generador de arquitectura de información.
Instrucciones paso a paso:
PROMPT TEMPLATE PARA PARTY ROCK – GENERACIÓN DE FLUJO:
Actúa como un experto en UX/UI para aplicaciones móviles. Tengo el
siguiente Press Release para una app:
[PEGAR EL PRESS RELEASE COMPLETO AQUÍ]
Con base en este Press Release, genera:
1. Una lista de MÁXIMO 6 pantallas que necesita esta app para resolver
el JTBD principal (el trabajo del usuario descrito en el titular)
2. Para cada pantalla: nombre, propósito en 1 línea, y los 3 elementos
de UI más importantes que debe contener
3. El flujo de navegación entre las pantallas en formato:
[Pantalla A] → [Acción del usuario] → [Pantalla B]
4. Una pantalla que NO debe existir en la versión inicial y por qué
Responde en español. Sé específico y evita funcionalidades genéricas.
Cada pantalla debe rastreable a un dolor del usuario o una ganancia
identificada en el mapa de empatía.Party Rock generará el flujo. Evalúe críticamente la respuesta con esta lista:
Una vez tenga el flujo inicial de Party Rock, agréguele las restricciones del Mapa de Empatía:
PROMPT DE REFINAMIENTO:
Ahora quiero refinar las pantallas considerando las siguientes barreras
del usuario que identifiqué en el Mapa de Empatía Móvil:
DOLORES IDENTIFICADOS:
- [Dolor 1: ej. "El usuario abandona si hay más de 3 campos en un formulario"]
- [Dolor 2: ej. "El usuario desconfía si no ve confirmación en tiempo real"]
- [Dolor 3: ej. "El usuario opera con batería baja y mal internet frecuentemente"]
CONTEXTOS DE USO CRÍTICOS:
- [Contexto 1: ej. "Usa la app en transporte público con una sola mano"]
- [Contexto 2: ej. "Primer uso: nunca ha facturado electrónicamente"]
Con base en esto, modifica el flujo anterior para:
1. Eliminar cualquier paso que genere fricción según los dolores identificados
2. Añadir micro-interacciones que generen confianza en los momentos de duda
3. Garantizar que el flujo funcione en condiciones de batería baja y mala conexiónLovable (lovable.dev) es una herramienta de IA generativa que convierte descripciones en texto en interfaces visuales funcionales y navegables.
El prompt para Lovable debe ser más específico que el de Party Rock. Lovable necesita instrucciones de diseño visual, no solo de contenido.
PROMPT MAESTRO LOVABLE – TEMPLATE:
Crea una aplicación móvil con las siguientes especificaciones:
NOMBRE DE LA APP: [Nombre]
DESCRIPCIÓN EN 1 LÍNEA: [Copiar el subtítulo del Press Release]
USUARIO OBJETIVO: [Descripción del usuario del Mapa de Empatía]
JTBD PRINCIPAL: [El trabajo que resuelve la app]
PANTALLAS REQUERIDAS (en orden de flujo):
PANTALLA 1 – [Nombre]:
- Propósito: [1 línea]
- Elementos: [CTA principal], [elemento 2], [elemento 3]
- Restricción de diseño: [ej. "máximo 2 acciones posibles para el usuario"]
PANTALLA 2 – [Nombre]:
- Propósito: [1 línea]
- Elementos: [lista de máximo 4 elementos]
- Restricción: [ej. "sin scroll, todo visible en una pantalla de 6 pulgadas"]
[Repetir para cada pantalla – máximo 5 pantallas]
ESTILO VISUAL:
- Paleta de colores: [sus colores de marca o preferencia]
- Tono: [profesional/amigable/minimalista/etc.]
- Tipografía: [Sans-serif moderna, legible en pantallas pequeñas]
RESTRICCIONES OBLIGATORIAS:
- Sin menús de hamburguesa (navegación en bottom bar)
- Botón de acción principal siempre visible (no requiere scroll)
- Formularios de máximo 4 campos por pantalla
- Mensajes de confirmación siempre en verde con ícono de checkLovable genera la primera versión en 2-3 minutos. Seguir este proceso de iteración:
| Iteración | Qué revisar | Prompt de corrección |
|---|---|---|
| Versión 1 | ¿El flujo principal resuelve el JTBD de principio a fin? | “Ajusta [pantalla X] para que el usuario pueda [acción] sin necesidad de [fricción identificada]” |
| Versión 2 | ¿Las barreras del Mapa de Empatía están eliminadas? | “En [pantalla Y], añade [elemento de confianza] porque el usuario tiene miedo de [dolor Z]” |
| Versión 3 | ¿El flujo completo funciona en el tiempo del PR? | “Reduce el flujo de [pantalla A] a [pantalla B] a máximo 2 pasos” |
Una vez satisfecho con el resultado en Lovable: 1. Hacer screenshot de cada pantalla generada 2. Importar imágenes a Figma como frames de referencia 3. Usar Figma para agregar interactividad (flechas de navegación entre pantallas)
Para cada pantalla del prototipo, haga la siguiente pregunta:
“¿Qué FAQ (interna o externa) justifica la existencia de esta pantalla?”
| Pantalla del PoC | FAQ que la justifica | ¿Pasa el filtro? |
|---|---|---|
| Home con saldo visible | FAQ externa: “¿Cuánto tengo disponible ahora mismo?” | ✅ SÍ |
| Tutorial en video de 3 min | FAQ externa: “¿Cómo funciona?” | ⚠️ Solo si el video es < 60s |
| Pantalla de configuración de notificaciones | No hay FAQ que la justifique en V1 | ❌ Eliminar del PoC inicial |
| Confirmación con tiempo real del proceso | FAQ externa: “¿Cómo sé que funcionó?” | ✅ SÍ |
Antes de presentar el PoC, responda estas tres preguntas. Si alguna es NO, hay trabajo pendiente:
¿Puede un usuario que nunca ha visto la app completar el flujo principal sin ayuda externa en menos de [tiempo del PR]? → Hacer una prueba de 5 minutos con alguien fuera del equipo.
¿Cada pantalla del prototipo puede rastrearse hasta un JTBD, un dolor del Mapa de Empatía o una FAQ? → Si hay pantallas huérfanas, eliminarlas.
¿El prototipo promete exactamente lo que el Press Release anuncia? → El titular del PR debe poder leerse en la pantalla de onboarding o confirmación final.
PRESS RELEASE PARTY ROCK LOVABLE FIGMA
+ FAQs → (Flujo lógico) → (Pantallas visuales) → (PoC navegable)
+ MAPA EMPATÍA
[Estrategia] [Arquitectura] [Diseño] [Validación]
30 min 20 min 45 min 30 min
FILTROS DE QA EN CADA ETAPA:
← ¿Justificado por el PR? ← ¿Elimina barreras? ← ¿Responde FAQs?Tiempo total estimado para el PoC inicial: 2-3 horas por equipo
| Herramienta | URL | Costo | Para qué usarla |
|---|---|---|---|
| Party Rock AWS | partyrock.aws | Gratuito | Generar flujos de navegación y estructura |
| Lovable | lovable.dev | Gratuito (tier básico) | Generar pantallas visuales automáticamente |
| Figma | figma.com | Gratuito (educativo) | Conectar pantallas y hacer prototipo navegable |
| Miro | miro.com | Gratuito | Mapa de Empatía colaborativo en clase |
Templates disponibles en Brightspace: - Template Miro: Mapa de Empatía Móvil (Sesión 3) - Template Figma: Frame 390×844 con grid para mobile - Template Google Docs: Press Release con instrucciones de cada sección
Especialización en Inteligencia de Mercados – Universidad de los Andes | Prof. Juan Pablo Gómez Bravo | 2026