Plantilla de especificación de una página para apps coherentes creadas por IA

Por qué importa el Modo de planificación cuando tu idea aún es vaga

Una idea vaga está bien para soñar. Es pobre para construir.

Cuando le pides a un creador de IA “una app para seguir hábitos” sin más detalles, tiene que adivinar qué quieres decir. Esas suposiciones cambian de prompt en prompt, así que la app también cambia. Terminas con pantallas que no coinciden, datos que se renombran a mitad del desarrollo y funciones que aparecen, desaparecen y luego reaparecen en otra forma.

Esa inconsistencia suele aparecer en unos pocos puntos:

• Suposiciones diferentes sobre quién es el usuario (usuario individual vs equipo)
• Flujos en conflicto (registrar primero, luego crear vs crear primero, luego registrar)
• Nombres de datos cambiantes (habit vs routine vs goal)
• Casos límite faltantes (qué pasa si un usuario borra algo)

“El Modo de planificación” es una pausa simple antes de construir. Escribes las decisiones que la IA inventaría de otro modo. El objetivo es coherencia: un conjunto de elecciones que la UI, el backend y la base de datos puedan seguir.

La meta no es la perfección. Es construir algo que puedas iterar sin parchar constantemente una pila de suposiciones. Si luego cambias de idea, actualizas una pequeña especificación y reconstruyes con la misma lógica.

Por eso importa una plantilla de especificación de una página. No es un PRD largo ni semanas de diagramas. Es una página que responde cuatro cosas: quiénes son los usuarios, qué intentan lograr, qué datos existen (en lenguaje claro) y qué casos límite o no-objetivos evitan que la primera versión explote.

Ejemplo: “Una app de reservas” queda mucho más clara cuando decides si es para un único dueño de salón o un marketplace, y si los clientes pueden reprogramar, cancelar o no presentarse.

La plantilla de una página, explicada en un minuto

Una plantilla de especificación de una página es una nota corta que convierte una idea vaga en instrucciones claras. No estás “diseñando todo el producto.” Estás dando a tu creador de IA suficiente estructura para tomar las mismas decisiones cada vez.

La página tiene cuatro bloques. Si no cabe en una página, probablemente tienes demasiadas funciones para un primer build.

• Usuarios: quién la usa (2–3 tipos) y qué los diferencia.
• Jobs-to-be-done: qué intenta lograr cada usuario, escrito como resultados.
• Entidades: las cosas clave que guardas y haces seguimiento (los sustantivos de datos).
• Casos límite + no-objetivos: qué puede salir mal y qué no vas a construir aún.

Una página fuerza restricciones útiles. Te empuja a elegir un usuario principal, definir el flujo mínimo exitoso y evitar promesas vagas como “soportar todo.” Esas restricciones son exactamente lo que impide que una app creada por IA cambie de idea entre pantallas.

El detalle “suficientemente bueno” se ve como afirmaciones simples y comprobables. Si alguien puede leerlo y preguntar “¿Cómo sabemos que esto funciona?” estás en el nivel correcto.

Un objetivo rápido:

• Un usuario nuevo puede completar la tarea principal en menos de 2 minutos.
• Cada job tiene un inicio y un fin claros (nada de “gestionar cosas” sin cierre).
• Cada entidad tiene 3–7 campos que necesitas ahora.
• Se nombran los 5 casos límite principales (duplicados, permisos, estados vacíos, fallos, entradas inválidas).

Usa un lenguaje sencillo. Escribe líneas que puedas pegar directamente en prompts, como “Un gestor puede aprobar o rechazar una solicitud, y el solicitante recibe una actualización de estado.”

Paso a paso: rellena la plantilla en 20 minutos

Pon un temporizador de 20 minutos y apunta a “lo bastante claro para construir”, no a “perfecto”. La idea es eliminar las conjeturas para que tu creador de IA haga las mismas elecciones cada vez.

Empieza con una sola frase que responda: ¿para quién es y qué resultado obtiene?

Ejemplo: “Una app móvil para dueños de perros para registrar paseos y visitas al veterinario en un solo lugar.”

Si no lo puedes decir en una frase, probablemente la idea son dos apps.

Luego nombra de 1 a 3 tipos de usuario como personas reales, no roles abstractos. “Dueño”, “Veterinario” y “Familiar” es mejor que “Usuario A”. Para cada uno, añade una línea corta sobre qué les importa más.

Después escribe 3 a 7 jobs-to-be-done en el formato: “Cuando [situación], quiero [acción], para [resultado].” Mantenlos comprobables. “Cuando termino un paseo, quiero registrar distancia y notas, para detectar patrones” es más claro que “seguir la salud”.

Ahora define tus entidades y campos clave sin hablar de bases de datos. Piensa en “cosas que la app recuerda”. Para la app de perros: Dog (nombre, edad), Walk (fecha, duración, notas), Visit (fecha, clínica, costo). Si un campo no se usa en una pantalla o job, déjalo fuera.

Termina con dos bloques cortos: casos límite y no-objetivos. Los casos límite son molestos pero comunes (“sin internet”, “dos perros con el mismo nombre”). Los no-objetivos son cosas que no vas a construir aún (“sin pagos”, “sin feed social”).

Finalmente, convierte cada bloque en prompts que tu creador pueda seguir. Mantener la estructura consistente (propósito, usuarios, jobs, entidades, casos límite) ayuda al sistema a generar pantallas, datos y flujos que coincidan.

Usuarios y jobs que una IA puede seguir

Si tu especificación dice “para todos”, un creador de IA tiene que adivinar qué construir primero. En una plantilla de una página, define usuarios por intención (qué vinieron a hacer), no por demografía. La intención conduce a decisiones claras sobre pantallas, datos y permisos.

Nombra 2–4 tipos de usuario, cada uno con un único objetivo principal. Buenos ejemplos: “Cliente que hace un pedido”, “Miembro del equipo que cumple pedidos” y “Gestor que revisa rendimiento.” Ejemplos vagos: “18–35”, “profesionales ocupados” o “admins” (a menos que digas qué administran).

Escribe JTBD en un formato estricto

Usa la misma estructura de frase siempre: “Cuando..., quiero..., para...”. Esto mantiene la app enfocada en resultados y da requisitos estables y comprobables al creador de IA.

Aquí tienes ejemplos realistas de JTBD con “hecho” claramente definido:

• Cuando termino una llamada con un cliente, quiero registrar los siguientes pasos en un solo lugar, para poder hacer seguimiento a tiempo. Hecho significa: nota guardada, fecha de vencimiento establecida, recordatorio programado.
• Cuando llega una nueva solicitud, quiero aprobarla o rechazarla rápido, para mantener el trabajo en movimiento. Hecho significa: decisión registrada, solicitante notificado, estado actualizado.
• Cuando estoy en móvil, quiero ver solo las tareas de hoy, para actuar sin buscar. Hecho significa: tareas filtradas al día, marcar como completada con un toque.
• Cuando cometo un error, quiero deshacer el último cambio, para recuperar sin soporte. Hecho significa: estado previo restaurado, nota de auditoría creada.

Los criterios de éxito importan porque eliminan la ambigüedad de “que se vea bien”. Le dicen al builder qué debe permitir la UI y qué debe guardar el backend.

Añade permisos a alto nivel

No escribas un plan de seguridad completo. Solo indica quién puede hacer qué, en lenguaje claro.

Ejemplo: “Los miembros pueden crear y editar sus propios items. Los gestores pueden editar cualquier item y cambiar estado. Los propietarios pueden gestionar usuarios y facturación.”

Si usas un paso de planificación en una herramienta como Koder.ai, estos tipos de usuario, líneas JTBD y permisos se convierten en entradas fiables. También evitan que la IA invente roles adicionales o mezcle responsabilidades entre pantallas.

Entidades: define los datos sin tecnicismos

Las entidades son las “cosas” que tu app registra. Si las nombras con claridad, tu creador de IA podrá crear pantallas, formularios y una base de datos coherentes. Esto evita campos desajustados y funciones extra aleatorias.

Empieza listando tus sustantivos principales. Si la app es para “gestionar proyectos”, tus sustantivos podrían ser Project, Task y Comment. Si es “reservar peluquerías”, podrías tener Booking, Service, Customer y Staff.

Elige 5 a 10 campos que la gente realmente menciona

Para cada entidad, escribe campos en palabras cotidianas, no términos de base de datos. Imagina lo que una persona escribiría en un formulario.

• Task: título, descripción, estado, fecha de vencimiento, prioridad, asignado a, creado por
• Project: nombre, objetivo, fecha de inicio, fecha de fin, propietario, archivado (sí/no)
• Invoice: número de factura, nombre del cliente, importe, moneda, fecha de vencimiento, pagado (sí/no)

Si no puedes explicar un campo en una frase, probablemente es demasiado detallado para la primera versión.

Relaciones y reglas en lenguaje sencillo

Describe cómo se conectan las entidades con frases simples:

“Un usuario puede tener muchos proyectos.” “Cada tarea pertenece a un proyecto.” “Un comentario pertenece a una tarea y tiene un autor.”

Esto da al builder suficiente estructura para generar listas consistentes, páginas de detalle y filtros.

Añade algunas reglas de datos que eviten comportamientos caóticos:

• Requerido: “Título de tarea es obligatorio.”
• Único: “Número de factura debe ser único.”
• Límites: “Descripción máx. 500 caracteres.”
• Predeterminados: “Las nuevas tareas inician con estado = Abierto.”

Finalmente, reduce el alcance nombrando lo que no vas a almacenar aún. Ejemplo: “Sin adjuntos en v1” o “No gestionar horarios del personal aún, solo reservas.” Esas exclusiones importan porque evitan que la app crezca en la dirección equivocada.

Pantallas y flujos: mantenlos simples y predecibles

Una plantilla de una página funciona mejor cuando la primera versión tiene un conjunto pequeño y estable de pantallas. Si intentas diseñar cada pantalla que la app podría necesitar algún día, tu creador de IA seguirá adivinando y la UI se desviará entre builds.

Empieza nombrando las pantallas mínimas que permiten completar la tarea principal. Para la mayoría de los MVPs, 3 a 6 pantallas son suficientes:

• Iniciar sesión
• Lista (tus items principales)
• Detalle (ver un item)
• Crear/Editar (un formulario)
• Ajustes (opcional)

Luego escribe el camino feliz como una breve historia de principio a fin.

Ejemplo: “El usuario inicia sesión, aterriza en la lista, busca, abre un item, edita un campo, guarda y vuelve a la lista.”

Para cada pantalla, anota las acciones clave en palabras simples. Evita pantallas “hacer de todo”. Elige las 2 a 4 acciones que más importan, como crear, editar, buscar, exportar o archivar.

Decide también qué debe ser rápido y qué puede ser aceptable. “Rápido” suele ser que la lista abra pronto, la búsqueda responda rápido y guardar se sienta instantáneo. “Aceptable” puede ser que la exportación tarde unos segundos, analíticas básicas o ajustes escasos.

Finalmente, captura roles y accesos en una línea por rol:

• Viewer: puede ver y buscar
• Editor: puede crear y editar
• Admin (solo si hace falta): puede gestionar usuarios y eliminar

Esto mantiene las pantallas previsibles, evita sorpresas de permisos y reduce reescrituras más adelante.

Casos límite y no-objetivos que evitan reescrituras

La mayoría de las reescrituras ocurren por una razón: la app funciona bien en el camino feliz y luego se rompe cuando la vida real aparece.

Una buena plantilla de una página deja espacio para casos límite y no-objetivos, y ese pequeño espacio ahorra horas.

Empieza con cada job-to-be-done y pregunta: ¿qué podría salir mal? Manténlo en lenguaje claro, no técnico. Estás eliminando ambigüedad para que el builder tome la misma decisión cada vez.

Casos límite comunes que vale la pena anotar:

• Información faltante o incompleta (campos vacíos, dirección desconocida, sin foto de perfil)
• Duplicados (mismo usuario se registra dos veces, mismo item agregado dos veces)
• Conflictos (dos personas editan el mismo registro, estado cambia mientras se visualiza)
• Límites y timeouts (conexión lenta, subida falla, petición tarda demasiado)
• Problemas de permisos (usuario intenta ver o editar algo que no debe)

Luego decide la respuesta. Sé específico: “Bloquear la acción y mostrar un mensaje claro”, “Permitir guardar como borrador”, o “Reintentar una vez y luego mostrar un botón para intentar de nuevo.” Estas reglas se traducen directamente en prompts coherentes.

Añade expectativas de privacidad y seguridad en una o dos líneas. Por ejemplo: “Recopilar los datos mínimos necesarios”, “Los usuarios pueden borrar su cuenta y todos sus datos personales” y “Ocultar items privados por defecto.” Si tu app incluye contenido generado por usuarios, anota qué hacer con reportes y spam, aunque sea algo simple en v1.

Finalmente, escribe no-objetivos para frenar el crecimiento del alcance.

Ejemplos claros de no-objetivos:

• Sin pagos o suscripciones en v1
• Sin inicio de sesión social (solo email por ahora)
• Sin panel de administrador más allá de lista básica y eliminar
• Sin modo offline

Un ejemplo rápido: si el job es “Crear un evento”, define qué pasa cuando la fecha es pasada, el título está en blanco o el mismo evento se crea dos veces. Esa claridad evita la siguiente reescritura.

Convierte la especificación de una página en prompts que tu creador de IA pueda ejecutar

La forma más rápida de obtener resultados coherentes es convertir cada bloque de tu plantilla en un prompt pequeño y directo. Piensa en ello como dar al builder un conjunto de cartas que puede seguir en orden, en lugar de una petición grande y difusa.

Convierte cada bloque (Usuarios, Jobs, Entidades, Pantallas, Casos límite, No-objetivos) en una instrucción con sustantivos y verbos claros. Evita opiniones como “hazlo limpio” a menos que también digas qué significa “limpio”.

Un patrón de prompt simple que funciona

Usa un ciclo de dos pasos: construir primero y luego validar contra la spec.

1. Construir: “Crea el modelo de datos y la API para estas Entidades: [pegar Entidades]. Soporta estos roles: [pegar Usuarios].”
2. Construir: “Crea pantallas y flujos exactamente para: [pegar Pantallas/Flujos].”
3. Validar: “Ahora comprueba tu trabajo contra esta especificación. Lista cualquier discrepancia y arréglala: [pegar spec completa].”

Añade una breve definición de hecho para que el builder sepa cuándo detenerse. Mantenla medible:

• Todos los roles listados pueden completar cada job-to-be-done de extremo a extremo
• Cada entidad tiene crear, ver, editar y archivar (si la spec lo indica)
• Las pantallas coinciden con los flujos nombrados, con etiquetas de campo consistentes
• Los casos límite se manejan con mensajes claros (sin fallos silenciosos)

Solo añade restricciones cuando realmente importen: dispositivos requeridos (mobile-first), autenticación requerida (acciones solo admin) o stack requerido (por ejemplo frontend React, backend Go, PostgreSQL) si tu plataforma lo espera.

Solicita cambios sin romper el plan

Cuando quieras editar, referencia el bloque de la spec, no el código.

Ejemplo: “Actualiza el bloque Entidades: añade ‘Subscription’ con campos X e Y. Luego regenera solo las APIs y pantallas afectadas y vuelve a ejecutar la validación.”

Ese enfoque mantiene el plan estable y te permite iterar con seguridad.

Un ejemplo realista: de idea a prompts de Modo de planificación

Imagina que quieres un rastreador de recordatorios de citas para un salón pequeño. La meta no es un sistema completo de reservas. Es un lugar ligero para almacenar citas y enviar recordatorios.

Así queda una plantilla de especificación de una página cuando está rellenada.

APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.

USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.

JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.

ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.

EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments

Ahora conviértelo en un paquete de prompts que puedas pegar en el Modo de planificación para construir la app. Mantenlo estricto para que el builder tome las mismas decisiones cada vez.

PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.

Trampas comunes que hacen inconsistentes las apps creadas por IA

La salida desordenada suele empezar con una spec vaga y listas de deseos. Un creador de IA hará lo que pidas, pero no puede leer tu mente. Pequeños huecos se convierten en grandes diferencias entre pantallas y flujos.

Estas trampas rompen la coherencia con más frecuencia, y la plantilla de una página las arregla:

• Funciones en lugar de jobs: “Añadir favoritos” es una función. Un job es “guardar items para revisar después.” Los jobs incluyen intención y éxito, así la IA puede tomar decisiones sensatas (dónde va el botón, qué pasa después de guardar, qué dicen los estados vacíos).
• Demasiadas entidades demasiado pronto: Si defines 12 tablas el primer día, la lógica se dispersa. Empieza con el modelo más pequeño que pueda enviarse. Si “Project”, “Task”, “Comment”, “Tag” y “Attachment” se sienten grandes, comienza solo con “Project” y “Task”.
• Permisos faltantes: Si no dices quién puede editar o borrar, el builder adivinará. Escribe reglas simples como “Solo el propietario puede borrar”, “Los miembros pueden crear y editar” y “Los viewers solo pueden leer.” Esto reduce la exposición accidental de datos.
• Sin criterios claros de éxito: Sin definición de hecho, recibes iteraciones infinitas. Añade 2–4 checks de aceptación, como “El usuario puede crear una tarea en menos de 30 segundos” o “Las tareas se muestran correctamente tras refrescar.”
• Casos límite sin comportamiento esperado: Listar “offline”, “emails duplicados” o “lista vacía” no basta. Para cada uno, indica qué debe hacer la app. Ejemplo: “Si el email ya existe, mostrar un error amigable y sugerir iniciar sesión.”

Si usas el Modo de planificación en Koder.ai, estos básicos importan aún más porque el plan se convierte en la fuente para prompts repetidos. Jobs claros, un modelo de datos pequeño, permisos explícitos y reglas de aceptación mantenienen cada nueva pantalla alineada con el resto.

Lista rápida de comprobación y siguientes pasos

Antes de construir, haz una pasada rápida sobre tu plantilla de una página. La meta es tapar los huecos que obligan a la IA a adivinar. Esas conjeturas se convierten en reescrituras.

Chequeo rápido de completitud:

• Usuarios: cada tipo tiene un objetivo claro y una nota de “quién puede hacer qué” (crear, ver, editar, borrar).
• Jobs-to-be-done: cada job empieza con un disparador y termina con un resultado verificable.
• Entidades: cada sustantivo en los jobs tiene un ítem de datos (aunque sea solo nombre, estado y timestamps).
• Pantallas y flujos: cada job se mapea a un camino simple (pantalla de inicio, acción clave, confirmación).
• Casos límite: anotaste al menos 5 cosas que pueden fallar (estado vacío, entrada inválida, duplicados, permisos, offline o red lenta).

Si quieres una idea de puntuación simple, valora cada área de 0 a 2:

• 0: falta o es vago
• 1: presente pero poco claro
• 2: suficientemente claro para construir

Apunta a al menos 7 de 10 antes de generar nada. Si Entidades o Casos límite están por debajo de 2, arréglalos primero. Son los que más churn causan.

Tras el primer build, revisa la app contra cada job-to-be-done y marca las discrepancias. Haz un snapshot antes de cada cambio. Si una nueva iteración empeora las cosas, revierte y prueba una edición más pequeña.

Si usas Koder.ai (koder.ai), el Modo de planificación es un lugar práctico para mantener esta especificación de una página como “fuente de la verdad” y regenerar solo lo que cambió en lugar de reescribir todo manualmente.

Mantén la spec actualizada sobre la marcha. Cuando aceptes un cambio en la app, actualiza la spec el mismo día. Cuando rechaces un cambio, escribe por qué, para que el siguiente prompt siga siendo coherente.