Prototipar antes de construir en salud
no es una buena práctica, es una responsabilidad
Cuando el software media decisiones clínicas, cada supuesto no validado es un riesgo para alguien.
¿Qué ocurre cuando un equipo de salud digital salta del requerimiento al desarrollo sin validar con personas reales?
Una revisión publicada en el Journal of Medical Internet Research (Kidman et al., 2024) ofrece una respuesta concreta: el 70% de los usuarios abandona las apps de salud dentro de los primeros 100 días. Las causas incluyen desajuste con necesidades reales, problemas funcionales y pérdida de confianza. Cada una de esas causas representa un supuesto que podría haberse validado antes de escribir una sola línea de código.
Este artículo aborda la pregunta siguiente: ¿cuál es el instrumento concreto para evitar esos errores? La respuesta es el prototipado.
Verificar no es validar
En ingeniería de software sanitario existe una distinción crítica que muchos equipos pasan por alto. La verificación responde a la pregunta “¿lo construimos bien?”: confirma que el sistema cumple sus especificaciones técnicas. La validación responde a una pregunta distinta: “¿construimos lo correcto?”. Es decir, ¿el sistema resuelve el problema real para el cual fue diseñado?
Un software puede pasar todas las pruebas técnicas y aun así ser inútil en la práctica clínica, porque la información no se interpreta como se esperaba, porque el flujo no coincide con el flujo de trabajo real, o porque las decisiones que exige el sistema no tienen sentido para quien lo utiliza. El prototipado permite abordar la pregunta de validación antes de que el costo de cambiar sea incomparable con el costo de haber preguntado a tiempo.
Lo que la regulación ya exige (y muchos equipos aún no aplican)
El desarrollo de software médico está sujeto a marcos regulatorios que exigen procesos formales de diseño, validación y control de cambios. En Chile, la Guía de Buenas Prácticas de Fabricación de Dispositivos Médicos del ISP (2025) establece que las entradas de diseño deben incluir requisitos de funcionamiento, desempeño, usabilidad y seguridad según el uso previsto. La validación de diseño debe garantizar que el dispositivo responda a las necesidades del usuario e incluir ensayos en condiciones reales o simuladas de uso.
En otras palabras, el marco normativo ya contempla que validar con usuarios no es opcional. Lo que falta, en muchos casos, es el instrumento para hacerlo antes de comprometer recursos de desarrollo. El prototipo cumple exactamente esa función: permite poner a prueba si la solución funciona para personas reales antes de escribir código.
La fidelidad que importa no es la visual
Existe la creencia de que un prototipo necesita verse terminado para ser útil. Pero la fidelidad de un prototipo no está vinculada a su acabado gráfico, sino a su capacidad de representar fielmente las interacciones que se van a probar. Un wireframe en papel que simula un flujo clínico completo puede entregar más información que una interfaz pulida que no permite al usuario completar una tarea real.
En fases tempranas, prototipos de baja fidelidad visual pero alta fidelidad de interacción permiten capturar hallazgos críticos sin el costo del desarrollo. En fases más avanzadas, prototipos funcionales permiten validar integraciones, flujos de datos y experiencias completas. Lo importante no es el nivel de acabado, sino la pregunta que el prototipo intenta responder: ¿la información se interpreta correctamente? ¿El flujo coincide con el flujo de trabajo real? ¿Las decisiones que exige el sistema tienen sentido para quien lo utiliza?
El prototipo como mecanismo de seguridad
En salud, los usuarios interactúan con los sistemas bajo presión de tiempo, interrupciones, estrés y sobrecarga cognitiva. Cuando una interfaz no coincide con el modelo mental del usuario, el riesgo no es solo abandono, puede ser daño para alguien. Un prototipo evaluado en condiciones que simulen esos escenarios permite identificar puntos de falla antes de que lleguen a producción. Porque un profesional clínico que no confía en la información que le entrega una plataforma, simplemente no la va a usar. Y esa confianza solo se descubre trabajando directamente con las personas.
Cuando la tecnología media en decisiones que afectan la vida de las personas, construir sin prototipar no es avanzar más rápido, es avanzar con demasiada incertidumbre. Nunca más diseñar para los usuarios, sin los usuarios.
En fases tempranas, prototipos de baja fidelidad visual pero alta fidelidad de interacción permiten capturar hallazgos críticos sin el costo del desarrollo. En fases más avanzadas, prototipos funcionales permiten validar integraciones, flujos de datos y experiencias completas. Lo importante no es el nivel de acabado, sino la pregunta que el prototipo intenta responder: ¿la información se interpreta correctamente? ¿El flujo coincide con el flujo de trabajo real? ¿Las decisiones que exige el sistema tienen sentido para quien lo utiliza?
Rebeca Reinoso
Ingeniera en Diseño de Productos
Ingeniera en Diseño de Productos
Fuentes
Kidman, P.G., Curtis, R.G., Watson, A., & Maher, C.A. (2024). When and Why Adults Abandon Lifestyle Behavior and Mental Health Mobile Apps: Scoping Review. Journal of Medical Internet Research, 26, e56897. Instituto de Salud Pública de Chile (2025). Guía de Buenas Prácticas de Fabricación de Dispositivos Médicos, incluidos los DMDIV. Versión 2. NCh ISO 13485:2017. Dispositivos Médicos — Sistema de Gestión de Calidad — Requisitos para fines regulatorios.
Kidman, P.G., Curtis, R.G., Watson, A., & Maher, C.A. (2024). When and Why Adults Abandon Lifestyle Behavior and Mental Health Mobile Apps: Scoping Review. Journal of Medical Internet Research, 26, e56897. Instituto de Salud Pública de Chile (2025). Guía de Buenas Prácticas de Fabricación de Dispositivos Médicos, incluidos los DMDIV. Versión 2. NCh ISO 13485:2017. Dispositivos Médicos — Sistema de Gestión de Calidad — Requisitos para fines regulatorios.
CONTÁCTANOS