02 — Estrategia de investigación UX — RELE
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 roles hogar + asesoría energética | Modelado de stakeholders + personas | §3–4 |
| Definir job principal | JTBD + stories Must | §5 |
| Mapear fricción de coordinación | Journey + service blueprint | §6–7 |
| Traducir a requisitos L2 | Matriz hallazgo → requisito → feature | §8 |
2. Fuentes y límites
Fuentes admisibles (secundarias / operativas)
- Conocimiento general de consumo doméstico (factura, contador, periodo de facturación).
- Analogía operativa con tools multi-rol de la serie (SURCO tareas, FIRME casos) — no copiar dominio.
- Restricciones ALS-2 de diversidad (sector energía libre; no marketplace; no lead-form-only; no fitness/agro).
Límites éticos de verdad
| Prohibido | Permitido |
|---|
| “El 68% de hogares pierde lecturas por WhatsApp” sin fuente | “[SUPUESTO] la coordinación informal es frecuente en asesoría doméstica” |
| Citas de usuarios ficticios como entrevistas reales | Quotes de persona etiquetadas como constructo de diseño |
| NPS inventado | Hipótesis H1–H4 con métrica futura |
3. Stakeholders
| Stakeholder | Influencia | Interés | Necesidad principal |
|---|
| Residente titular (RESIDENT) | Alta | Muy alta | Registrar y ver consumo por periodo |
| Asesor energético (ADVISOR) | Media–Alta | Alta | Cola de revisión y cierre con nota |
| Familia conviviente | Baja formal | Media | Entender picos (fuera de multi-user v1) |
| Comercializadora | Media potencial | Baja en v1 | No es marketplace ni integración |
| Regulador / CNMC | Alta potencial | Baja en v1 | Fuera de alcance L2 (no simular compliance) |
| Fabricante de contadores | Baja | Baja | IoT fuera de v1 |
Mapa de poder (resumen)
- Decisor de adopción en hogar: RESIDENT (titular de la vivienda / factura).
- Usuario frecuente de revisión: ADVISOR.
- Riesgo de rechazo: si la app pide más datos que un Excel sin devolver claridad de estado y nota.
4. Personas
P1 — Elena Marín · RESIDENT
| Campo | Detalle |
|---|
| Edad / contexto | ~38 años; piso en Ruzafa (València); trabaja híbrido |
| Digital | Alta (banca, apps); poca paciencia con formularios largos |
| Goals | Tener el consumo “a la vista”; no perder lecturas en el chat |
| Pains | Capturas de contador; no sabe si el asesor ya miró el mes |
| Quote de diseño | “Si no está en el panel, no cuentes con que lo he mandado.” |
| Email demo | casa@rele.energy |
Escenario: A mediados de agosto registra la lectura de 2026-08 (245 kWh), ve código RE-… y espera REVIEWED o nota FLAGGED.
P2 — Toni Gil · ADVISOR
| Campo | Detalle |
|---|
| Edad / contexto | ~44 años; asesor energético independiente / pequeña asesoría |
| Digital | Media–alta; prefiere desktop para revisión, móvil en visita |
| Goals | Ver cola SUBMITTED, validar o flaggear, dejar nota útil |
| Pains | Excel mezclado; no sabe qué ya revisó; sin CUPS a mano |
| Quote de diseño | “Dame periodo, kWh y CUPS. Yo marco si hay que revisar tarifa.” |
| Email demo | asesor@rele.energy |
Escenario: Abre RELE, filtra abiertas, entra en RE-0809-03, marca REVIEWED o FLAGGED con nota.
Anti-persona
| Quién | Por qué no es target v1 |
|---|
| Operador de EMS industrial multi-sede | Necesita SCADA, multi-tenant y SLAs → L3/L4 |
| Usuario solo “comparar tarifas y contratar” | Producto marketplace/comparador, no lecturas |
| Coach de club deportivo | Dominio VOLTA; no energía |
5. JTBD y user stories
Job principal
Cuando llega el cierre de periodo o la visita del asesor,
quiero registrar o revisar lecturas de contador con kWh y estado,
para tener el consumo a la vista sin perseguirse por WhatsApp.
Jobs secundarios
| Job | Rol |
|---|
| Ver cuántas lecturas abiertas hay | Ambos (scope distinto) |
| Dejar una nota de revisión legible | ADVISOR |
| Referir una lectura por código corto en llamada | Ambos |
Stories Must (v1)
| ID | Story | AC resumido |
|---|
| E1 | Como usuario, inicio sesión con email/password y recibo JWT | 200 + accessToken; 401 si mal |
| E2 | Como RESIDENT, listo mis lecturas y un summary (total, open, kwhTotal) | GET list + stats filtrados |
| E3 | Como ADVISOR, listo todas las lecturas de la demo | GET sin filtro resident |
| E4 | Como RESIDENT, creo lectura con period y kWh | POST; status SUBMITTED; code RE-… |
| E5 | Como ADVISOR, cambio estado a REVIEWED o FLAGGED con nota | PATCH status + advisorNote |
| E6 | Como RESIDENT, no puedo PATCH status | 403 |
| E7 | Como visitante, entiendo el valor en la home | CTAs “Soy residente / Soy asesor” |
Should / Could (fuera de L2 del día, no deuda)
- Selector multi-vivienda.
- Gráfico de tendencia kWh.
- Adjunto foto del contador.
- Notificaciones al marcar FLAGGED.
- Filtros UI por estado.
6. Journey — mes de Elena (happy path)
| Fase | Acción | Pensamiento | Touchpoint | Emoción |
|---|
| 1 Descubre | Llega a la home RELE | “¿Esto sustituye el Excel?” | / | Curiosidad |
| 2 Entra | Login casa@… | “Mis datos, no un form anónimo” | /login | Confianza |
| 3 Registra | period + kWh + coste | “En un minuto lo dejo” | /lecturas/nueva | Alivio |
| 4 Espera | Ve SUBMITTED en lista | “Toni lo verá” | /lecturas | Neutra |
| 5 Cierra loop | Ve REVIEWED + nota | “Tiene sentido el pico de AC” | /lecturas/:id | Satisfacción |
Journey asesor (paralelo)
| Fase | Acción | Touchpoint |
|---|
| Login | asesor@… | /login |
| Cola | Stats abiertas + lista | /lecturas |
| Revisión | Detalle kWh/CUPS | /lecturas/:id |
| Cierre | REVIEWED o FLAGGED + nota | PATCH |
7. Service blueprint (resumen)
| Capa | Elementos |
|---|
| Frontstage | Home, login, lista, form, detalle |
| Backstage humano | Asesor interpreta picos, decide flag |
| Sistemas | Angular :4200 · Nest :3009 · Prisma · Neon · JWT |
| Soporte | Seed demo, códigos RE-…, badges estado |
| Fallos | Red caída → error + reintento; 403 por rol; 401 sin token |
8. Matriz hallazgo → requisito → feature
| ID | Hallazgo (tipo) | Requisito | Feature L2 |
|---|
| F1 | Coordinación informal pierde contexto [SUPUESTO] | Captura estructurada period+kWh | POST /api/readings |
| F2 | Asesor necesita cola priorizable [HIPÓTESIS] | Lista + open count | GET list + stats |
| F3 | Cierre de revisión debe ser explícito [HIPÓTESIS] | Estados REVIEWED/FLAGGED | PATCH status |
| F4 | Confianza del residente en feedback [HIPÓTESIS] | Nota visible | advisorNote en detalle |
| F5 | Referencia oral en llamada [SUPUESTO] | Código corto único | code RE-MMDD-XXX |
| F6 | Ambos roles necesitan auth [DECISIÓN] | JWT multi-rol | login + guards |
| F7 | Vivienda ancla CUPS [DECISIÓN] | Entidad Home | seed + include en list |
9. Preguntas abiertas (investigación futura, no bloqueantes)
- ¿El asesor gestiona N hogares o 1:1 en la práctica real de la demo extendida?
- ¿DRAFT se usa en flujo real o basta SUBMITTED al crear? ([DECISIÓN v1]: create → SUBMITTED; DRAFT en enum para evolución.)
- ¿costEur lo rellena el residente o se estima? ([DECISIÓN v1]: opcional en form.)
10. Síntesis para diseño
| Principio | Aplicación en UI |
|---|
| Claridad del número | kWh y periodo prominentes; stats kWh Σ |
| Honestidad de estado | Badges DRAFT/SUBMITTED/REVIEWED/FLAGGED |
| Roles sin ambigüedad | CTA home dual; acciones create vs patch por rol |
| Referencia | Código RE-… siempre visible |
| Marca marítima calmada | Fog/navy/sea; coral solo para alerta |
Cierre de verdad: ninguna cifra de mercado en este doc es primaria. Las personas y journeys son constructos de diseño para alinear producto, Paper y código.
