Diseño end-to-end · Frontend
Vagalume
Un sistema para comprender el dolor a lo largo del tiempo
Una herramienta de autoconocimiento y acompañamiento que ayuda a las personas a reconocer patrones que influyen en su salud.
El dolor no es lineal
El dolor es subjetivo, episódico y no lineal. Evoluciona, se solapa con otras señales y, a menudo, se describe retrospectivamente de una forma difícil de interpretar.
La mayoría de las herramientas de seguimiento reducen esta complejidad a registros estáticos o interpretan patrones de forma prematura, generando observaciones que parecen inteligentes, pero que en realidad no están respaldadas por evidencia.
Pregunta de diseño
¿Cómo puede un sistema transformar información ambigua y cambiante en hallazgos fiables a lo largo del tiempo?
Tres decisiones que dieron forma al sistema
Generar confianza a través de la transparencia
La confianza crece cuando nada queda oculto detrás de una caja negra. Los usuarios pueden entender cómo el sistema llega a sus conclusiones.
Eliminar fricción a través de claridad
El sistema se explica a sí mismo mediante su uso. Una estructura clara y modelos mentales familiares reducen la necesidad de instrucciones.
Priorizar la integridad frente a la espectacularidad
Las conclusiones solo se muestran cuando los datos los respaldan. Cuando no hay suficiente evidencia, el sistema permanece en silencio.
Del seguimiento de episodios a la selección espacial
La primera versión se centraba exclusivamente en el seguimiento de episodios: cuándo comenzaba el dolor, su intensidad y cuándo terminaba. El objetivo del MVP fue validar la lógica principal: el seguimiento de episodios y la identificación de patrones a lo largo del tiempo.
Los tests con usuarios llevaron a introducir la selección espacial —tocar zonas de la cabeza en un mapa—, ampliar el seguimiento de síntomas e incorporar señales contextuales: factores relacionados con el dolor, como el estrés o dormir mal.
En el caso de los dolores de cabeza, el mapa permite seleccionar varias zonas, reflejando situaciones reales como un dolor que se extiende o afecta a ambos lados.
Estado y evolución del dolor de cabeza
El producto se diseñó para adaptarse a los modelos mentales de los usuarios sobre los episodios de migraña.
Un dolor de cabeza puede evolucionar con el tiempo. Por eso, los dolores de cabeza tienen dos estados: sin dolor y en curso. Cada actualización durante un episodio activo crea una instantánea del estado, que incluye intensidad, síntomas, ubicación y contexto.
Cuando el episodio termina, estas instantáneas se comparan cronológicamente para generar una línea temporal de evolución. Esta línea temporal explica qué ocurrió durante el episodio.
Los usuarios destacaron la evolución del dolor de cabeza como una forma muy útil de entender si algo ayudaba a aliviar el dolor o lo empeoraba. Esta percepción del usuario es subjetiva, ya que no existe una relación causal entre los distintos elementos.
Resultado del sistema
Los episodios representan lo que ocurrió. Los patrones representan lo que se repite. Estas dos capas son deliberadamente independientes por diseño.
Los patrones solo emergen a través de varios episodios y únicamente cuando se cumplen umbrales explícitos. Si no hay suficientes datos, el sistema permanece en silencio.
En la práctica, esto significa que los patrones no se muestran en absoluto. Los estados vacíos se tratan como resultados válidos, no como fallos.
Tras el user testing con usuarios, los patrones se integraron en el mapa del dolor de cabeza, ya que era el lugar en el que los usuarios se fijaban con mayor frecuencia.
Reorganizar los resultados a medida que el sistema maduraba
Las tarjetas de la página de inicio se reordenaron y agruparon a partir de la observación de cómo los usuarios utilizaban la web.
Los patrones pertenecían conceptualmente al mapa del dolor de cabeza, y esta información era más relevante que el número de dolores de cabeza y la intensidad media, que eran datos más secundarios.
Los dolores de cabeza recientes debían aparecer justo después del mapa para que los usuarios pudieran consultar el último registro y entender qué había ocurrido.
Una corrección importante
Revisé la lógica y me di cuenta de que los patrones estaban limitados a tres, aunque podían existir más.
Probé a colocar los patrones dentro de la tarjeta del mapa del dolor de cabeza, pero resultaba demasiado densa. En su lugar, los trasladé a una tarjeta independiente, sin la etiqueta «Patrones», que evité deliberadamente para reducir la carga cognitiva.
Reutilicé el icono de una bombilla para representar los insights. Funciona bien a distintas escalas y mantiene la coherencia en toda la aplicación: patrones y resúmenes.
Todos los datos hacían referencia a los últimos 30 días y ese contexto se repetía. Agrupé todo bajo un único encabezado de 30 días y eliminé el título de las tarjetas individuales.
Agregación de insights en el mapa del dolor de cabeza
Evité deliberadamente las descripciones de texto libre para prevenir ambigüedades durante el procesamiento de los datos y reducir el riesgo de generar conclusiones falsas o engañosas. En su lugar, la ubicación del dolor se registra mediante selección espacial y las observaciones se derivan de datos estructurados.
El mapa no es decorativo: es un mecanismo de introducción de datos que permite agregarlos y ayuda a los usuarios a ver la intensidad de un vistazo.
La intensidad se representa mediante cinco tonos de azul. Se exploraron los degradados, pero se descartaron porque no escalaban bien al imprimir informes. También se evitó un sistema de semáforo para no alarmar a los usuarios, ya que el objetivo es crear una experiencia de registro segura y tranquila.
Generalizar el sistema: dolor corporal
Amplié el sistema al dolor corporal y el modelado espacial se convirtió en el principal reto de diseño. A diferencia de la cabeza, el cuerpo introduce múltiples regiones.
En lugar de buscar una representación anatómica completa, elegí deliberadamente un modelo espacial simplificado: regiones lo bastante grandes como para poder tocarlas fácilmente en el móvil, pero lo bastante limitadas como para seguir siendo manejables a nivel cognitivo.
Resultado del sistema
No todas las zonas del cuerpo se pueden seleccionar.
Reduje deliberadamente el número de zonas de dolor corporal que los usuarios pueden registrar para hacer la introducción de datos más manejable y reducir la cantidad de información que el sistema debe procesar al mostrar patrones.
Por ejemplo, seleccionar «rodilla izquierda» incluye tanto la parte delantera como la trasera de la rodilla. Sin embargo, en el caso del dolor de espalda era necesaria una mayor granularidad debido al número de usuarios que señalaban dolor en zonas concretas. Por eso diseñé las regiones seleccionables con suficiente detalle para especificar el dolor con precisión.
Resultado del sistema
El seguimiento del dolor corporal difiere deliberadamente en un aspecto clave: el sistema permite registrar y agregar señales de dolor corporal sin imponerles un ciclo de vida.
Los dolores de cabeza encajan de forma natural en un modelo mental episódico; el dolor corporal no siempre. A través de los tests y del feedback, quedó claro que muchas personas no experimentan el dolor corporal como episodios diferenciados. Forzar esa estructura habría introducido fricción y distorsionado los datos.
Todos los registros diarios se resumen en una vista diaria del dolor, mientras que los dolores de cabeza se conceptualizan como episodios.
Trade-offs y limitaciones
Almacenamiento de datos
Todos los datos se almacenan localmente. Esto simplifica las decisiones relacionadas con la confianza y obliga a que la lógica del sistema siga siendo explícita e inspeccionable.
Onboarding
No hay un onboarding que pida a los usuarios que declaren de antemano sus patrones o dolores habituales. Es intencionado: el producto está diseñado para explicarse por sí mismo.
Sin predicciones
No hay predicciones, afirmaciones causales ni correlaciones externas. Cada una de estas opciones habría ampliado el alcance y, en algunos casos, debilitado la integridad del sistema.
Un diseño visual tranquilo
El diseño sencillo y limpio, sin ilustraciones y con un uso contenido del color, es intencionado.
Las personas que experimentan dolor o migrañas pueden distraerse o sobreestimularse fácilmente con animaciones o con colores brillantes y muy saturados en la interfaz.
También evité deliberadamente utilizar naranja o rojo en las escalas de intensidad para no transmitir una sensación de error, urgencia o alarma. La intención de la web es acompañar e informar, no diagnosticar ni alarmar.
Feedback de los usuarios
Audiencia
El producto está dirigido a personas que experimentan dolor, independientemente de su edad. Esto quedó más claro durante ocho semanas de pruebas beta.
Insight principal
El informe para el médico fue la funcionalidad adicional más solicitada, lo que validó la necesidad de facilitar la comunicación médica, no solo el autorregistro.
Últimos 30 días
Al principio, el periodo de tiempo adecuado para los usuarios era una pregunta abierta. Treinta días parecen ser suficientes para obtener las señales que necesitan.
Puedo ir al médico y enseñarle exactamente lo que ocurrió.
Por qué importa este trabajo
Aunque se trata de un producto de salud B2C, los problemas que explora son los mismos en los que trabajo en sistemas de analítica impulsados por IA: cuándo pedir información al usuario, cómo hacerlo y cuándo mostrar resultados, manteniendo su confianza a lo largo de todo el recorrido.
Lo que aprendí con este trabajo
La implementación reveló limitaciones arquitectónicas que dieron forma al modelo episódico.
Distintos problemas requerían estructuras de sistema diferentes. Forzar la consistencia reducía la claridad.
Diseñado e implementado end-to-end, con un enfoque mobile-first, y utilizando desarrollo frontend asistido por IA para validar el sistema en la práctica.
Si un insight no se ha ganado, no se muestra.