Especificación de producto de una página para desarrollos con IA: pantallas, campos, reglas

Por qué los builds con IA se desvían sin una especificación clara

Cuando le das a un constructor de IA un prompt vago, tiene que adivinar. Completa los detalles faltantes con patrones que ha visto antes, no con lo que tú querías decir. Por eso las apps construidas por IA pueden sentirse aleatorias incluso cuando la primera demo se ve bien.

Esa sensación de “azar” suele aparecer en formas pequeñas pero dolorosas: falta un campo que dabas por obvio en una pantalla, un formulario acepta valores que debería bloquear, o un botón va al lugar equivocado porque la herramienta imaginó un flujo distinto.

La inconsistencia es otro síntoma común. Una pantalla lo llama “Company”, otra “Organization”. Los admins pueden editar algo en un sitio pero no en otro. La base de datos acaba con columnas extra, columnas faltantes o tipos equivocados porque la UI y el modelo de datos se inventaron por separado.

Una especificación de producto de una página reduce esa adivinanza. Le da a la herramienta un conjunto cerrado de decisiones que no tiene que tomar, así obtienes menos reconstrucciones y menos ida y vuelta. Cuando algo está mal, puedes señalar una sola frase y arreglarlo en vez de discutir qué “realmente” quiso decir el prompt.

Sin una especificación clara, verás a menudo:

• Pantallas extra que no pediste, mientras que las clave se omiten
• Campos requeridos convertidos en opcionales (o al revés)
• Permisos inconsistentes (quién puede ver, crear, editar, eliminar)
• Reglas de validación faltantes, por lo que entran datos malos
• Múltiples versiones del mismo flujo (dos maneras de hacer una tarea)

Este enfoque encaja con fundadores, PMs, diseñadores y agencias que usan herramientas como Lovable, Bolt, v0, Cursor o Replit y quieren builds que se comporten de forma predecible. También ayuda si heredaste código generado por IA y quieres que la siguiente iteración sea menos caótica y más fácil de reparar.

Qué significa “especificación de una página” en la práctica

Una especificación de producto de una página es una nota corta y estructurada que elimina la adivinanza antes de pedir a una herramienta de IA que construya. No intenta capturar toda tu visión. Captura las decisiones que los constructores tienden a “rellenar”, que es donde nacen las funciones aleatorias y la lógica rota.

Piensa en ello como un contrato: estas son las pantallas, estos son los campos y estas son las reglas. Si un detalle cambia cómo se comporta la app, pertenece a la página. Si es solo copy o estilo, por lo general no.

Una especificación de una página práctica incluye:

• Una lista de pantallas con una frase por pantalla (qué puede hacer el usuario allí)
• Los campos de datos que deben existir (nombre, tipo, requerido/opcional)
• Las reglas que gobiernan el comportamiento (validación, permisos, cambios de estado)
• Unas pocas restricciones que eviten valores por defecto malos (método de auth, roles, límites básicos de seguridad)

No incluye un diseño UI completo, historias de usuario largas ni páginas de casos límite. Puedes añadir mockups después, pero la especificación debe tener sentido por sí sola.

Para mantenerla corta sin ser vaga, escribe en declaraciones con “debe” y “si/entonces”. “Solo los admins pueden eliminar un proyecto” vence a “Los admins gestionan proyectos.” “El correo es obligatorio y debe ser único” vence a “Los usuarios se registran con email.”

Una comprobación rápida: si le dieras esta página a otra persona, ¿podrían construir el comportamiento que esperas sin preguntar 20 cosas? Si no, la página necesita reglas más claras o campos faltantes.

Paso a paso: convierte una idea en una especificación de una página

Una buena especificación de una página no es una novela. Es un conjunto de instrucciones claras que evita que una IA adivine. Si puedes imprimirla y alguien más puede explicar tu app de vuelta, está haciendo su trabajo.

Comienza con una frase simple que describa la función de la app. Evita jerga. Ejemplo: “Ayuda a un equipo pequeño a rastrear solicitudes de clientes desde la bandeja de entrada hasta completadas.”

Luego, nombra tus tipos de usuario. Manténlo reducido (2 a 4). Para cada uno, escribe lo que pueden hacer usando verbos simples: ver, crear, editar, aprobar, eliminar. Esto previene el caos de permisos después.

Un orden fiable que mantiene la especificación en tierra:

1. Escribe la frase del trabajo (qué significa el éxito).
2. Define tipos de usuario y permisos (quién puede qué).
3. Escribe el camino feliz en 5 a 8 pasos (el recorrido que siempre debe funcionar).
4. Lista pantallas antes de funciones (qué páginas existen y qué debe hacer cada pantalla).
5. Añade campos de datos y reglas al final (una vez que las pantallas estén estables).

Para el camino feliz, sé concreto. Para una app de seguimiento de solicitudes: el usuario inicia sesión, crea una solicitud, asigna un responsable, el responsable cambia el estado, el solicitante recibe una notificación, un manager ve un resumen semanal.

Después de que la lista de pantallas esté clara, añade los campos de datos que necesita cada pantalla (título, descripción, estado, responsable, timestamps) y las reglas (campos obligatorios, cambios de estado permitidos, quién puede editar tras la aprobación). Aquí es donde los prototipos generados por IA suelen fallar: las reglas se sobreentienden en vez de escribirse.

Define pantallas de una forma que una herramienta de IA pueda ejecutar

Si quieres un build predecible, tu lista de pantallas debe leerse como instrucciones, no como un moodboard. Una regla simple de nombres ayuda: usa verbo + sustantivo para que cada pantalla implique qué ocurre allí.

Ejemplos: “Ver Pedidos”, “Crear Factura”, “Editar Perfil”, “Restablecer Contraseña”. Evita nombres vagos como “Dashboard” a menos que digas qué contiene.

Trata cada pantalla como una tarjeta pequeña con los mismos campos cada vez:

• Propósito: una frase que describa qué se considera “éxito” en esa pantalla.
• Quién puede acceder: roles (Invitado, Usuario conectado, Admin) más cualquier limitación especial.
• Acciones principales: 2 a 4 acciones escritas como botones.
• Datos mostrados/editar: los objetos clave involucrados.
• Salidas: qué cambia después de la acción (registro creado, email enviado, estado actualizado).

Marca los puntos de entrada para que la navegación no se invente. Por ejemplo: onboarding desde el primer lanzamiento, login desde “Sign in”, un enlace de invitación a “Aceptar invitación”, o un deep link a un elemento específico.

También define los estados aburridos que son fáciles de saltarse pero caros después. Para cada pantalla, añade notas de una línea para:

• Estado vacío: qué ve el usuario cuando aún no hay datos.
• Estado de error: qué ve el usuario cuando algo falla, más la acción de recuperación.

Finalmente, evita la expansión de alcance nombrando pantallas que no deben existir. Ejemplo: “No debe existir: analíticas de admin, perfiles públicos de usuarios, chat dentro de la app.” Es una línea simple que evita datos extra, permisos y bugs.

Haz los flujos de usuario predecibles, no imaginativos

Las herramientas de IA son buenas llenando huecos, y ese es el problema. Si no detallas los flujos principales, la herramienta inventará pasos, pantallas y navegación que suenan plausibles pero no coinciden con lo que querías.

Elige 2 a 3 flujos centrales y escríbelos de extremo a extremo como pasos sencillos. Mantén la primera pasada lineal y luego añade solo las ramas que prevengan mala UX y lógica rota.

Una forma simple de escribir flujos

Escribe cada flujo como un camino numerado con inicio y fin claros. Usa los nombres exactos de pantalla que listaste y declara qué ocurre después de cada acción.

• Flow 1: Sign up -> Verify email -> Create profile -> Land on Dashboard
• Flow 2: Create item -> Save -> See item detail -> Return to list with a success message
• Flow 3: Checkout -> Pay -> Confirmation -> Land on Orders (not back to the cart)

Luego añade unas cuantas ramas críticas:

• Cancelar: si el usuario se sale a mitad, ¿dónde aterriza?
• Reintentar: ¿qué ocurre tras un pago fallido o una subida fallida?
• Permiso denegado: ¿qué ve el usuario y a dónde puede ir después?
• Eliminar: paso de confirmación y a dónde va el usuario tras la eliminación.

Sé explícito sobre la navegación. Si la app usa pestañas, nómbralas. Si usa una barra lateral, lista secciones. Si es un flujo lineal, dilo. También indica expectativas de “volver a” como “tras editar, volver al detalle del ítem” o “tras guardar ajustes, quedarse en la misma página”.

Lista campos de datos para que la base y la UI coincidan

Si no anotas los campos de datos, una herramienta IA los inventará. Así terminas con una UI que pide una cosa y una base que almacena otra.

Una pequeña tabla de campos suele ser suficiente para mantener la consistencia del build.

Usa una tabla compacta de campos

Elige los objetos principales (por ejemplo: User, Project, Item) y lista los campos para cada uno. Manténlo corto: nombre, tipo, requerido y un ejemplo.

Debajo de la tabla, añade una línea: qué campos son entrada de usuario vs generados por el sistema. Ejemplo: title y due_date son entrada del usuario; status por defecto es draft; owner_user_id se establece desde el usuario conectado; created_at es automático.

Las relaciones importan porque impulsan pantallas y permisos. Escríbelas claramente: “Un usuario posee muchos proyectos. Un proyecto tiene muchos items. Un item pertenece a un proyecto.”

Los valores por defecto y timestamps previenen bugs de “¿por qué está esto en blanco?”. Decláralos: status = draft, role = member, updated_at cambia al editar, deleted_at se usa para borrado blando (si lo quieres).

Los campos sensibles necesitan manejo explícito:

• Contraseñas: almacenar solo un hash, nunca texto plano
• Tokens/keys: almacenar cifrados, nunca mostrar el valor completo en la UI
• Secretos: mantener fuera del cliente y de los logs

Escribe las reglas que detienen la lógica rota

Una lista de pantallas y campos le dice a la IA qué construir. Las reglas le dicen cómo debe comportarse la app cuando la usan personas reales. Sin reglas, obtienes código que “más o menos funciona”: formularios aceptan datos malos, usuarios ven cosas que no deberían y los cambios de estado ocurren fuera de orden.

Escribe reglas en lenguaje llano, pero hazlas comprobables. Alguien debe poder leer una regla y responder “pasa o falla?”.

Los tres tipos de reglas a incluir

• Validación: obligatorio vs opcional, longitud mínima/máxima, formatos permitidos, condiciones entre campos
• Permisos: quién puede ver, crear, editar, eliminar y qué ocurre si lo intentan de todas formas
• Lógica de negocio: cómo cambian los registros en el tiempo (estados), límites, unicidad, deduplicación

Ejemplo: un formulario “Solicitar presupuesto”.

Reglas de validación: el email debe coincidir con un formato normal; el nombre de empresa tiene 2 a 80 caracteres; el presupuesto es obligatorio solo si el tipo de Project = Full rebuild.

Reglas de permisos: cualquiera puede crear una solicitud; solo admins pueden cambiar el estado; el solicitante puede ver su solicitud solo a través de un enlace mágico.

Reglas de negocio: el estado puede moverse Draft -> Submitted -> Approved/Rejected, pero nunca hacia atrás; una solicitud activa por email por día; sumisiones duplicadas combinan notas en vez de crear un segundo registro.

Decide qué ocurre cuando algo falla

No te quedes en “muestra un error.” Especifica el comportamiento para que UI y API coincidan.

Mantenlo simple:

• El mensaje es corto y específico (sin términos técnicos).
• Aparece en un lugar consistente (inline bajo el campo o un banner superior).
• Se preserva la entrada del usuario.
• Fallos de permiso por defecto se niegan.
• Los fallos se registran con una razón que los admins puedan revisar.

Casos límite que vale la pena señalar: enlaces expirados, usuarios eliminados referenciados por registros antiguos y envíos dobles por doble clic.

Añade unos pocos no negociables (seguridad, auth, escala)

Una especificación de una página no está completa hasta que nombras las cosas que la build no debe fallar. Estos guardarraíles evitan reconstrucciones de último minuto.

Seguridad y autenticación (elige, no supongas)

Sé explícito sobre cómo la gente inicia sesión. Si no eliges, la IA lo hará.

Decide:

• Método de auth: email + contraseña, magic link, OAuth (Google, etc.) o sin login
• Roles: quién puede ver qué (por ejemplo: admin vs usuario regular)
• Reglas de sesión: tiempo de auto-logout, “recordarme” activado/desactivado

También escribe dos expectativas básicas en palabras sencillas: “No dejar secretos en el código o cliente” y “Toda entrada del usuario debe validarse y ser segura.” Esto ayuda a prevenir claves de API expuestas, inyección SQL y formularios que aceptan cualquier cosa.

Escala, logs y expectativas de despliegue

No necesitas números exactos, solo objetivos aproximados. Ejemplo: “lanzamiento con ~200 usuarios, puede crecer a 10,000; cuenta típica tiene 50 a 5,000 registros.”

Añade qué debe registrarse para auditorías y debugging: inicios, fallos de inicio, cambios de permisos y eliminaciones.

Finalmente, indica dónde correrá. “Necesitamos staging y producción” es suficiente. Nota que los secretos deben estar en variables de entorno (no hardcodeados) y lista los pocos que ya conoces (database URL, clave del proveedor de email).

Establece límites para que el build se mantenga enfocado

Las herramientas de IA son rápidas, pero también “ayudan” añadiendo funciones extra que no pediste. Una especificación de una página necesita guardas para que la v1 sea pequeña, testeable y tenga sentido enviarla.

Empieza con una división simple: must have vs nice to have. Los must haves son el conjunto mínimo que hace el producto usable de extremo a extremo. Los nice to have son ideas reales, pero no pueden bloquear la v1.

Define qué significa “hecho” para v1 en palabras claras. Aquí das permiso para ignorar inflación de alcance: pulido de diseño, filtros avanzados, roles que no necesitas todavía, multi-idioma, analíticas profundas.

Para mantener objetivo el build, añade unas comprobaciones de aceptación por pantalla:

• La pantalla carga sin errores y muestra el estado vacío correcto
• El usuario puede completar la acción principal en 3 pasos o menos
• Los errores de validación aparecen junto al campo y bloquean el guardado
• Aparece feedback de éxito y los datos son visibles tras refrescar
• Las reglas de permisos se hacen cumplir (usuarios bloqueados no ven ni editan)

También decide qué puede mockearse en v1 y qué debe ser real. Los mocks están bien si se etiquetan claramente y son seguros. Ejemplo: pago falso (sin cargo real), emails escritos a un log en vez de enviados, URLs de subida de archivos placeholder, respuestas fijas de APIs externas.

Ejemplo de especificación de una página (escenario simple y realista)

Aquí tienes una especificación de una página que podrías entregar a un constructor de IA para una pequeña app de reservas de clínica.

App: “BrightClinic Booking”

Usuarios: Pacientes y admins de la clínica.

Pantallas: Landing (qué ofrece la clínica + “Book”), Registrarse / Iniciar sesión, Reservar cita, Mis reservas, Horario admin.

En Reservar cita, el usuario elige una fecha, ve los horarios disponibles, selecciona una hora, añade una nota opcional y confirma. En Mis reservas, el usuario ve citas futuras y puede reprogramar o cancelar.

Campos de datos (Appointment): Patient name (text), phone (text), appointment time (date/time), status (scheduled, cancelled), notes (optional text). Mantén el perfil del paciente mínimo para v1: name y phone.

Reglas (la lógica que no debe romperse)

• Sin doble reserva: solo una cita por franja horaria.
• Ventana de cancelación: los pacientes pueden cancelar hasta 24 horas antes de la hora de la cita.
• Ediciones solo por admin: solo los admins pueden cambiar estado, mover cualquier reserva o editar notas tras la confirmación.
• Los pacientes solo pueden ver y gestionar sus propias reservas.

Comprobaciones rápidas de aceptación:

1. Un paciente puede registrarse, reservar un hueco y verlo en Mis reservas.
2. Reprogramar libera el hueco viejo y reserva el nuevo.
3. Cancelar dentro de 24 horas está bloqueado con un mensaje claro.
4. El horario admin muestra todas las citas, incluido el estado.
5. Un paciente no puede acceder a la pantalla de admin.

Errores comunes que hacen el código generado por IA un desastre

La mayoría de proyectos enmarañados generados por IA empiezan con una especificación que suena completa pero deja fuera los detalles que la IA necesita para tomar decisiones consistentes. El resultado son pantallas aleatorias, datos que no coinciden y lógica que funciona en un sitio y falla en otro.

Los patrones que más daño causan:

• Notas solo de función sin pantallas. “Los usuarios pueden gestionar facturas” no basta. Sin nombrar pantallas (List, Create, Detail, Edit), el build suele saltarse básicos como estados vacíos y pasos de confirmación.
• Permisos y roles faltantes. Si no dices quién puede ver, crear, editar, eliminar, el valor por defecto suele ser “todo el mundo puede todo”.
• Sin ejemplos de campos. Si dices “número de teléfono” o “status” sin valores de ejemplo, la IA adivina formatos y nombres. Terminas con phone, phoneNumber y mobile en distintos archivos, más valores de estado en conflicto.
• Sin manejo de fallos. Muchos builds describen solo el camino feliz. Un login fallido o una lista vacía entonces llevan a pantallas en blanco o carga infinita.
• Mezclar v1 y “luego”. Cuando las ideas futuras comparten la misma especificación, el build intenta incluirlo todo. Obtienes ajustes a medio hacer, tablas sin usar y navegación confusa.

Otra comprobación: si le dieras tu especificación a un nuevo compañero, ¿podría decir exactamente qué construir mañana y qué ignorar hasta después? Si no, la IA llenará los huecos.

Lista rápida y siguientes pasos

Antes de hacer clic en “build”, haz una pasada rápida sobre tu especificación de una página. Si puedes responder estos puntos sin adivinar, la herramienta de IA tiene más probabilidades de producir algo consistente.

Confirma que tienes:

• Alcance claro de pantallas (qué puedes hacer en cada pantalla, no solo el título)
• Roles y permisos, más los flujos principales escritos de extremo a extremo
• Campos de datos listados (nombre, tipo, requerido/opcional, por defecto, valor de ejemplo)
• Validación, permisos y comportamiento ante fallos (qué error se muestra, dónde y qué ocurre después)
• Límites para v1 (must have vs nice to have)

Si algo se siente borroso, arréglalo ahora. “Los usuarios pueden editar un perfil” es vago. “El usuario puede editar nombre y teléfono; email es solo lectura; phone debe tener 10 a 15 dígitos; mostrar error bajo el campo; guardar deshabilitado hasta que sea válido” es algo que una herramienta puede seguir.

Siguientes pasos:

1. Pega la especificación en tu constructor de IA y pide una v1 funcional, no un producto completo.
2. Prueba el camino feliz y algunos casos de fallo (contraseña incorrecta, campo obligatorio faltante, sin permiso, estado vacío, error de red).
3. Si ves comportamiento extraño, actualiza la especificación primero y luego reconstruye o regenera solo la parte afectada.

Si ya tienes un prototipo generado por IA que está roto o es inseguro (problemas de auth, secretos expuestos, lógica inconsistente), FixMyMess (fixmymess.ai) está pensado exactamente para ese handoff: diagnosticar qué falla, reparar y endurecer el código, y prepararlo para despliegue cuando el prototipo necesita volverse apto para producción.