Casos de uso y workflows

Esta página recorre los cinco flujos que estructuran la experiencia del usuario en EMA Well, desde el registro inicial hasta la decisión de pasar a Pro. La perspectiva es funcional —qué pasa, en qué orden y por qué importa— y deja para el manual de usuario las instrucciones paso a paso.

Onboarding y setup inicial

El onboarding lleva a un usuario nuevo desde el registro hasta su primer dashboard con pilares activos en menos de cinco minutos. La diferencia entre Free y Pro aparece en la fase de detección de necesidades: Free ofrece tres preguntas que autoseleccionan pilares del set base; Pro entrega entre cinco y ocho preguntas más extensas y usa Claude para generar pilares personalizados que pueden no existir en el catálogo curado.

Una vez confirmados los pilares, el sistema crea un recurso Patient FHIR para el usuario y registra la asociación en user_patient_map. Esa estructura permite que las observations generadas por cada check-in queden vinculadas correctamente desde el primer registro y mantengan portabilidad cuando el usuario decida exportar.

Check-in diario

El check-in diario es el corazón del producto. La meta de UX es explícita: completarlo en menos de sesenta segundos. Lo que el usuario ve son cinco pantallas cortas; lo que el sistema hace al recibir el submit es lo más denso del flujo.

El submit dispara cinco operaciones en paralelo: persiste la información operacional en daily_log y entries, genera las Observation FHIR con códigos LOINC canónicos, recalcula la racha considerando los días previos, evalúa si alguna acción desbloquea achievements, y dispara el flujo de nurturing por correo cuando corresponde. La pantalla post-check-in muestra un insight breve y la nueva racha; ningún usuario debería ver pasar más de un par de segundos entre el submit y esa confirmación.

Visualización semanal

El final de la semana es un buen punto de reflexión, y EMA Well lo modela como un flujo distinto del check-in diario. El usuario abre la vista semanal —típicamente los domingos por la mañana, según el patrón observado— y el sistema le muestra un heatmap de pilares por día y los trends de mood y energía. La decisión de escribir una reflexión semanal es opcional, pero el espacio está disponible para quienes lo aprovechen.

Adicionalmente, los domingos a la medianoche UTC, el sistema dispara un correo de resumen vía Loops que llega a la bandeja del usuario al día siguiente. El correo se envía solo a usuarios con al menos dos check-ins esa semana —menos que eso indica desconexión y un correo con un heatmap vacío no aporta valor.

Programa de doce semanas

El programa estructura los primeros tres meses del usuario en tres fases consecutivas de cuatro semanas cada una. La división es deliberada y refleja la curva habitual de adopción de hábitos: instalación, consistencia y, finalmente, integración.

Al completar la fase 1, el sistema dispara un trigger suave de upgrade a Pro para los usuarios que todavía estén en Free. La sugerencia aparece como modal contextual con la diferencia entre planes; cerrar el modal no penaliza la experiencia ni vuelve a aparecer hasta el siguiente hito. La idea es que el momento de mostrar Pro sea cuando el usuario ya invirtió cuatro semanas y está genuinamente comprometido, no en el primer login. Cada fase termina con un achievement automático y, al completarse las doce semanas, se desbloquea el achievement final program_complete.

Upgrade a Pro

El paso a Pro nace de tres triggers posibles dentro de la experiencia: una racha que llega o supera los siete días, un achievement recientemente desbloqueado, o el intento de tocar una feature que solo está disponible en Pro. Cualquiera de los tres lleva al usuario a la página de upgrade, que presenta los dos planes lado a lado.

La elección dispara Stripe Checkout —mensual o anual según preferencia del usuario— y, cuando la sesión se completa, el webhook de Stripe llega al worker de Well y actualiza subscriptions.tier = pro para el usuario. Las features Pro quedan activas inmediatamente: no hace falta cerrar sesión ni recargar, porque el tier se consulta en cada request sensible. Si el usuario cancela la suscripción más adelante, el tier vuelve a free solo al final del período pagado, lo que evita pérdida abrupta de funcionalidad.