De un prototipo funcional a una app de salud usable: qué aporta una UX especializada
12/10/2026
El registro funciona, los formularios guardan los datos, las notificaciones llegan y el equipo puede completar de principio a fin todos los recorridos previstos. Desde un punto de vista técnico, la primera versión de la aplicación está funcionando.
La percepción puede cambiar en cuanto la utiliza alguien que no participó en el proyecto. Un paciente tarda demasiado en encontrar una opción, interpreta de forma distinta una instrucción o abandona un cuestionario porque no sabe cuánto le queda. Un profesional necesita varios clics para llegar al dato que busca o tiene que salir de su flujo habitual para utilizar la herramienta.
Ese es el espacio que debe cubrir una buena validación UX en salud. No consiste en comprobar si la aplicación es bonita ni en pedir a un grupo de usuarios si “les gusta”. Consiste en comprobar si las personas para las que se ha diseñado pueden utilizarla correctamente, comprender qué está ocurriendo y completar las tareas importantes dentro de situaciones suficientemente próximas a la realidad. Es el paso posterior a los principios generales de diseño UX/UI para aplicaciones médicas: no solo diseñar bien, sino demostrar que la solución funciona para sus usuarios.
Una primera versión puede demostrar que una idea es técnicamente viable. La UX especializada permite averiguar si esa misma idea está preparada para convertirse en producto.
Hay una diferencia importante entre comprobar que una funcionalidad existe y comprobar que puede utilizarse correctamente.
El equipo técnico puede verificar que un botón ejecuta una acción, que un formulario almacena la información o que una alerta aparece cuando corresponde. La validación UX añade otra capa: observa si el usuario identifica ese botón, comprende qué información debe introducir y entiende correctamente el significado de la alerta.
Validación funcional
Validación UX
El botón ejecuta la acción
El usuario comprende qué ocurrirá al pulsarlo
El formulario guarda los datos
El usuario sabe qué dato se le está pidiendo
El flujo puede completarse
La persona puede completarlo sin ayuda
El mensaje de error aparece
El usuario entiende qué ha ocurrido y cómo continuar
La información está disponible
El profesional puede encontrarla cuando la necesita
La pantalla funciona en móvil
La interacción sigue siendo comprensible en el contexto real
La lógica implementada es correcta
El recorrido tiene sentido para el usuario
Esta diferencia es especialmente relevante en salud porque determinados errores de interacción pueden ir más allá de una simple molestia. Dependiendo de la finalidad del producto, una mala interpretación puede provocar que se introduzca información incorrecta, que no se complete una tarea importante o que una advertencia se entienda de una forma distinta a la prevista.
Esto no significa que cualquier app de salud tenga las mismas obligaciones que un producto sanitario regulado. Sí significa que, cuanto mayor sea la consecuencia de un error de uso, menos sentido tiene tratar la usabilidad como un ajuste visual de última hora. Si existen dudas sobre la consideración del software, conviene revisar desde fases tempranas aspectos como la regulación del software médico y las apps sanitarias y, cuando corresponda, los requisitos asociados al Marcado CE en software sanitario y apps médicas.
La primera dificultad: el equipo conoce demasiado bien el producto
Después de meses trabajando sobre una aplicación, el equipo sabe dónde está cada funcionalidad, entiende la terminología y conoce el recorrido correcto. Ese conocimiento hace que las pruebas internas sean necesarias, pero insuficientes para validar la experiencia.
Un usuario nuevo no dispone de ese contexto. Tampoco debería necesitarlo.
Imaginemos una app de seguimiento postoperatorio que solicita al paciente registrar dolor, movilidad y determinados síntomas. El equipo conoce perfectamente qué significa cada escala, pero durante una prueba descubrimos que varios pacientes interpretan “dolor actual” como “máximo dolor sufrido durante el día”. La aplicación está guardando los datos correctamente, aunque la información obtenida no representa aquello que creíamos estar preguntando.
En productos de seguimiento, este tipo de problema afecta incluso a la calidad del dato. Como vimos al analizar la monitorización remota de pacientes, no basta con capturar información: hay que asegurarse de que el dato tiene el contexto y la calidad necesarios para ser útil.
Ese tipo de hallazgo explica por qué las pruebas con usuarios en salud aportan información difícil de obtener únicamente revisando pantallas. El objetivo no es que el usuario confirme nuestras decisiones, sino descubrir dónde nuestras decisiones no coinciden con su forma de entender la tarea.
En salud no existe “el usuario”
Otra fuente habitual de problemas aparece cuando diseñamos una experiencia genérica para perfiles que en realidad tienen objetivos muy distintos.
El paciente puede necesitar saber qué tiene que hacer hoy y recibir confirmación de que lo ha hecho correctamente. Un médico quizá necesite detectar una excepción en pocos segundos. Enfermería puede gestionar tareas pendientes para decenas de pacientes, mientras que administración trabaja con estados, autorizaciones o citas.
Incluso una misma persona puede necesitar experiencias diferentes según el contexto. No interactúa igual con una aplicación alguien que consulta tranquilamente información preventiva que quien acaba de recibir un diagnóstico, se encuentra con dolor o trata de completar una tarea desde casa después de una intervención.
Esta diversidad de perfiles también explica por qué la accesibilidad de las aplicaciones móviles debe considerarse desde el diseño y no como una comprobación final. Una interfaz que funciona correctamente para un perfil digital avanzado puede presentar barreras importantes para otros usuarios.
Por eso una validación útil debe partir de tres variables:
Quién realiza la tarea.
Qué necesita conseguir.
En qué contexto intenta hacerlo.
El diseño centrado en el paciente no consiste únicamente en preguntar qué quiere el paciente. Consiste en comprender sus objetivos, capacidades, limitaciones y contexto para comprobar después si el producto responde a ellos.
Validar UX no es preguntar “¿te gusta?”
Una prueba de usabilidad pierde gran parte de su valor si enseñamos el producto, explicamos cómo funciona y después preguntamos al participante si le resulta sencillo.
Es más útil plantear una situación concreta:
“Has recibido una notificación para completar el seguimiento de hoy. Quieres comunicar que desde ayer tienes más molestias. Enséñame cómo lo harías.”
Después observamos dónde pulsa primero, si duda, si interpreta correctamente las opciones, si necesita regresar a otra pantalla o si sabe con seguridad que terminó la tarea.
La diferencia es importante porque la opinión y el comportamiento no siempre coinciden. Una persona puede afirmar que una aplicación le parece sencilla y haber necesitado ayuda tres veces para completar una tarea.
Esta forma de trabajar conecta directamente con el diseño de aplicaciones a medida basado en Design Thinking: comprender el problema, formular hipótesis, prototipar y validar antes de asumir que la primera solución es la correcta.
Una buena validación combina, por tanto, lo que el usuario hace, lo que entiende y lo que explica después de hacerlo.
Un marco práctico para validar una primera versión
No todas las pantallas necesitan recibir el mismo nivel de atención. Una forma más eficiente de trabajar consiste en empezar por las tareas que determinan si el producto puede cumplir realmente su objetivo.
1. Identificar las tareas críticas
Antes de reclutar usuarios conviene definir qué acciones queremos validar. En una app de seguimiento podrían ser registrarse correctamente, enviar un cuestionario, comunicar un síntoma, interpretar una alerta y localizar instrucciones.
Para cada tarea deberíamos poder explicar qué significa completarla con éxito y qué errores consideramos especialmente relevantes.
2. Elegir usuarios representativos
No necesitamos reproducir toda la población en cada iteración, pero sí evitar probar únicamente con compañeros, perfiles digitales avanzados o personas que ya conocen el producto.
Si la solución será utilizada por pacientes mayores, profesionales bajo presión asistencial o cuidadores, esas condiciones deberían formar parte de la estrategia de validación.
3. Crear escenarios, no instrucciones
Una prueba útil describe el objetivo, no la secuencia de clics. En lugar de decir “entra en seguimiento y pulsa registrar síntoma”, planteamos la necesidad y observamos qué recorrido construye el usuario.
4. Medir y observar
Las notas cualitativas son importantes, pero conviene complementarlas con información objetiva: cuántas personas completan una tarea, cuánto tardan, cuántas necesitan ayuda o en qué pasos se producen errores.
5. Priorizar los hallazgos
No todos los problemas detectados deben corregirse con la misma urgencia. Un icono ligeramente confuso no tiene el mismo peso que una interacción que provoca que varios pacientes envíen información equivocada.
Podemos priorizar cada hallazgo considerando cuatro factores:
Criterio
Pregunta
Frecuencia
¿Cuántos usuarios encuentran el problema?
Impacto
¿Impide o dificulta completar la tarea?
Recuperación
¿Puede el usuario darse cuenta y corregirse?
Riesgo
¿Qué consecuencia puede tener el error?
Esto convierte la investigación UX en una herramienta para decidir el roadmap, no en una lista interminable de observaciones. Es también coherente con la metodología de trabajo de GooApps®, donde descubrimiento, definición y validación preceden a la construcción del producto definitivo.
Qué métricas merece la pena recoger
No necesitamos convertir una sesión de usabilidad en un experimento estadístico complejo. Sí conviene establecer algunas medidas comunes que permitan comparar iteraciones.
Éxito de tarea. Qué porcentaje de participantes completa correctamente la acción sin intervención.
Errores. Qué errores aparecen y cuáles se repiten entre distintos usuarios.
Necesidad de ayuda. Cuántas veces el moderador debe intervenir para que la persona continúe.
Tiempo de ejecución. Puede revelar recorridos innecesariamente complejos, aunque un tiempo menor no siempre sea el objetivo principal.
Comprensión. Especialmente relevante cuando el usuario debe interpretar instrucciones, resultados, permisos o alertas.
Confianza. En determinadas tareas interesa comprobar si, después de completarlas, la persona sabe con seguridad qué ha ocurrido.
Estas métricas tienen más valor cuando se conectan con tareas concretas que cuando se utilizan para generar una puntuación global de “buena UX”. Una vez publicado el producto, pueden complementarse con analítica de las interacciones dentro de la app para descubrir abandonos o recorridos problemáticos a mayor escala.
La accesibilidad también debe probarse
La accesibilidad no debería aparecer cuando el diseño ya está terminado. En salud podemos estar trabajando precisamente con poblaciones donde las dificultades visuales, motoras, cognitivas o de alfabetización digital son más frecuentes.
Los criterios técnicos son importantes, pero tampoco sustituyen a observar el uso. Una interfaz puede superar determinadas comprobaciones automáticas y seguir utilizando un lenguaje demasiado complejo para su población objetivo.
Conviene pensar en accesibilidad como una combinación de requisitos técnicos y experiencia real: contraste, tamaño de controles, navegación, jerarquía, lenguaje, mensajes de error y alternativas para distintas capacidades. El trabajo desarrollado por GooApps® junto a Fundación ONCE en torno a la accesibilidad de aplicaciones móviles muestra precisamente por qué estos criterios deben incorporarse al producto desde etapas tempranas.
Del hallazgo a la decisión de producto
Uno de los mayores desperdicios en investigación UX ocurre cuando se realizan pruebas, se documentan problemas y el informe acaba almacenado sin modificar el producto.
Cada hallazgo relevante debería provocar una decisión. A veces será cambiar una pantalla; otras veces descubriremos que sobra una funcionalidad, que necesitamos pedir un dato en otro momento o que estamos intentando resolver con interfaz un problema que en realidad pertenece al proceso.
Este es uno de los mayores valores de validar antes de seguir desarrollando: permite decidir qué no merece la pena construir.
La experiencia de Oncologym, la app de fitness, nutrición y coaching para pacientes oncológicos ilustra bien esta metodología. GooApps® trabajó arquitectura de información, user journeys, wireframes, prototipos y validación antes de consolidar el producto, permitiendo depurar funcionalidades antes de que los cambios resultaran más costosos.
Qué ocurre si el prototipo se ha creado con IA o no-code
La procedencia del prototipo no cambia el objetivo de la validación.
Una primera versión creada con ChatGPT, Claude, herramientas no-code o un equipo tradicional puede servir perfectamente para probar recorridos y tareas. De hecho, la reducción del coste de prototipado permite contrastar determinadas hipótesis mucho antes.
Una IA puede generar una pantalla coherente con patrones comunes de diseño, pero no sabe por sí misma si la terminología es adecuada para tus pacientes, si el profesional encuentra el dato a tiempo o si un mensaje se interpreta correctamente dentro de un proceso asistencial concreto.
Por eso el prototipado rápido y la validación deberían reforzarse mutuamente: cuanto más barato es cambiar una primera versión, más sentido tiene probar antes de consolidarla.
¿Ya tienes una primera versión de tu app de salud?
Las pruebas con usuarios no desaparecen cuando publicamos la aplicación. A partir de ese momento aparecen datos de comportamiento que permiten comprobar si los problemas observados en sesiones controladas también existen a escala.
Podemos analizar abandonos, repeticiones, errores, solicitudes de ayuda y tiempos de ejecución. Después, cuando aparece un patrón, volvemos a investigación cualitativa para entender qué lo está provocando.
Esta combinación evita dos errores frecuentes: rediseñar basándonos únicamente en opiniones individuales o interpretar analítica sin comprender el motivo del comportamiento.
La validación UX funciona mejor como un ciclo: hipótesis → prototipo → prueba → hallazgo → cambio → medición → nueva hipótesis. No como una aprobación única antes del lanzamiento.
Una app no está validada porque funcione
La velocidad con la que hoy podemos construir una primera versión hace que sea fácil confundir progreso técnico con progreso de producto. Una aplicación puede tener todos sus componentes funcionando y seguir necesitando cambios importantes antes de enfrentarse a pacientes y profesionales reales.
La validación UX en salud permite encontrar esos problemas cuando todavía podemos corregirlos con criterio. No se trata de multiplicar sesiones de investigación ni de perseguir una interfaz perfecta, sino de comprobar que las personas pueden completar las tareas que justifican la existencia del producto.
Si el proyecto se encuentra todavía en una fase más temprana, nuestra guía sobre cómo desarrollar una app de salud explica cómo encajan definición, diseño, desarrollo y validación dentro del proceso completo. En GooApps® combinamos esa visión de producto con UX/UI y especialización sanitaria para convertir primeras versiones en soluciones preparadas para contextos reales.
¿Tu aplicación funciona, pero todavía no sabes cómo responderán los usuarios reales?
¿Cuántos usuarios necesito para una prueba de usabilidad?
Depende del número de perfiles, tareas y riesgos que queramos estudiar. En fases iterativas suele resultar más útil probar con grupos pequeños, corregir los principales problemas y repetir que acumular decenas de usuarios sobre una versión que sabemos que tiene errores. Si existe una finalidad regulada, el plan de validación deberá adaptarse además a los requisitos específicos del producto.
¿Puedo realizar pruebas UX de forma remota?
Sí, siempre que el tipo de tarea y el contexto lo permitan. Las sesiones remotas pueden facilitar el acceso a determinados perfiles y permitir observar al usuario utilizando su propio dispositivo. Para tareas donde el entorno físico, un dispositivo médico o la interacción con otros profesionales sea importante puede resultar necesario complementar con pruebas presenciales.
¿Hay que pagar o compensar a los participantes?
Depende del proyecto y del tipo de usuario, pero conviene valorar el tiempo y esfuerzo que se solicita. En perfiles difíciles de reclutar, una compensación adecuada puede facilitar una muestra más representativa. En entornos sanitarios deben respetarse además los procedimientos éticos y organizativos que correspondan.
¿Cómo sé cuándo una versión está suficientemente validada?
No existe un punto en el que desaparezca cualquier problema. La decisión debería basarse en si las tareas críticas pueden completarse con el nivel de éxito previsto, si los errores de mayor impacto están controlados y si los riesgos residuales resultan aceptables para el uso planteado.
¿La validación UX sustituye a una validación clínica o regulatoria?
No. Son ámbitos diferentes. La UX permite evaluar interacción, comprensión y uso; una validación clínica evalúa otras cuestiones relacionadas con desempeño o resultados, y los requisitos regulatorios dependerán de la finalidad y clasificación del producto.
+34 675 549 894
Agenda tu llamada virtual 
