02 — Estrategia de investigación UX — VOLTA
Importante: este documento contiene artefactos de diseño y razonamiento secundario.
No hay entrevistas de campo primarias ni estadísticas inventadas presentadas como dato medido.
Etiquetas: [COMPROBADO] en producto, [SUPUESTO], [HIPÓTESIS], [DECISIÓN DE DISEÑO].
1. Objetivos de investigación (del caso)
| Objetivo | Método en este caso | Salida |
|---|
| Entender actores del club de barrio | Modelado de stakeholders + personas | §3–4 |
| Definir job principal | JTBD + stories Must | §5 |
| Mapear fricción de plaza | Journey + service blueprint | §6–7 |
| Traducir a requisitos L1 | Matriz hallazgo → requisito → feature | §8 |
2. Fuentes y límites
Fuentes admisibles (secundarias / operativas)
- Conocimiento general de clubs deportivos de barrio y gestión informal de listas.
- Analogía operativa con captación de leads + inbox ops (serie daily: paneles JWT, estados).
- Restricciones ALS-2 de diversidad (sector fitness libre; no marketplace; no agro/legal/logistics).
Límites éticos de verdad
| Prohibido | Permitido |
|---|
| “El 68% de clubs usa solo WhatsApp” sin fuente | “[SUPUESTO] la coordinación informal es frecuente en clubs pequeños” |
| Citas de usuarios ficticios como entrevistas reales | Quotes de persona etiquetadas como constructo de diseño |
| NPS inventado | Hipótesis H1–H3 con métrica futura |
3. Stakeholders
| Stakeholder | Influencia | Interés | Necesidad principal |
|---|
| Socio potencial / visitante | Baja formal | Muy alta | Pedir plaza sin fricción |
| Coach del club (COACH) | Alta | Muy alta | Inbox ordenado y estados |
| Familia (inscripción KIDS) | Media | Alta | Datos de contacto claros |
| Junta / dueño del club | Alta adopción | Media | Menos caos operativo |
| Ayuntamiento / instalaciones | Baja en v1 | Baja | Fuera de producto |
| Apps marketplace fitness | Competencia | — | No copiar modelo multi-proveedor |
Mapa de poder (resumen)
- Decisor de adopción: coach / responsable del club.
- Usuario frecuente captura: visitante (form) y coach (inbox diario).
- Riesgo de rechazo: si el form pide más que un WhatsApp sin devolver acuse ni claridad de estado.
4. Personas
P1 — Marc Solé · Visitante / socio potencial
| Campo | Detalle |
|---|
| Edad / contexto | ~28 años; quiere HIIT o cancha por la tarde tras el trabajo |
| Digital | Alta; móvil-first; odia crear cuentas para “solo preguntar” |
| Goals | Saber que su plaza está pedida; recibir contacto del club |
| Pains | Mensajes sin respuesta; no sabe a quién escribir; horarios confusos |
| Quote de diseño | “Dime la clase, el día y que alguien me conteste.” |
| Seed demo | marc@example.com · solicitud HIIT VO-0808-01 |
Escenario: Entra en la web del club, elige HIIT 19:00, envía y guarda el código VO-.
P2 — Nora Beltrán · COACH
| Campo | Detalle |
|---|
| Edad / contexto | ~35 años; coach y cara del club de barrio |
| Digital | Media–alta; usa móvil entre clases y desktop en la oficina |
| Goals | Ver nuevas solicitudes, contactar, confirmar o cancelar plazas |
| Pains | WhatsApp mezclado con personal; no sabe quién ya fue llamado |
| Quote de diseño | “Si está en NEW, es mío. Si está CONFIRMED, hay plaza.” |
| Email demo | coach@volta.club |
Escenario: Login → inbox → Marc NEW → CONTACTED → tras llamada CONFIRMED.
Anti-persona
| Quién | Por qué no es target v1 |
|---|
| Cadena de gimnasios multi-ciudad con CRM y billing | Necesita multi-sede, cuotas, aforo live → L3/L4 |
| Marketplace de coaches freelancers | Producto tipo CORREA, no club propio |
5. JTBD y user stories
Job principal (visitante)
Cuando quiero un hueco en una clase o cancha del club,
quiero enviar mis datos y preferencias en un solo paso,
para que el coach me contacte sin perder el mensaje en WhatsApp.
Job principal (coach)
Cuando llegan pedidos de plaza,
quiero verlos con estado y tipo de clase,
para contactar y confirmar sin Excel ni papel.
Jobs secundarios
| Job | Rol |
|---|
| Ver cuántas abiertas (NEW+CONTACTED) hay | COACH |
| Referir una solicitud por código corto | Ambos |
| Cancelar si no hay hueco o no contesta | COACH |
Stories Must (v1)
| ID | Story | AC |
|---|
| US1 | Como visitante, quiero un form con tipo de clase, día y franja | POST 201 + redirect success |
| US2 | Como visitante, quiero un código de referencia | code visible en /ok |
| US3 | Como coach, quiero entrar con email/password | JWT + redirect /inbox |
| US4 | Como coach, quiero listar solicitudes y stats | GET list + summary |
| US5 | Como coach, quiero cambiar estado | PATCH status |
MoSCoW (v1)
| Prioridad | Ítems |
|---|
| Must | Home, join, success, login, inbox, detail, status, empty/error |
| Should | Labels ES de ClassType y status; badges de color |
| Could | Filtro por status en UI; copy teléfono click-to-call |
| Won’t | Pagos, aforo live, multi-coach, notificaciones push |
6. Journey (visitante → coach)
| Fase | Actor | Acción | Touchpoint | Emoción [HIPÓTESIS] |
|---|
| 1 Descubrir | Marc | Entra a web | Home hero | Curiosidad |
| 2 Elegir | Marc | Mira clases | Sección #clases | Interés |
| 3 Pedir | Marc | Rellena form | /apuntarme | Esperanza |
| 4 Acuse | Marc | Ve código | /ok | Alivio |
| 5 Contacto | Nora | Ve NEW, llama | Inbox + detalle | Control |
| 6 Cierre | Nora | CONFIRMED | PATCH | Satisfacción operativa |
Momentos de verdad
- Form sin cuenta — si pide login, abandono alto [HIPÓTESIS].
- Código VO- — prueba social de “ha llegado”.
- Estado en inbox — evita re-contactar a quien ya está confirmado.
7. Service blueprint (resumen)
| Capa | Elementos |
|---|
| Frontstage visitante | Home, form, success |
| Frontstage coach | Login, inbox, detail, botones estado |
| Backstage | Coach llama/WhatsApp externo (fuera de app) |
| Sistemas | Nest API, Prisma, Neon, JWT, Angular |
| Soportes | Seed demo, Paper, docs |
| Fallos | 401 sin token; 404 id; red caída → UI error |
8. Matriz hallazgo → requisito → feature
| Hallazgo | Tipo | Requisito | Feature v1 |
|---|
| Mensajes ambiguos sin clase/hora | [SUPUESTO] | Capturar ClassType + day + slot | Form join |
| Sin acuse al visitante | [HIPÓTESIS] | Devolver código | Success + code |
| Coach no sabe estado | [SUPUESTO] | Máquina de estados | RequestStatus |
| Panel abierto = riesgo PII | [DECISIÓN] | Auth JWT | Login + guards API |
| L1 compacto | [DECISIÓN] | Un rol COACH | Sin multi-rol |
9. Preguntas abiertas (no bloquean v1)
| ID | Pregunta | Cómo se resolvería después |
|---|
| Q1 | ¿Aforo real por franja? | Integración calendario L2+ |
| Q2 | ¿Email automático al coach? | Hook post-create L1+ |
| Q3 | ¿RGPD consent explícito en form? | Checkbox + política L1+ |
10. Síntesis
VOLTA se diseña como canal de plaza del club, no como marketplace fitness.
La investigación del caso es constructiva y etiquetada: personas, JTBD y journey son artefactos de diseño; las métricas de validación quedan para uso real futuro.
