02 — UX Research & modelo operativo (microflotas)
Método: investigación secundaria + síntesis operativa. No son entrevistas de campo reales.
Fuentes citables abajo. Cada hallazgo se marca: comprobado (secundario) / supuesto / hipótesis / decisión de diseño.
1. Preguntas de investigación (cerradas en esta ejecución)
- ¿Cuántas paradas/día gestiona una microflota / mensajero de cargo bike en ciudad densa?
- ¿Qué implica offline (cobertura irregular en sótanos, parking, casco antiguo) para el courier?
- ¿Qué debe hacer el producto hoy (L2) con esas respuestas?
2. Hallazgos — volumen de paradas
| Fuente | Dato | Tipo |
|---|---|---|
| Microhub + e-cargo bike pilots (p. ej. resúmenes de NYC DOT / estudios microhub) | ~4–8 viajes/día × ~5 entregas/viaje → orden 20–40 paradas/día por bici en programas densos | Comprobado (secundario agregado) |
| Modelos de ruta cargo e-bike en literatura (p. ej. ETRR 2019, escenarios de densidades) | Rutas de referencia con ~8 stops en tramos cortos; capacidad de bultos limita carga, no el “tapping” de estado | Comprobado (secundario) |
| Flotas van/camión urbana (fleet last-mile) | 80–150 stops/día en van — no es el target de microflota TROCHA | Comprobado (contexto; fuera de persona) |
| Ops microflota 2–15 riders (modelo de producto) | Coordinador ve 15–80 paradas/día en total flota; courier individual 8–25 paradas/turno en B2B ligero/local | Supuesto de diseño calibrado por secundarios |
| Decisión TROCHA L2 | KPI de volumen del día en consola ops: total, por estado, % entregadas. Seed ≥ 12 paradas del día para lista creíble | Decisión de diseño |
Implicación producto (implementada):
- Endpoint y UI de stats del día (no solo lista plana).
- Lista ordenada por urgencia operativa (en ruta → asignada → pendiente → entregada/fallida).
- Copy de journey y JTBD anclado a “turno con muchas paradas”, no a flota van de 120 stops.
3. Hallazgos — offline
| Hallazgo | Tipo |
|---|---|
| Mensajeros pierden red en sótanos, patios interiores, parkings y tramos de casco antiguo (patrón operativo conocido en last-mile; no medido aquí con telemetría) | Hipótesis fuerte / supuesto de campo |
| Actualizar estado debe poder encolarse y sincronizar al recuperar red; no bloquear el turno | Decisión de diseño |
| Listado de la ruta del día debe ser legible offline desde última sync (caché local) | Decisión de diseño |
| Conflictos de estado concurrente (ops + courier) → last-write-wins en L2; documentar riesgo | Decisión de diseño (L3: versionado) |
Implicación producto (implementada):
- Banner offline / en cola.
- Caché de paradas en
localStoragetras cada listado OK. - Cola de
PATCH statussinavigator.onLine === falseo fallo de red; flush enonline. - Detalle de parada usable desde caché si GET falla.
4. Personas (actualizadas con modelo operativo)
Nora Aguilar — DISPATCHER (ops)
| Campo | Valor |
|---|---|
| Rol | Coordinadora microflota 4–8 mensajeros |
| Volumen | ~20–60 paradas/día flota (supuesto) |
| Devices | Laptop + móvil |
| Necesidad | KPIs del día + asignar sin WhatsApp |
| Cita (sintética) | “Si no veo cuántas van en ruta, llamo a todo el mundo.” |
Hugo Serra — COURIER
| Campo | Valor |
|---|---|
| Rol | Cargo bike |
| Volumen | ~10–20 paradas/turno (supuesto calibrado) |
| Devices | Móvil, guantes, sol |
| Necesidad | 1 tap estado; funciona sin red un rato |
| Cita (sintética) | “En el parking del centro se me cae el 4G; igual tengo que marcar entregado.” |
5. JTBD
Funcional: Cuando empiezo el turno con muchas paradas, quiero un listado con estado y volumen del día, para no repreguntar por chat.
Emocional: Reducir ansiedad de “¿se me ha perdido un paquete?”.
Social: Parecer flota profesional frente a comercios B2B locales.
6. Stories Must (con AC)
| ID | Historia | Prioridad | Criterios de aceptación |
|---|---|---|---|
| E1 | Login JWT multi-rol | Must | Token con role DISPATCHER|COURIER |
| E2 | Ops lista + stats día | Must | Totales por estado del día calendario |
| E3 | Ops crea y asigna | Must | PENDING o ASSIGNED con courierEmail |
| E4 | Courier cambia estado | Must | IN_TRANSIT / DELIVERED / FAILED |
| E5 | Offline enqueue status | Must | Sin red, estado queda en cola y se reintenta |
| E6 | Lista cache offline | Must | Sin red, se muestran últimas paradas cacheadas |
7. Journey (ops + courier) — offline branch
- Login ops → stats día → crea paradas
- Courier login → ve asignadas (cache al cargar)
- En sótano: marca DELIVERED offline → banner cola
- Sale a la calle:
online→ flush → ops ve DELIVERED
8. Fuentes (secundarias)
- Springer ETRR: Measuring delivery route cost trade-offs between electric-assist cargo bicycles and delivery trucks (2019) — escenarios de densidades y stops.
- Microhub / e-cargo summaries (NYC DOT y estudios microhub): órdenes de magnitud entregas/hora y trips/día.
- Last-mile fleet guides: van 80–150 stops/día como contraste de no-persona.
9. No inventado
No se afirman entrevistas, NPS de clientes reales ni telemetría de flotas TROCHA. El seed y la UI son demo realistas, no datos de un cliente productizado.
