Qué hace que una web sea seria y útil

Resultado visible

Crearás 01-ficha-problema.md: una ficha de una página que define para quién existe tu web, qué problema resuelve, qué información necesita y cómo comprobarás que funciona. Será el contrato de calidad de la primera versión y evitará empezar por colores, animaciones o tecnología.

Puedes descargar la plantilla editable o copiarla desde esta lección.

Antes de empezar

No necesitas saber programar. Necesitas una idea, 60 minutos y disposición para separar hechos de suposiciones.

Al terminar tendrás:

• una necesidad escrita desde el punto de vista de una persona;
• una acción principal que la web debe facilitar;
• un inventario de información con fuente y responsable;
• límites que impiden inventar confianza;
• entre cinco y siete criterios que otra persona puede comprobar.

Qué vas a aprender

• Útil: responde una necesidad real y permite avanzar hacia un resultado.
• Fiable: distingue hechos, condiciones y límites; no fabrica autoridad.
• Comprensible: una persona reconoce qué ofrece, para quién y qué debe hacer.
• Accesible: el recorrido esencial no depende de un dispositivo, sentido o habilidad concreta.
• Mantenible: alguien sabe qué actualizar, de dónde sale el dato y cómo comprobar el cambio.

Una web seria no tiene por qué ser grande. Una página rápida con un teléfono correcto puede ser mejor producto que una aplicación con diez pantallas inútiles. El diseño visual importa, pero no puede rescatar una dirección falsa, un formulario que no responde o una promesa que nadie puede demostrar.

El cambio de pregunta

Una petición suele empezar así:

«Quiero una web moderna para mi negocio».

Todavía no es un problema que se pueda construir ni probar. Cambia la conversación:

La tecnología se elige después. HTML estático, Next.js o una base de datos son medios; no son la definición del producto.

Caso conductor: Lumbre y Oliva

Usaremos un restaurante completamente ficticio para no disfrazar suposiciones de datos reales. La persona principal está caminando por la ciudad, consulta el móvil y quiere decidir dónde cenar. Tiene poca batería, quizá mala conexión y no quiere crear una cuenta.

Ejemplo resuelto

Petición vaga: «Quiero una web impresionante para mi restaurante».

Definición útil:

Necesidad escrita desde la persona:

Cuando estoy buscando dónde cenar desde el móvil, necesito consultar platos, precios, horario y forma de contacto, para decidir si el restaurante me encaja y solicitar una mesa sin sorpresas.

Observa lo que no dice: «necesito un carrusel», «necesito React» o «necesito un chatbot». Una necesidad describe el resultado, no adelanta la solución.

El caso ejecutable se conserva con código y pruebas en Aulafy Taller: Lumbre y Oliva. En esta lección analizamos el porqué; en el taller podrás inspeccionar el resultado.

Método paso a paso

1. Elige una persona y un momento

«Todo el mundo» no ayuda a priorizar. Empieza por la persona que tiene la necesidad más importante o frecuente y describe el momento que la activa.

Ejemplos concretos:

• estudiante que busca prácticas desde el portátil y necesita demostrar lo que sabe hacer;
• familia que compara una academia desde el móvil y necesita conocer nivel, horario y precio;
• pequeña empresa que busca soporte informático después de una incidencia;
• paciente que consulta un tratamiento y necesita información general antes de pedir cita.

No inventes una biografía de diez párrafos. Para esta ficha bastan situación, necesidad, posible barrera y resultado esperado.

2. Escribe la necesidad sin diseñar todavía

Usa esta estructura solo como ayuda:

Cuando [situación real], necesito [tarea o información],
para [resultado que intento conseguir].

Comprueba que una persona podría pronunciarla y que no contiene una función concreta. «Necesito recibir un email automático» puede esconder la necesidad real: «necesito saber si mi solicitud se recibió y qué ocurrirá después».

3. Define una acción principal

La acción principal es el avance más valioso que la web puede facilitar. No siempre es una venta.

Si aparecen cinco acciones «principales», todavía no has priorizado. Escoge una y trata las demás como apoyo.

4. Haz inventario de la información mínima

Anota qué necesita conocer la persona antes, durante y después de actuar.

Para el restaurante:

• antes: tipo de cocina, carta, precios, ubicación y horario;
• durante: fecha, turno, personas y canal de contacto;
• después: confirmación de recepción, plazo de respuesta y advertencia de que aún no hay reserva.

Cada dato cambiante necesita cuatro cosas:

Si no hay fuente o responsable, escribe [PENDIENTE]. Una casilla pendiente es más profesional que una respuesta inventada.

5. Diseña confianza con hechos

La confianza no se añade escribiendo «somos líderes» o colocando cinco estrellas falsas. Se construye mostrando información que la persona puede entender y contrastar:

• identidad y contacto coherentes;
• precios, condiciones y límites visibles;
• autoría o responsable del contenido cuando sea relevante;
• fecha de revisión en información cambiante;
• política de privacidad acorde con los datos realmente recogidos;
• mensajes honestos ante acciones incompletas o manuales.

En sectores sensibles, una frase prudente suele ser más valiosa que una promesa comercial. Una clínica informa, pero no diagnostica en una landing. Un despacho explica áreas de práctica, pero no garantiza resultados.

6. Convierte «que funcione» en pruebas observables

Un criterio de aceptación debe permitir que dos personas lleguen al mismo resultado. Incluye condición, acción y resultado cuando ayude.

Débil:

• «la web será moderna»;
• «el formulario funcionará»;
• «tendrá buen SEO».

Observable:

• a 390 px, el título explica la propuesta y la acción principal aparece sin desbordamiento horizontal;
• la carta se puede leer como HTML sin descargar un PDF;
• cada plato muestra nombre, descripción, precio y alérgenos conocidos en texto;
• el horario coincide en Inicio, Visita y datos estructurados;
• al enviar datos válidos, aparece un resumen y se explica que no existe reserva confirmada;
• con JavaScript desactivado siguen disponibles carta, horario, teléfono y correo;
• ninguna página publica reseñas, premios o disponibilidad que no procedan de una fuente aprobada.

Una ficha completa, no un documento eterno

Copia esta estructura en 01-ficha-problema.md:

# Ficha del problema

## 1. Persona y momento
- Persona principal:
- Situación que activa la visita:
- Barrera o restricción relevante:

## 2. Necesidad
Cuando [...], necesito [...], para [...].

## 3. Resultado y acción
- Resultado para la persona:
- Acción principal de la web:
- Qué ocurrirá después:

## 4. Información imprescindible
| Dato | Fuente | Responsable | Estado |
|---|---|---|---|
| | | | CONFIRMADO / PENDIENTE |

## 5. Incluido y excluido
- Incluido en la primera versión:
- No incluido todavía:
- Prohibido inventar:

## 6. Criterios de aceptación
- [ ]
- [ ]
- [ ]
- [ ]
- [ ]

## 7. Revisión
- Propietario de la ficha:
- Fecha:
- Próxima revisión:

Prompt para Codex

La documentación de Codex recomienda aportar objetivo, contexto, restricciones y una definición observable de terminado. En esta fase queremos análisis, no código.

Trabaja solo en modo análisis. No crees ni modifiques archivos.

OBJETIVO
Convertir mi idea en una ficha verificable para la primera versión de una web.

CONTEXTO
- Idea: [DESCRIBE LA IDEA EN TUS PALABRAS]
- Información real disponible: [ENUMÉRALA]
- Público que imagino: [ESCRÍBELO O INDICA QUE NO LO SABES]

LÍMITES
- No propongas tecnología, colores ni animaciones todavía.
- No inventes personas, precios, testimonios, credenciales ni requisitos legales.
- Distingue HECHO, SUPOSICIÓN y PENDIENTE.
- Si hay varios públicos, recomienda uno para la primera versión y explica el criterio.

FORMATO DE SALIDA
1. Persona principal y momento.
2. Necesidad: «Cuando…, necesito…, para…».
3. Resultado para la persona y acción principal.
4. Información imprescindible con fuente, responsable y estado.
5. Incluido, pospuesto y excluido.
6. Riesgos y afirmaciones que no se deben inventar.
7. Entre cinco y siete criterios de aceptación observables.
8. Máximo cinco preguntas que cambiarían materialmente la ficha.

TERMINADO CUANDO
Otra persona pueda leer la ficha, explicar para qué existe la web y comprobar
los criterios sin depender de gustos personales.

Cómo revisar la respuesta de Codex

Codex ayuda a estructurar la incertidumbre, pero no convierte una suposición en investigación de usuarios. Revisa línea por línea:

1. Persona: ¿existe o es una caricatura creada para justificar la idea?
2. Necesidad: ¿describe un resultado o una función elegida de antemano?
3. Datos: ¿cada precio, fecha, credencial y condición tiene fuente?
4. Acción: ¿puede completarse o se promete una automatización inexistente?
5. Criterios: ¿se pueden observar en una pantalla, una prueba o una conversación?

No aceptes una tabla solo porque está bien escrita. Corrige hechos, elimina relleno y conserva [PENDIENTE] donde todavía necesites preguntar.

Comparación antes y después

Práctica guiada

Elige uno de estos escenarios o usa tu propia idea:

1. Un estudiante necesita presentar tres proyectos y explicar qué aprendió.
2. Una academia pequeña necesita informar de niveles y recibir solicitudes de prueba.
3. Un profesional autónomo necesita explicar servicios y filtrar consultas relevantes.

Completa la ficha en este orden:

1. Escribe la necesidad sin mencionar páginas ni tecnología.
2. Decide una acción principal.
3. Enumera un máximo de diez datos imprescindibles.
4. Marca como [PENDIENTE] todo dato sin fuente.
5. Escribe cinco criterios observables, incluyendo uno móvil, uno de contenido y uno de límites.
6. Pide a Codex que critique la ficha sin editarla.
7. Corrige el documento y registra qué cambió.

Prompt de revisión:

Revisa esta ficha sin modificar archivos. No diseñes la web todavía.

Busca únicamente:
- necesidades que en realidad sean soluciones disfrazadas;
- más de una acción compitiendo por ser principal;
- afirmaciones sin fuente o responsable;
- funciones que prometan más de lo que la versión uno puede hacer;
- criterios subjetivos o imposibles de comprobar;
- personas o barreras importantes que hayan quedado excluidas.

Devuelve una tabla con: hallazgo, evidencia textual, impacto y corrección mínima.
Si no puedes demostrar un problema con el texto, no lo inventes.

FICHA:
[PEGA AQUÍ 01-ficha-problema.md]

Rúbrica de salida

Puntúa cada criterio con 0, 1 o 2:

Necesitas al menos 11 de 14 puntos y ningún cero en información, confianza o criterios. Si no llegas, no programes todavía: reduce alcance o consigue los datos que faltan.

Comprueba el resultado

Haz la prueba de un minuto: entrega la ficha a otra persona sin explicarla y pídele que responda:

1. ¿Para quién existe esta web?
2. ¿Qué problema intenta resolver?
3. ¿Cuál es la acción principal?
4. ¿Qué dato sigue pendiente?
5. ¿Cómo sabremos que la primera versión funciona?

Si necesita adivinar, la ficha todavía no está lista. También puedes pedir a Codex que responda usando solo el documento: si añade información, identifica la frase como inferencia y corrige el vacío.

Error frecuente y recuperación

Error 1: empezar copiando una web admirada. Recuperación: conserva la referencia visual para más adelante, pero vuelve a escribir la ficha sin mencionar colores ni animaciones.

Error 2: tratar al propietario del negocio como si fuera la única persona usuaria. Recuperación: separa el objetivo del negocio de la tarea que intenta completar quien visita la web.

Error 3: convertir [PENDIENTE] en contenido provisional publicado. Recuperación: bloquea esa afirmación o sustituye la función por un canal manual explícito.

Error 4: pedir a Codex que elija por ti datos que dependen del negocio. Recuperación: úsalo para detectar preguntas, contradicciones y pruebas; confirma tú precios, condiciones, permisos y publicación.

Mini ejercicio y evidencia

Guarda:

• 01-ficha-problema.md;
• evidencias/01-revision.txt con puntuación, preguntas falladas y cambios realizados.

No publiques la ficha ni uses datos personales durante la práctica. Si otra persona la revisa, comparte solo la información necesaria y elimina teléfonos, correos, credenciales o detalles sensibles.

Autoevaluación

1. ¿Una web estática de cuatro páginas puede ser profesional? Sí. La profesionalidad depende de resolver la necesidad con información fiable, accesibilidad, verificación y mantenimiento; no del número de dependencias.

2. ¿Por qué «quiero un chatbot» no es una necesidad de usuario? Porque nombra una solución. Primero hay que demostrar qué pregunta o tarea resuelve, con qué fuentes y qué ocurre cuando no puede responder.

3. ¿Qué haces si falta el precio o la política de cancelación? Marcarlo [PENDIENTE], identificar a quien debe confirmarlo y evitar publicarlo como hecho.

4. ¿Para qué sirven los criterios de aceptación antes de escribir código? Permiten delimitar el encargo, revisar el resultado y detectar cuándo una propuesta visual no resuelve el problema.

Siguiente paso

No diseñes todavía. En la lección 2 clasificarás cada función como imprescindible, posterior o excluida y elegirás el tipo de web más sencillo que pueda cumplir esta ficha.

Fuentes oficiales

• OpenAI: buenas prácticas para trabajar con Codex
• OpenAI: prompting
• GOV.UK Service Manual: aprender sobre las personas y sus necesidades
• GOV.UK Service Manual: medir el éxito de un servicio
• W3C WAI: planificar y gestionar la accesibilidad web