Describir tu app (mini-PRD)

Por qué describir antes de generar

La tentación es grande de abrir la herramienta y teclear «hazme una app de seguimiento de hábitos». Pruébalo, y verás el problema: la IA va a llenar todos los vacíos con sus propias decisiones. Decidirá los colores, las funcionalidades, la estructura — y hay pocas probabilidades de que sus decisiones correspondan a lo que tenías en mente. Luego pasarás diez mensajes deshaciendo lo que habrías podido evitar con dos minutos de reflexión.

Ese es todo el interés del mini-PRD. PRD significa «Product Requirements Document», el pliego de requisitos que escriben los equipos de producto profesionales. La versión «mini» cabe en una decena de líneas y responde a cinco preguntas: para qué sirve la app, quién la usa, qué hace exactamente, qué aspecto tiene, y sobre qué base técnica. Con eso, la IA produce a la primera algo cercano a tu visión.

Hay un beneficio oculto: escribir el mini-PRD te obliga a clarificar tu propio pensamiento. Muchas ideas de apps parecen límpidas en la cabeza y se revelan difusas sobre el papel. «Una app para ayudar a los alumnos» — vale, pero ¿a hacer qué, concretamente? El mini-PRD es tu primera herramienta de jefe de proyecto, incluso antes del primer prompt.

El mini-PRD en cinco bloques

• Objetivo: una frase. «Una app web para seguir los hábitos de trabajo diarios.»
• Usuarios: quién la usa y en qué contexto. «Alumnos de secundaria, en su teléfono, por la noche.»
• Funcionalidades: de 3 a 5 acciones concretas, numeradas. No más para una v1.
• Estilo: 3-4 adjetivos y una restricción. «Depurado, mobile-first, acento verde, botones grandes.»
• Técnica: mantente simple. «HTML/CSS/JS simple, almacenamiento local, sin cuenta de usuario.»

El orden tiene su importancia: se parte de la intención (el objetivo) para terminar en la implementación (la técnica). Si no sabes qué poner en el bloque técnico, escribe simplemente «lo más simple posible, sin base de datos ni cuenta de usuario» — la IA lo entenderá y elegirá por ti una base sana.

El mini-PRD de Tom, completo

Quiero construir una app web: un seguimiento de hábitos.
Usuarios: alumnos de secundaria que quieren mantener rutinas de trabajo, sobre todo en el teléfono.
Funciones:
1. añadir / eliminar un hábito
2. marcar cada día si el hábito está hecho
3. ver una racha (streak) de días consecutivos logrados
4. ver un mini calendario del mes con los días marcados
Estilo: depurado, mobile-first, acento verde, botones grandes fáciles de tocar.
Técnica: HTML/CSS/JS simple, almacenamiento local (localStorage), sin cuenta de usuario.
Construye primero ÚNICAMENTE las funciones 1 y 2. Añadiremos el resto después de mis pruebas.

Observa la última línea: Tom da la visión completa, pero pide explícitamente construir solo las funciones 1 y 2. Es la combinación ganadora — la IA conoce el destino (tomará decisiones coherentes con lo que viene), pero el primer entregable sigue siendo pequeño y comprobable. Validas la base, y luego pides «añade ahora la función 3» en un mensaje siguiente.

Las palabras que lo cambian todo

Algunos términos de tu mini-PRD tienen un efecto desmesurado sobre el resultado. «Mobile-first» le dice a la IA que diseñe primero para una pantalla pequeña — crucial si tus usuarios están en el teléfono. «Almacenamiento local» evita toda la complejidad de cuentas y servidores. «Depurado» orienta hacia un diseño sobrio en lugar de recargado. Estas palabras clave son atajos hacia decisiones técnicas enteras.

A la inversa, algunas palabras desencadenan una complejidad que no sospechas. «Cuenta de usuario» implica registro, inicio de sesión, contraseñas, recuperación — horas de trabajo. «Notificaciones» implica permisos y servicios externos. «Tiempo real» (ver los cambios de otros al instante) implica un servidor permanente. Si una de estas palabras se cuela en tu v1, pregúntate seriamente si puede esperar a la v2.

Describir el estilo sin ser diseñador

No necesitas vocabulario de diseñador para obtener una app bonita. Tres técnicas simples: da adjetivos (depurado, cálido, profesional, lúdico), cita una referencia conocida («en el espíritu de la app Notas de Apple», «sobrio como un sitio de prensa»), y precisa un color de acento («acento verde», «tonos azul noche»). La IA traducirá esas indicaciones en decisiones tipográficas y visuales coherentes.

Si el primer resultado no te gusta, afina por comparación en lugar de por jerga: «más aireado», «los botones son demasiado pequeños para un pulgar», «demasiados colores, conserva solo el verde y el gris». Son comentarios que cualquiera puede formular, y la IA los entiende perfectamente.

Priorizar: ¿v1 o más tarde?

Distingue lo «indispensable v1» de lo «estaría bien más tarde». La prueba es simple: sin esta función, ¿la app sigue siendo útil? Si sí, es «más tarde». Tom aplica la prueba: sin la adición de hábitos, la app está vacía — v1. Sin el marcado diario, no sirve para nada — v1. Sin las notificaciones, funciona muy bien — más tarde. Sin el compartir entre alumnos, también — más tarde.

flowchart TD
  I["Idea de funcionalidad"] --> Q["Sin ella, ¿la app es útil?"]
  Q -->|"No, queda inutilizable"| V1["Indispensable v1"]
  Q -->|"Sí, funciona igualmente"| V2["Lista «más tarde»"]
  V1 --> P["En el mini-PRD"]
  V2 --> L["Anotada para la v2"]

Guarda tu lista «más tarde» bien resguardada en un archivo o una nota: no es una papelera, es tu hoja de ruta. En el capítulo 5, una vez la app desplegada, es de esa lista de donde sacarás tus próximas mejoras — guiado por los comentarios de tus primeros usuarios.

Mini glosario del capítulo

• PRD: Product Requirements Document, el pliego de requisitos de un producto.
• localStorage: un pequeño espacio de almacenamiento en el navegador, donde una app puede guardar datos sin servidor.
• Mobile-first: diseñar primero para el teléfono, y luego adaptar a las pantallas grandes.
• v1 / v2: primera versión usable / siguiente versión mejorada.
• Streak: racha de días consecutivos de éxito (término corriente en las apps de hábitos).