Galenus AI
Investigación de campo en El Salvador para un asistente médico con IA. El problema no era el modelo: era que sus reportes no se parecían a los que el hospital ya usaba.
Sector
Salud digital · IA
Rol
UX Researcher
Periodo
2022 – 2024
Equipo
Distribuido en tres países
Herramientas
Adobe XD, Figma, Excel
Lectura
6 min
En resumen
El equipo desarrollaba un motor de IA capaz de generar reportes médicos. El problema no era técnico: era que esos reportes no encajaban con el formato que los hospitales ya usaban.
Analicé los focus groups y las pruebas de usabilidad grabadas en campo con personal sanitario: transcribí y codifiqué las sesiones rastreando fricciones pantalla por pantalla.
El análisis identificó pantallas con tasas de fallo cercanas al 100% y produjo un informe desglosado en diseño, contenido y funcionalidad técnica.
Después diseñé un plan de investigación etnográfica en atención primaria para entender cómo se recogen realmente los datos del paciente en consulta. Quedó completo, pero su ejecución seguía pendiente cuando dejé el proyecto.
01
El problema
Un motor de IA que genera reportes médicos correctos puede ser inservible si los reportes no se parecen a los que el hospital ya usa. Un médico con siete minutos por paciente no adapta su flujo de trabajo a un formato nuevo: abandona la herramienta.
El equipo técnico trabajaba en el motor y hacía ingeniería inversa del formato real de los reportes en los hospitales salvadoreños. Mi papel fue el otro lado de esa ecuación: entender el trabajo clínico real en el que ese motor tenía que insertarse.
¿Cómo se recoge hoy la información del paciente, quién la recoge, y con qué herramientas?
La pregunta anterior a cualquier pregunta de interfaz.
El proyecto se repartía entre tres países: el equipo de producto y desarrollo en República Dominicana, una empresa asociada en México que aportaba asesoría y desarrollaba parte de la aplicación, y en El Salvador los asesores y médicos que conocían el sistema de salud donde el producto tenía que funcionar. Esa distribución explica buena parte del problema: quienes construían la herramienta y quienes iban a usarla no compartían ni país ni contexto clínico.
02
Trabajo de campo
Dirigí sesiones presenciales con personal sanitario en El Salvador, grabadas para su análisis posterior. El objeto de prueba fue la aplicación del lado del paciente.
El análisis no se quedó en observaciones generales. Transcribí y codifiqué las grabaciones rastreando el comportamiento pantalla por pantalla, y organicé los resultados en una matriz de fricciones por flujo.
El análisis de las sesiones con médicos. Codificar el material es lo que convierte una grabación en una lista de prioridades.
Tasas de fallo por pantalla
Flujo | Pantalla crítica | Tasa de fallo |
|---|---|---|
Recetas | Información de receta | ~100% |
Perfil | Navegación a perfil | ~100% |
Registro | Fecha de nacimiento | ~85% |
Registro | Alta y onboarding | ~70% |
Citas | Navegación de citas | >75% |
Agenda | — | ~30% |
La conclusión operativa fue de priorización: recetas, perfil y registro concentraban los fallos más severos y debían atenderse primero. El flujo de citas, en cambio, tenía una sola pantalla causando confusión extrema mientras el resto funcionaba — el arreglo más barato con mayor retorno.
03
De hallazgos a decisiones
El informe de recomendaciones no se quedó en «esta pantalla confunde». Cada problema se desglosó en tres capas accionables, cada una dirigida a un responsable distinto.
Fecha de nacimiento · ~85% de fallo
Diseño: sustituir el teclado numérico por un selector de fecha, para eliminar los problemas de formato con las barras.
Contenido: si se mantiene la entrada manual, indicar el formato justo encima del campo.
Técnico: autoformatear a medida que el usuario escribe.
Información de receta · ~100% de fallo
Diseño: señales visuales que distingan estados y acciones de cada receta, y separar claramente la receta del acceso a la farmacia.
Contenido: lenguaje simple para los estados, con glosario para términos desconocidos.
Técnico: integrar un localizador de farmacias con pasos claros para obtener el medicamento.
Onboarding de registro · ~70% de fallo
Diseño: sacar las preguntas no esenciales del alta inicial y moverlas al perfil.
Contenido: fragmentar la información en secciones completables a lo largo del tiempo.
Técnico: permitir elegir unidades de peso y talla, y restringir la entrada a rangos válidos.
Por qué esta estructura. Un informe que solo dice «hay confusión» deja el trabajo a medias. Separar diseño, contenido y funcionalidad técnica permite que cada especialidad recoja su parte sin negociación previa, y hace que los hallazgos sobrevivan a la reunión donde se presentan.
04
Investigación etnográfica en atención primaria
Diseñé después un estudio cualitativo etnográfico para responder la pregunta de fondo, con hipótesis explícitas y falsables. Por ejemplo: «los médicos son los principales recolectores de información del paciente, no el personal asistente». Planteada así, la investigación podía desmentirla.
El plan combinaba tres técnicas —observación participante en consultas reales, entrevistas semiestructuradas a médicos, enfermeras, secretarias y pacientes, y análisis documental de formularios y registros— con consideraciones éticas de consentimiento informado, anonimato y no interferencia en la consulta.
Los riesgos se declararon desde el inicio: acceso a información sensible bajo normativa de privacidad médica, efecto del observador, barreras culturales y variabilidad de herramientas entre centros.
El estudio no llegó a ejecutarse mientras estuve en el proyecto. El plan quedó completo y listo, pero la ejecución se fue retrasando por otras prioridades del proyecto y seguía pendiente cuando me marché. Lo incluyo porque diseñar el estudio —hipótesis falsables, técnicas combinadas, marco ético y riesgos declarados— fue trabajo real, aunque el trabajo de campo quedara por delante.
Dos usuarios con necesidades, tiempos y presiones distintas sobre el mismo sistema. Diseñar un único recorrido habría fallado para ambos.
05
Resultados
La investigación aportó una priorización basada en datos de qué flujos arreglar primero —con tasas de fallo por pantalla en lugar de opiniones—, un informe accionable desglosado por disciplina, y user journeys diferenciados de médico y paciente. El plan etnográfico quedó documentado y listo para ejecutarse.
Lo que no puedo afirmar. No dispongo de datos de adopción ni de mejora medida tras implementar las recomendaciones. Este caso no incluye ninguna cifra de impacto posterior.
06
Aprendizajes
El problema estaba en el formato, no en el modelo. El motor funcionaba. Lo que fallaba era que sus reportes no se parecían a los que el hospital ya usaba. En productos de IA aplicada, el ajuste al flujo de trabajo existente pesa más que la calidad del modelo — y eso solo se descubre yendo al lugar donde se trabaja.
Codificar pantalla por pantalla convierte observaciones en prioridades. Una sesión grabada produce impresiones; una matriz de fricciones produce un orden de trabajo.
Un mal resultado bien localizado vale más que uno bueno y difuso. Descubrir que el flujo de citas tenía una sola pantalla rompiendo la experiencia fue más útil que cualquier hallazgo positivo.
Investigar en otro país obliga a separar lo cultural de lo universal. Un flujo que funciona en un sistema de salud no se traslada sin ajuste a otro.