UI / UX Design
Colmena: Salud digital en tiempos de pandemia
Cómo diseñamos desde cero la experiencia digital de una isapre durante la pandemia, sobre una base técnica rota, con stakeholders no digitales y para usuarios que nunca habían usado una app de salud.
Year :
2020-2021
Industry :
Salud — Isapre
Client :
Isapre Colmena
Rol :
UX/UI
Contexto
Pandemia COVID-19. Las sucursales presenciales de Colmena colapsaron. Los usuarios necesitaban gestionar bonos, reembolsos y servicios de salud desde casa. El problema: la app que existía no funcionaba.
Colmena tenía una app. La habían construido desarrolladores sin experiencia en diseño de producto y sin participación de UX. El resultado era una interfaz donde los flujos más críticos, comprar un bono y solicitar un reembolso, estaban rotos o eran tan confusos que nadie los completaba. La app existía pero no servía.
Cuando llegó la pandemia y las sucursales tuvieron que reducir su operación, esa realidad se volvió urgente. Fui parte del equipo convocado para diseñar la experiencia digital real: no parchear lo que había, sino construir los flujos correctos desde cero, dentro de las restricciones técnicas existentes.
Lo que encontramos al llegar
El diagnóstico inicial fue claro. Había una app instalada en los teléfonos de los afiliados, pero funcionaba como una barrera más que como una solución.
Estado inicial | Lo que construimos |
|---|---|
Flujo de compra de bonos incompleto. Los usuarios llegaban a la mitad y no podían continuar. | Flujo de compra de bonos end-to-end, con resumen de costos visible desde el inicio. |
Reembolsos sin flujo funcional. Solo era posible gestionarlos presencialmente. | Flujo de reembolso digital funcional por primera vez en la historia del producto. |
Navegación construida por developers sin criterio de UX. Sin jerarquía ni lógica de tareas. | Arquitectura de navegación rediseñada centrada en las 3 tareas más frecuentes. |
Lenguaje técnico de seguros incomprensible para el usuario promedio. | Lenguaje cotidiano en toda la interfaz. Cero jerga de seguros. |
40% de abandono en los primeros 3 minutos de sesión. | +35% de sesiones activas completadas en los primeros 3 meses. |
Los desafíos reales
No había diseño que heredar. Todo partía de cero en términos de UX, pero dentro de una base técnica ya construida en Ionic que no podíamos cambiar. El diseño tenía que adaptarse a lo que el framework permitía. |
Los usuarios finales eran adultos mayores o personas con baja familiaridad digital. Diseñar para alguien que nunca ha usado una app de salud es radicalmente diferente a diseñar para un usuario tech. |
Los stakeholders eran ejecutivos de salud y negocio, sin experiencia digital. Aprobar cada decisión de diseño requería primero educar sobre qué era lo que se estaba aprobando. |
El tiempo era crítico. La pandemia no esperaba. Cada semana de retraso era una semana más de sucursales saturadas y usuarios sin atención digital. |
El desafío invisible: los stakeholders
Una parte del trabajo que no aparece en los wireframes fue aprender a trabajar con tomadores de decisión que no tenían referencia digital. Los ejecutivos de Colmena eran profesionales de salud y negocio con décadas de experiencia en su industria, pero sin contexto para evaluar un flujo de UX.
Diseñar para usuarios no digitales y convencer a stakeholders no digitales al mismo tiempo fue el reto más complejo del proyecto.
Usuario final Afiliado Colmena | Cliente interno Ejecutivos Colmena | Equipo técnico Desarrollo Ionic |
|---|---|---|
Adulto de 40 a 65 años. Bajo manejo digital. Necesita resolver trámites de salud sin ir a una sucursal durante la pandemia. | Tomadores de decisión sin background digital. Aprobaban o rechazaban propuestas basándose en intuición de negocio, no en criterios de UX. | Framework híbrido con restricciones visuales reales. El diseño tenía que funcionar dentro de lo que Ionic permitía implementar. |
Resultados
+35%Aumento de sesiones activas | +18%Adopción del canal digital | −12%Visitas presenciales a sucursales |
|---|
Mi proceso
Auditoría de lo existente
Lo primero fue entender exactamente qué estaba roto y por qué. Mapeé todos los flujos existentes, identifiqué en qué pasos se caían los usuarios y cuáles eran técnicamente no funcionales. Eso nos dio una lista clara de prioridades: los flujos de bono y reembolso eran los más críticos y los más rotos. Por ahí empezamos.
Research con usuarios reales
Hicimos entrevistas y tests de usabilidad con afiliados. El hallazgo más importante fue que los usuarios no abandonaban por pereza, sino por miedo a equivocarse. "No sé si estoy haciendo bien esto" era la frase que más se repetía. Eso cambió el enfoque del diseño: el objetivo principal pasó a ser reducir la ansiedad, no solo la fricción.
Diseño de flujos críticos desde cero
Construí el flujo de compra de bonos y el de reembolso completos en Figma. El principio guía fue mostrar el resumen de costos al inicio, no al final. Simplifiqué el lenguaje: fuera los términos técnicos de seguros de salud, adentro lenguaje cotidiano. Cada pantalla tenía una sola acción posible para no abrumar a un usuario que ya llegaba con ansiedad.
Diseño dentro de las limitaciones de Ionic
onic tenía restricciones visuales reales. No todo lo que diseñaba era implementable sin costo técnico alto. Aprendí a trabajar con el equipo de desarrollo desde el inicio de cada flujo para diseñar dentro de lo posible. Algunas propuestas las simplifiqué, otras las adapté. El resultado no era el UI más pulido del mundo, pero era funcional y usable, que era lo que importaba en ese momento.
Gestión de stakeholders no digitales
Los prototipos interactivos no eran suficientes para convencer a los ejecutivos. Necesitaban ver el problema en su propio lenguaje. Empecé a presentar con datos de sucursales: "Este flujo genera X llamadas de soporte por semana. Si lo resolvemos digitalmente, ese número baja y las sucursales se descongestionan." Los números de negocio y el contexto de pandemia movieron las aprobaciones más que cualquier wireframe.
Testing y ajuste continuo
Hicimos rondas de testing antes de cada release. Con usuarios finales validamos que los flujos eran comprensibles sin explicación previa. Las iteraciones más importantes vinieron de observar a personas reales intentando comprar un bono por primera vez. Eso era imposible de simular en una reunión de stakeholders.
Decisiones de diseño clave
La decisión más impactante fue mostrar el resumen de costos al inicio del flujo de compra de bonos. Era contraintuitivo para los stakeholders. Argumenté con los datos de abandono que teníamos: la mayoría de los usuarios que llegaban al último paso y veían el costo por primera vez, abandonaban. Al poner el costo al frente el abandono bajó de forma significativa.
La segunda decisión fue simplificar el lenguaje de forma radical. Los textos originales usaban terminología de seguros que los usuarios no entendían. Reescribimos cada label, título y mensaje de error en lenguaje cotidiano. Ese cambio no requirió desarrollo adicional y tuvo impacto directo en la tasa de completación.
El UI no era perfecto. Pero era el primero que realmente funcionaba. Eso fue suficiente para cambiar el comportamiento de los usuarios.
Con Ionic aprendí a distinguir entre un límite técnico real y una resistencia al cambio del equipo de desarrollo. Algunas simplificaciones de diseño que parecían imposibles eran perfectamente implementables cuando las presentaba con el contexto correcto. Esa negociación constante entre lo ideal y lo posible fue uno de los aprendizajes más valiosos del proyecto.
Aprendizajes
Funcional primero, pulido después | El miedo es fricción |
|---|---|
El UI de Ionic no era el más bonito. Pero era el primero que permitía comprar un bono sin abandonar. En un contexto de pandemia, eso valía más que cualquier animación. | Los usuarios no abandonaban por pereza. Abandonaban por ansiedad. Diseñar para reducir el miedo a equivocarse fue más efectivo que simplificar los pasos. |
Habla el idioma del negocio | El lenguaje es UI |
Con stakeholders no digitales, los wireframes no convencen. Los datos de sucursales y el impacto operativo sí. Aprendí a traducir cada decisión de diseño a lenguaje de negocio. | Reescribir los textos en lenguaje cotidiano fue el cambio con mejor relación esfuerzo-impacto. Sin desarrollo adicional, mejoró la tasa de completación de forma inmediata. |
Más proyectos
UI / UX Design
Colmena: Salud digital en tiempos de pandemia
Cómo diseñamos desde cero la experiencia digital de una isapre durante la pandemia, sobre una base técnica rota, con stakeholders no digitales y para usuarios que nunca habían usado una app de salud.
Year :
2020-2021
Industry :
Salud — Isapre
Client :
Isapre Colmena
Rol :
UX/UI
Contexto
Pandemia COVID-19. Las sucursales presenciales de Colmena colapsaron. Los usuarios necesitaban gestionar bonos, reembolsos y servicios de salud desde casa. El problema: la app que existía no funcionaba.
Colmena tenía una app. La habían construido desarrolladores sin experiencia en diseño de producto y sin participación de UX. El resultado era una interfaz donde los flujos más críticos, comprar un bono y solicitar un reembolso, estaban rotos o eran tan confusos que nadie los completaba. La app existía pero no servía.
Cuando llegó la pandemia y las sucursales tuvieron que reducir su operación, esa realidad se volvió urgente. Fui parte del equipo convocado para diseñar la experiencia digital real: no parchear lo que había, sino construir los flujos correctos desde cero, dentro de las restricciones técnicas existentes.
Lo que encontramos al llegar
El diagnóstico inicial fue claro. Había una app instalada en los teléfonos de los afiliados, pero funcionaba como una barrera más que como una solución.
Estado inicial | Lo que construimos |
|---|---|
Flujo de compra de bonos incompleto. Los usuarios llegaban a la mitad y no podían continuar. | Flujo de compra de bonos end-to-end, con resumen de costos visible desde el inicio. |
Reembolsos sin flujo funcional. Solo era posible gestionarlos presencialmente. | Flujo de reembolso digital funcional por primera vez en la historia del producto. |
Navegación construida por developers sin criterio de UX. Sin jerarquía ni lógica de tareas. | Arquitectura de navegación rediseñada centrada en las 3 tareas más frecuentes. |
Lenguaje técnico de seguros incomprensible para el usuario promedio. | Lenguaje cotidiano en toda la interfaz. Cero jerga de seguros. |
40% de abandono en los primeros 3 minutos de sesión. | +35% de sesiones activas completadas en los primeros 3 meses. |
Los desafíos reales
No había diseño que heredar. Todo partía de cero en términos de UX, pero dentro de una base técnica ya construida en Ionic que no podíamos cambiar. El diseño tenía que adaptarse a lo que el framework permitía. |
Los usuarios finales eran adultos mayores o personas con baja familiaridad digital. Diseñar para alguien que nunca ha usado una app de salud es radicalmente diferente a diseñar para un usuario tech. |
Los stakeholders eran ejecutivos de salud y negocio, sin experiencia digital. Aprobar cada decisión de diseño requería primero educar sobre qué era lo que se estaba aprobando. |
El tiempo era crítico. La pandemia no esperaba. Cada semana de retraso era una semana más de sucursales saturadas y usuarios sin atención digital. |
El desafío invisible: los stakeholders
Una parte del trabajo que no aparece en los wireframes fue aprender a trabajar con tomadores de decisión que no tenían referencia digital. Los ejecutivos de Colmena eran profesionales de salud y negocio con décadas de experiencia en su industria, pero sin contexto para evaluar un flujo de UX.
Diseñar para usuarios no digitales y convencer a stakeholders no digitales al mismo tiempo fue el reto más complejo del proyecto.
Usuario final Afiliado Colmena | Cliente interno Ejecutivos Colmena | Equipo técnico Desarrollo Ionic |
|---|---|---|
Adulto de 40 a 65 años. Bajo manejo digital. Necesita resolver trámites de salud sin ir a una sucursal durante la pandemia. | Tomadores de decisión sin background digital. Aprobaban o rechazaban propuestas basándose en intuición de negocio, no en criterios de UX. | Framework híbrido con restricciones visuales reales. El diseño tenía que funcionar dentro de lo que Ionic permitía implementar. |
Resultados
+35%Aumento de sesiones activas | +18%Adopción del canal digital | −12%Visitas presenciales a sucursales |
|---|
Mi proceso
Auditoría de lo existente
Lo primero fue entender exactamente qué estaba roto y por qué. Mapeé todos los flujos existentes, identifiqué en qué pasos se caían los usuarios y cuáles eran técnicamente no funcionales. Eso nos dio una lista clara de prioridades: los flujos de bono y reembolso eran los más críticos y los más rotos. Por ahí empezamos.
Research con usuarios reales
Hicimos entrevistas y tests de usabilidad con afiliados. El hallazgo más importante fue que los usuarios no abandonaban por pereza, sino por miedo a equivocarse. "No sé si estoy haciendo bien esto" era la frase que más se repetía. Eso cambió el enfoque del diseño: el objetivo principal pasó a ser reducir la ansiedad, no solo la fricción.
Diseño de flujos críticos desde cero
Construí el flujo de compra de bonos y el de reembolso completos en Figma. El principio guía fue mostrar el resumen de costos al inicio, no al final. Simplifiqué el lenguaje: fuera los términos técnicos de seguros de salud, adentro lenguaje cotidiano. Cada pantalla tenía una sola acción posible para no abrumar a un usuario que ya llegaba con ansiedad.
Diseño dentro de las limitaciones de Ionic
onic tenía restricciones visuales reales. No todo lo que diseñaba era implementable sin costo técnico alto. Aprendí a trabajar con el equipo de desarrollo desde el inicio de cada flujo para diseñar dentro de lo posible. Algunas propuestas las simplifiqué, otras las adapté. El resultado no era el UI más pulido del mundo, pero era funcional y usable, que era lo que importaba en ese momento.
Gestión de stakeholders no digitales
Los prototipos interactivos no eran suficientes para convencer a los ejecutivos. Necesitaban ver el problema en su propio lenguaje. Empecé a presentar con datos de sucursales: "Este flujo genera X llamadas de soporte por semana. Si lo resolvemos digitalmente, ese número baja y las sucursales se descongestionan." Los números de negocio y el contexto de pandemia movieron las aprobaciones más que cualquier wireframe.
Testing y ajuste continuo
Hicimos rondas de testing antes de cada release. Con usuarios finales validamos que los flujos eran comprensibles sin explicación previa. Las iteraciones más importantes vinieron de observar a personas reales intentando comprar un bono por primera vez. Eso era imposible de simular en una reunión de stakeholders.
Decisiones de diseño clave
La decisión más impactante fue mostrar el resumen de costos al inicio del flujo de compra de bonos. Era contraintuitivo para los stakeholders. Argumenté con los datos de abandono que teníamos: la mayoría de los usuarios que llegaban al último paso y veían el costo por primera vez, abandonaban. Al poner el costo al frente el abandono bajó de forma significativa.
La segunda decisión fue simplificar el lenguaje de forma radical. Los textos originales usaban terminología de seguros que los usuarios no entendían. Reescribimos cada label, título y mensaje de error en lenguaje cotidiano. Ese cambio no requirió desarrollo adicional y tuvo impacto directo en la tasa de completación.
El UI no era perfecto. Pero era el primero que realmente funcionaba. Eso fue suficiente para cambiar el comportamiento de los usuarios.
Con Ionic aprendí a distinguir entre un límite técnico real y una resistencia al cambio del equipo de desarrollo. Algunas simplificaciones de diseño que parecían imposibles eran perfectamente implementables cuando las presentaba con el contexto correcto. Esa negociación constante entre lo ideal y lo posible fue uno de los aprendizajes más valiosos del proyecto.
Aprendizajes
Funcional primero, pulido después | El miedo es fricción |
|---|---|
El UI de Ionic no era el más bonito. Pero era el primero que permitía comprar un bono sin abandonar. En un contexto de pandemia, eso valía más que cualquier animación. | Los usuarios no abandonaban por pereza. Abandonaban por ansiedad. Diseñar para reducir el miedo a equivocarse fue más efectivo que simplificar los pasos. |
Habla el idioma del negocio | El lenguaje es UI |
Con stakeholders no digitales, los wireframes no convencen. Los datos de sucursales y el impacto operativo sí. Aprendí a traducir cada decisión de diseño a lenguaje de negocio. | Reescribir los textos en lenguaje cotidiano fue el cambio con mejor relación esfuerzo-impacto. Sin desarrollo adicional, mejoró la tasa de completación de forma inmediata. |
Más proyectos
UI / UX Design
Colmena: Salud digital en tiempos de pandemia
Cómo diseñamos desde cero la experiencia digital de una isapre durante la pandemia, sobre una base técnica rota, con stakeholders no digitales y para usuarios que nunca habían usado una app de salud.
Year :
2020-2021
Industry :
Salud — Isapre
Client :
Isapre Colmena
Rol :
UX/UI
Contexto
Pandemia COVID-19. Las sucursales presenciales de Colmena colapsaron. Los usuarios necesitaban gestionar bonos, reembolsos y servicios de salud desde casa. El problema: la app que existía no funcionaba.
Colmena tenía una app. La habían construido desarrolladores sin experiencia en diseño de producto y sin participación de UX. El resultado era una interfaz donde los flujos más críticos, comprar un bono y solicitar un reembolso, estaban rotos o eran tan confusos que nadie los completaba. La app existía pero no servía.
Cuando llegó la pandemia y las sucursales tuvieron que reducir su operación, esa realidad se volvió urgente. Fui parte del equipo convocado para diseñar la experiencia digital real: no parchear lo que había, sino construir los flujos correctos desde cero, dentro de las restricciones técnicas existentes.
Lo que encontramos al llegar
El diagnóstico inicial fue claro. Había una app instalada en los teléfonos de los afiliados, pero funcionaba como una barrera más que como una solución.
Estado inicial | Lo que construimos |
|---|---|
Flujo de compra de bonos incompleto. Los usuarios llegaban a la mitad y no podían continuar. | Flujo de compra de bonos end-to-end, con resumen de costos visible desde el inicio. |
Reembolsos sin flujo funcional. Solo era posible gestionarlos presencialmente. | Flujo de reembolso digital funcional por primera vez en la historia del producto. |
Navegación construida por developers sin criterio de UX. Sin jerarquía ni lógica de tareas. | Arquitectura de navegación rediseñada centrada en las 3 tareas más frecuentes. |
Lenguaje técnico de seguros incomprensible para el usuario promedio. | Lenguaje cotidiano en toda la interfaz. Cero jerga de seguros. |
40% de abandono en los primeros 3 minutos de sesión. | +35% de sesiones activas completadas en los primeros 3 meses. |
Los desafíos reales
No había diseño que heredar. Todo partía de cero en términos de UX, pero dentro de una base técnica ya construida en Ionic que no podíamos cambiar. El diseño tenía que adaptarse a lo que el framework permitía. |
Los usuarios finales eran adultos mayores o personas con baja familiaridad digital. Diseñar para alguien que nunca ha usado una app de salud es radicalmente diferente a diseñar para un usuario tech. |
Los stakeholders eran ejecutivos de salud y negocio, sin experiencia digital. Aprobar cada decisión de diseño requería primero educar sobre qué era lo que se estaba aprobando. |
El tiempo era crítico. La pandemia no esperaba. Cada semana de retraso era una semana más de sucursales saturadas y usuarios sin atención digital. |
El desafío invisible: los stakeholders
Una parte del trabajo que no aparece en los wireframes fue aprender a trabajar con tomadores de decisión que no tenían referencia digital. Los ejecutivos de Colmena eran profesionales de salud y negocio con décadas de experiencia en su industria, pero sin contexto para evaluar un flujo de UX.
Diseñar para usuarios no digitales y convencer a stakeholders no digitales al mismo tiempo fue el reto más complejo del proyecto.
Usuario final Afiliado Colmena | Cliente interno Ejecutivos Colmena | Equipo técnico Desarrollo Ionic |
|---|---|---|
Adulto de 40 a 65 años. Bajo manejo digital. Necesita resolver trámites de salud sin ir a una sucursal durante la pandemia. | Tomadores de decisión sin background digital. Aprobaban o rechazaban propuestas basándose en intuición de negocio, no en criterios de UX. | Framework híbrido con restricciones visuales reales. El diseño tenía que funcionar dentro de lo que Ionic permitía implementar. |
Resultados
+35%Aumento de sesiones activas | +18%Adopción del canal digital | −12%Visitas presenciales a sucursales |
|---|
Mi proceso
Auditoría de lo existente
Lo primero fue entender exactamente qué estaba roto y por qué. Mapeé todos los flujos existentes, identifiqué en qué pasos se caían los usuarios y cuáles eran técnicamente no funcionales. Eso nos dio una lista clara de prioridades: los flujos de bono y reembolso eran los más críticos y los más rotos. Por ahí empezamos.
Research con usuarios reales
Hicimos entrevistas y tests de usabilidad con afiliados. El hallazgo más importante fue que los usuarios no abandonaban por pereza, sino por miedo a equivocarse. "No sé si estoy haciendo bien esto" era la frase que más se repetía. Eso cambió el enfoque del diseño: el objetivo principal pasó a ser reducir la ansiedad, no solo la fricción.
Diseño de flujos críticos desde cero
Construí el flujo de compra de bonos y el de reembolso completos en Figma. El principio guía fue mostrar el resumen de costos al inicio, no al final. Simplifiqué el lenguaje: fuera los términos técnicos de seguros de salud, adentro lenguaje cotidiano. Cada pantalla tenía una sola acción posible para no abrumar a un usuario que ya llegaba con ansiedad.
Diseño dentro de las limitaciones de Ionic
onic tenía restricciones visuales reales. No todo lo que diseñaba era implementable sin costo técnico alto. Aprendí a trabajar con el equipo de desarrollo desde el inicio de cada flujo para diseñar dentro de lo posible. Algunas propuestas las simplifiqué, otras las adapté. El resultado no era el UI más pulido del mundo, pero era funcional y usable, que era lo que importaba en ese momento.
Gestión de stakeholders no digitales
Los prototipos interactivos no eran suficientes para convencer a los ejecutivos. Necesitaban ver el problema en su propio lenguaje. Empecé a presentar con datos de sucursales: "Este flujo genera X llamadas de soporte por semana. Si lo resolvemos digitalmente, ese número baja y las sucursales se descongestionan." Los números de negocio y el contexto de pandemia movieron las aprobaciones más que cualquier wireframe.
Testing y ajuste continuo
Hicimos rondas de testing antes de cada release. Con usuarios finales validamos que los flujos eran comprensibles sin explicación previa. Las iteraciones más importantes vinieron de observar a personas reales intentando comprar un bono por primera vez. Eso era imposible de simular en una reunión de stakeholders.
Decisiones de diseño clave
La decisión más impactante fue mostrar el resumen de costos al inicio del flujo de compra de bonos. Era contraintuitivo para los stakeholders. Argumenté con los datos de abandono que teníamos: la mayoría de los usuarios que llegaban al último paso y veían el costo por primera vez, abandonaban. Al poner el costo al frente el abandono bajó de forma significativa.
La segunda decisión fue simplificar el lenguaje de forma radical. Los textos originales usaban terminología de seguros que los usuarios no entendían. Reescribimos cada label, título y mensaje de error en lenguaje cotidiano. Ese cambio no requirió desarrollo adicional y tuvo impacto directo en la tasa de completación.
El UI no era perfecto. Pero era el primero que realmente funcionaba. Eso fue suficiente para cambiar el comportamiento de los usuarios.
Con Ionic aprendí a distinguir entre un límite técnico real y una resistencia al cambio del equipo de desarrollo. Algunas simplificaciones de diseño que parecían imposibles eran perfectamente implementables cuando las presentaba con el contexto correcto. Esa negociación constante entre lo ideal y lo posible fue uno de los aprendizajes más valiosos del proyecto.
Aprendizajes
Funcional primero, pulido después | El miedo es fricción |
|---|---|
El UI de Ionic no era el más bonito. Pero era el primero que permitía comprar un bono sin abandonar. En un contexto de pandemia, eso valía más que cualquier animación. | Los usuarios no abandonaban por pereza. Abandonaban por ansiedad. Diseñar para reducir el miedo a equivocarse fue más efectivo que simplificar los pasos. |
Habla el idioma del negocio | El lenguaje es UI |
Con stakeholders no digitales, los wireframes no convencen. Los datos de sucursales y el impacto operativo sí. Aprendí a traducir cada decisión de diseño a lenguaje de negocio. | Reescribir los textos en lenguaje cotidiano fue el cambio con mejor relación esfuerzo-impacto. Sin desarrollo adicional, mejoró la tasa de completación de forma inmediata. |