01 — Definición del proyecto: ATRIO
5.1 Identidad
| Campo | Valor |
|---|---|
| Nombre | ATRIO |
| Significado | Del atrio del museo: umbral entre la calle y las salas de exposición |
| Eslogan | El umbral entre la ciudad y la obra |
| Una frase | Web pública del museo municipal para descubrir exposiciones, planificar la visita y solicitar entradas o grupos |
| Descripción ejecutiva | ATRIO es el canal digital del Museo Municipal de Rivera: catálogo editorial de exposiciones con ficha, información práctica de visita (horarios, tarifas, acceso, accesibilidad) y captura de demanda de entradas/grupos/escolares sin checkout online en v1. Reduce fricción frente a redes dispersas y llamadas a taquilla. |
| Sector | Cultura / Museos / Administración local |
| Tipo | Web pública institucional + panel staff ligero de leads |
| Plataforma principal | Web responsive (desktop-first editorial, mobile usable) |
| Secundarias | Email de confirmación (stub v1); kiosco / ticketing online (roadmap) |
| Mercado | España/Latam — museo municipal de ciudad mediana (constructo; Rivera como sede ficticia de trabajo) |
| Idioma UI | Español |
| Otros idiomas | Catalán / inglés (roadmap) |
5.2 Problema
| Tipo | Contenido |
|---|---|
| Principal | Visitantes y docentes no encuentran en un solo sitio qué se expone, cuándo y cómo reservar o comprar entrada |
| Secundarios | Contenido en PDF/Instagram/carteles; colas de info en taquilla; grupos escolares sin canal claro; comunicación sin rastro de demanda |
| Quién | Ciudadanos, turistas de paso, docentes, familias, staff de comunicación |
| Hoy | Llamadas, email genérico, redes, cartel en fachada |
| Deficiencias | Info desactualizada; sin ficha de exposición; sin registro de solicitudes |
| Coste | Visitas perdidas, personal de taquilla saturado, baja ocupación en franjas tranquilas, mala experiencia turística |
| Oportunidad | Web ligera con catálogo vivo + captura de demanda |
Clasificación de conocimiento
| Clase | Ejemplos |
|---|---|
| Supuestos de diseño | El museo no tiene e-commerce de tickets; un lead es suficiente en v1; público con alfabetización digital media-alta |
| Hipótesis | Un formulario de 5 campos reduce llamadas de grupos ≥30 % |
| Decisiones | Sin pago online v1; staff con STAFF_KEY no OAuth; stack Angular/Nest/Neon |
5.3 Objetivos
| Tipo | Objetivos |
|---|---|
| Negocio | Aumentar visitas planificadas; reducir consultas repetitivas; visibilidad de temporal |
| Usuario | Saber qué ver, cuándo ir, cómo llegar, cómo pedir entrada/grupo |
| Producto | Catálogo + plan de visita + formulario + bandeja staff de solicitudes |
| Experiencia | Claridad editorial, confianza institucional, lectura cómoda (WCAG AA) |
| Técnicos | API de contenido; seed realista; CORS; sin secretos en git |
| No objetivos | Pago online, membresía, app nativa, multi-museo SaaS, i18n completo |
| Restricciones | Stack fijo cron; calidad portfolio aunque Nivel 1 de alcance |
| Riesgos | Contenido desactualizado; expectativa “comprar ya”; clave staff débil en prod |
5.4 Métricas
| Métrica | Definición |
|---|---|
| North Star | Solicitudes de visita/entrada completadas / semana |
| Activación | % visitas que abren ≥1 ficha de exposición |
| Conversión | % que envían formulario de entradas |
| Retención | Visitas recurrentes al catálogo (30 d) |
| Tarea | Tiempo a info de visita útil < 60 s |
| Abandono | Formulario iniciado sin envío |
| Error | Tasa de fallos POST visit-requests |
| Staff | Tiempo medio NEW → CONTACTED |
| A11y | 0 issues críticos automatizados en journey principal |
| LCP | Home < 2,5 s en 4G medio |
Complejidad y calidad
- Alcance: Nivel 1 (web pública + leads + staff ligero).
- Calidad: barra completa del cron §6.1 (paridad documental y de estados con proyectos de mayor nivel).
