ATRIO · 02-ux-research-strategy.md · 3 de 21

En esta página 6.1 Stakeholders 0%

02 — Investigación UX y estrategia · ATRIO

Nota metodológica: No hay investigación primaria. Perfiles, JTBD y journeys son constructos de diseño. Validar con observación en taquilla y entrevistas a docentes antes de producción.


6.1 Stakeholders

StakeholderInfluenciaInterésNecesidadesRiesgosRelación
Dirección museoAltaAltaVisitas, reputación, servicio públicoScope políticoPropietario
Comunicación / webMediaAltaContenido actualizable, SEOBurnout editorialEditor
Taquilla / atenciónMediaAltaMenos llamadas repetidasResistencia al cambioOperador
DocentesBajaAltaGrupos, confirmaciónAbandono si no respondenUsuario clave
Visitante ciudadanoBajaMediaClaridad, horarios, a11yNo vuelveUsuario principal
Turista de pasoBajaMediaMóvil, 1 expo “imperdible”BounceUsuario secundario
AyuntamientoAltaMediaTransparencia, accesibilidadPlazos y pliegosPatrocinador
ConservaciónMediaMediaCorrecta presentación de obraConflictos de copyContribuidor
Legal / privacidadAltaMediaRGPD en formulariosMultasGatekeeper
Soporte técnico municipalMediaBajaHosting estableDowntimeDependencia

6.2 Perfiles de usuario

Perfil 1 — Marta “Docente” (primaria)

CampoDetalle
RolProfesora de secundaria, organiza salidas culturales
Edad38
Contexto1–2 visitas al museo al año con 20–28 alumnos
Experiencia digitalMedia-alta (email del centro, Classroom)
MotivacionesCumplir programación; logística simple y confirmable
NecesidadesFormulario de grupo, fechas, respuesta en 48 h
ObjetivosReservar visita escolar a “Luz de sala” en abril
Frustraciones“No sé si hay cupo ni a quién escribir”
LimitacionesSolo puede gestionar en recreos; móvil a veces
DispositivosAndroid + portátil del centro
EntornoSala de profesores; wifi irregular
AccesibilidadPrefiere formularios cortos, labels claros
Cita«Si puedo pedir grupo en cinco minutos, lo hago.»
EscenarioMartes 11:20: rellena formulario escolar para 24 personas el 18/04

Perfil 2 — Luis “Visitante local”

CampoDetalle
RolJubilado reciente, visita culturales de mañana
Edad62
ContextoVive en la ciudad; busca temporales nuevas
Experiencia digitalMedia; prefiere web clara
MotivacionesVer algo nuevo sin colas ni sorpresas de horario
NecesidadesLetra legible, horarios, tarifas, acceso
ObjetivosConfirmar si la temporal está abierta el domingo
FrustracionesHorarios confusos en redes; PDFs
DispositivosiPad + portátil en casa
EntornoCasa, luz diurna
AccesibilidadTexto ≥16px; contraste alto; sin jerga
Cita«Solo quiero saber si está abierta la temporal.»
EscenarioSábado noche: mira home y ficha, planifica domingo 11:00

Perfil 3 — Noa “Turista 48 h”

CampoDetalle
RolVisitante de fin de semana
Edad27
Contexto48 h en la ciudad; 1 actividad cultural
Experiencia digitalAlta
MotivacionesUna exposición “imperdible” bien fotografiada
NecesidadesMobile-first, hero claro, CTA entradas
ObjetivosDecidir en 2 minutos si va al museo o a otro plan
FrustracionesWebs municipales anticuadas
DispositivosiPhone
Entorno4G en la calle
AccesibilidadTouch targets grandes
Cita«Si se ve bien en el móvil, compro o voy.»
EscenarioViernes 18:00: abre home en el tren, guarda “Planificar visita”

Perfil 4 — Clara “Comunicación museo” (staff)

CampoDetalle
RolTécnica de comunicación y públicos
Edad34
ContextoGestiona web, redes y bandeja de visitas de grupo
Experiencia digitalAlta
MotivacionesResponder leads a tiempo; medir demanda
NecesidadesListado de solicitudes NEW/CONTACTED/CLOSED
ObjetivosBajar tiempo de primera respuesta a < 1 día laborable
FrustracionesEmails perdidos en bandeja compartida
DispositivosMacBook en oficina
Cita«Necesito ver quién escribió ayer y marcarlo contactado.»
EscenarioLunes 09:00: abre /staff, filtra NEW, llama a Marta

6.3 Jobs To Be Done

JTBD 1 — Visitante, decidir visita

Cuando tengo un hueco cultural, quiero ver qué hay abierto y la ficha de la exposición, para decidir si merezco el desplazamiento.

JTBD 2 — Docente, grupo escolar

Cuando organizo una salida, quiero solicitar plaza de grupo y dejar mis datos, para recibir confirmación sin depender del email genérico.

JTBD 3 — Staff, gestionar demanda

Cuando llegan peticiones, quiero verlas ordenadas y cambiar su estado, para no perder leads y medir carga de trabajo.

JTBDBarrerasAlternativas actuales
1Web rota, sin fotosInstagram, boca a boca
2Sin formularioTeléfono taquilla
3Email caóticoExcel manual

6.4 Historias de usuario (épicas)

Épica E1 — Descubrir exposiciones

IDHistoriaPrioridadAC (resumen)Métrica
E1-1Como visitante, quiero ver exposiciones publicadas en home y listado, para elegir qué visitarMustSolo published; cards con foto, título, fechas, estadoexhibition_list_view
E1-2Como visitante, quiero filtrar por Actual/Próxima/Pasada, para acotarShouldQuery status; empty si 0filter_apply
E1-3Como visitante, quiero abrir ficha por slug, para leer cuerpo y comisariadoMust404 si no existe; CTA entradas/visitaexhibition_view
E1-4Como sistema, quiero seed de 3 exposiciones realistas, para demoMustSeed idempotente o documentado

Épica E2 — Planificar visita

IDHistoriaPrioridadACMétrica
E2-1Como visitante, quiero horarios, tarifas, dirección y a11y, para planificar el díaMustDatos de /visit-info; error reintentablevisit_plan_view
E2-2Como visitante, quiero CTA a solicitar entradas desde visita y detalleMustLinks a /entradas con exhibitionId opcionalcta_click

Épica E3 — Solicitar entradas / grupo

IDHistoriaPrioridadACMétrica
E3-1Como visitante/docente, quiero enviar solicitud con nombre, email, personas y tipoMustValidación; 201; status NEWvisit_request_submit
E3-2Como visitante, quiero ver confirmación clara tras envíoMustPantalla success con email
E3-3Como visitante, quiero mensajes de error de validación y de redMustCampos + bannervisit_request_error

Épica E4 — Staff solicitudes

IDHistoriaPrioridadACMétrica
E4-1Como staff, quiero listar solicitudes con clave, para gestionar demandaShould→Must v1.1Header x-staff-key; 401 si nostaff_list
E4-2Como staff, quiero marcar CONTACTED/CLOSEDMust staffPATCH statusstaff_status_change

MoSCoW

MustShouldCouldWon’t ahora
Catálogo, ficha, visita, form, estados, seed, staff básicoEmail real, CMS exposicionesColección, agenda educativa, i18nPago online, app nativa, multi-museo

Casos de error / alternativos (E3)

  • Email inválido → no envía, mensaje bajo campo
  • API caída → banner + teléfono de recepción
  • exhibitionId inválido → 400
  • Doble submit → botón disabled en sending

6.5 Journey maps

Journey A — “Sábado de exposición” (Luis)

FaseAcciónPensamientoEmociónTouchpointProblemaOportunidadMétrica
DescubrirAbre home“¿Qué hay?”CuriosidadHome heroHero genéricoFoto real + temporalpage_view
ExplorarScroll / listado“¿Me interesa?”InterésCardsSin fotoMedia reallist_view
EvaluarFicha“¿Cuándo?”ConfianzaDetalleTexto densoTipografía displayexhibition_view
Planificar/visita“¿Abre domingo?”AlivioPlan visitaInfo incompletaBloques clarosvisit_plan_view
DecidirVa en personaSatisfacciónOffline

Journey B — “Salida escolar” (Marta)

FaseAcciónEmociónTouchpointOportunidad
NecesidadPrograma trimestreEstrés
DescubrirFicha temporalEsperanzaDetalleCTA grupo
SolicitarForm escolar 24 paxAnsiedad/entradasTipos SCHOOL
EsperarEmail (futuro)ImpacienciaSLA 2 días
StaffClara marca CONTACTED/staffEstado visible

Journey C — “Lunes de bandeja” (Clara)

FaseAcciónTouchpoint
Entrar/staff + claveStaff
FiltrarNEWStaff filters
Contactarmailto / teléfonoLista
CerrarCONTACTED → CLOSEDPATCH

6.6 Service blueprint (resumen)

CapaElementos
UsuarioNavega, lee, envía form
FrontstageWeb ATRIO, confirmación UI, (futuro) email, taquilla
BackstageAPI Nest, Prisma, Neon, panel staff, bandeja coms
SoporteHosting, DNS, backups Neon
EvidenciasSolicitud NEW en BD, estados, seed exposiciones
FallosAPI caída → error UI + teléfono; clave staff filtrada → rotar STAFF_KEY; contenido viejo → owner editorial
RecuperaciónReintentar; canal telefónico documentado

Riesgos de investigación

  • No validado con docentes reales.
  • Rivera/sede es constructo de diseño.
  • Supuesto de “sin checkout” puede frustrar si el museo ya vende online.