Ammia (Surexs)

Cuando inicié con Ammia, el reto era claro: las personas no entendían sus seguros y no sabían qué hacer en los momentos críticos. Desde el punto de vista del diseño, mi misión —y la llevé a cabo completamente sola— fue transformar esa experiencia confusa en algo intuitivo, claro y empático.

Contexto de negocio

Surexs tradicionalmente vende pólizas de seguros y fianzas a empresas (B2B) en volúmenes grandes, con procesos y necesidades propias de áreas de RR. HH., finanzas y compliance. Ammia surge como el esfuerzo de la compañía por abrir un canal B2C, llevando al usuario individual una experiencia directa para comprar, entender y usar su seguro.

Este contexto implicaba diseñar una experiencia que conviviera con dos realidades:

1) Personas ya aseguradas a través de su empresa (integración y uso inmediato)

2) Personas sin póliza que querían cotizar y contratar desde cero (Tienda), manteniendo la confianza y el respaldo de la operación B2B.

Aquí te lo explico mucho más fácil

El problema desde el usuario

Hablando con asegurados y administradores, descubrí patrones comunes:

• Nadie sabía dónde estaba su póliza cuando la necesitaba.
• Reportar un siniestro era sinónimo de ansiedad y llamadas interminables.
• Los términos técnicos generaban frustración y desconfianza.

El insight principal

“Cuando ocurre un accidente, el usuario no necesita leer un manual, necesita pasos simples y certezas inmediatas”.

Personas, mapa de empatía y journey

En esta sección reunimos la comprensión del usuario y la alineamos con los objetivos del negocio. Primero verás las personas (quiénes son y qué necesitan), luego el mapa de empatía (qué piensan, sienten, dicen y hacen) y finalmente el customer journey que traduce esos hallazgos en pasos claros de la experiencia.

Investigación

Como era la única persona de diseño, tuve que organizar y ejecutar todo el proceso de Design Thinking por mi cuenta, desde empatizar hasta testear.

Empatizar

Entrevistas en profundidad con 18 usuarios asegurados y 6 administradores corporativos.

• Objetivo: entender pains reales en vinculación, uso de póliza, red médica y reporte de siniestros.
• Guion semiestructurado: tareas recientes, barreras, lenguaje que confunde, expectativas de “siguiente paso”.
• Reclutamiento y cuotas: mezcla por edad, plataforma (iOS/Android), experiencia previa y tipo de cobertura (empresa vs. individual).
• Modalidad y duración: 45–60 min por sesión, remoto (grabado) y 4 presenciales para contexto (documentos físicos, fotos, correos).
• Análisis: codificación temática (p. ej., “no encuentro PDF”, “OTP tarda”, “jerga”), mapa de afinidad y saturación teórica (se repiten patrones).
• Resultados accionables: microcopy claro, CTA de vincular visible, checklist para siniestros y geolocalización en red médica, con métricas para validar cambios.

Shadowing: acompañé a usuarios mientras intentaban reportar un siniestro real, registrando momentos de verdad, interrupciones y pasos redundantes (observación contextual).

Mapas de empatía para captar qué piensan, sienten, dicen y hacen al enfrentarse a un siniestro; insumos clave para el microcopy y la jerarquía de acciones.

Definir

Customer Journey Map (CJM) con puntos de dolor y emociones por etapa.

• Alcance: Descubrir → Vincular/Comprar → Usar → Resolver → Post-servicio.
• Capas del CJM: Objetivo del usuario · Acciones · Pains · Oportunidades UX · Métricas (TTFPV, view-quote-personalize-bind, drop-off) · Curva emocional.
• Segmentación: dos journeys paralelos: Asegurados por empresa vs Nuevos usuarios.
• Entregables: versión 1-slide para presentación + versión extendida con evidencias.

Momentos críticos identificados

• Descarga de póliza: visibilidad del PDF, compartir a un toque, glosario “qué cubre”.
• Reporte de siniestro: checklist mínimo, tiempos estimados y estado en tiempo real.
• Solicitud de reembolso: documentos claros, validaciones amistosas y estatus granular.

How Might We (HMW) para guiar la ideación

• ¿Cómo podríamos reducir la ansiedad al reportar un siniestro?
• ¿Cómo podríamos hacer que compartir la póliza sea tan fácil como enviar una foto?
• ¿Cómo podríamos hacer visible el siguiente paso tras vincular/comprar?
• ¿Cómo podríamos explicar deducible y coberturas en lenguaje humano y breve?
• ¿Cómo podríamos usar la geolocalización para sugerir la mejor opción de atención cercana?
• ¿Cómo podríamos reducir el tiempo de cotización sin perder precisión?
• ¿Cómo podríamos hacer el OTP casi invisible (autofill, 1 input, reenvío claro)?

De HMW a decisiones de diseño

• Ansiedad en siniestro → CTA persistente “Reportar”, wizard de 3 pasos, checklist y ETA.
• Póliza difícil de hallar → botón “Descargar PDF” destacado y opción Compartir.
• Siguiente paso difuso → pantalla de éxito con 2 CTAs: “Usar beneficios” / “Ver póliza”.
• Deducible confuso → tooltips y ejemplos (“más deducible = menor prima”).
• Atención cercana → red médica geolocalizada (lista/mapa, “Abierto ahora”, distancia).
• Cotización lenta → formulario progresivo en bloques y validaciones amistosas.
• OTP friccionado → input único con autofill, Reenviar en 00:30 y canal alterno.

Idear

Ideación

Técnicas utilizadas: Crazy 8s para explorar rápidamente variaciones de flujo/UI y mapas mentales para agrupar caminos de solución según los HMW (ansiedad en siniestros, hallazgo de póliza, comprensión de deducible).

Generación de ideas: produje 40+ ideas en papel/Figma (layouts, CTAs, microcopy, estados). Las agrupé por tema y objetivo (vinculación, tienda, red médica, siniestros) para detectar patrones repetidos.

Priorización: apliqué matriz impacto/esfuerzo (rápido valor al usuario) y, para flujos críticos, una estimación ligera tipo RICE (alcance, impacto, confianza, esfuerzo). Mantuve un breve decision log con riesgos y supuestos.

Conceptos clave seleccionados

• Botón persistente “Reportar”

Por qué: reduce tiempo de reacción en el momento de verdad.

Métrica objetivo: ↑ clics en “Reportar” desde home y ↓ tiempo a 1er paso del parte.

• Checklist dinámico de siniestro

Por qué: baja ansiedad mostrando solo lo indispensable según póliza/evento.

Métrica objetivo: ↑ tasa de finalización del reporte y ↓ errores/retrabajos.

• Red médica filtrada por geolocalización

Por qué: prioriza cercanía y disponibilidad (“Abierto ahora”, distancia).

Métrica objetivo: ↓ TTFP (tiempo al primer proveedor) y ↑ clics en “Llamar/¿Cómo llegar?”.

Prototipar

Metodología: sesiones moderadas (remotas y 4 presenciales), con escenarios simulados y tareas realistas. Iteraciones cortas con 5–8 participantes por ciclo, registro en video y notas estructuradas.

Tareas clave evaluadas:

• Descargar póliza desde el detalle (y opción Compartir).
• Reportar siniestro (CTA persistente → wizard → checklist y confirmación).
• Red médica (búsqueda por geolocalización, filtros “Abierto ahora” / distancia).

Criterios de éxito: completar sin ayuda, tiempo < 2 min y comprensión del siguiente paso. Resultado: validé que podían descargar su póliza y reportar un siniestro en menos de 2 minutos.

Métricas capturadas: tasa de éxito por tarea, tiempo (mediana/p90), errores y su severidad, feedback abierto y marcadores de confusión (scrolls, toques repetidos, retrocesos).

Principales ajustes tras el feedback

• Microcopy: lenguaje más directo (“Descargar PDF”, “Reportar ahora”, “Te tomará <2 min”).
• Jerarquía visual: CTA de vincular y reportar más prominentes; botones arriba del pliegue.
• Flujo de siniestro: checklist reducido y estados claros (Recibido/En revisión/Autorizado).
• Accesibilidad: contraste AA, tamaños táctiles ≥44 px y foco visible en inputs.

Testear

Modalidad: sesiones moderadas con escenarios realistas y participantes representativos. Se evaluaron tareas clave y se registró comportamiento (video/notas) para identificar fricción.

Tareas evaluadas:

• Descargar póliza (y localizar el PDF de forma inmediata).
• Reportar siniestro (CTA persistente → wizard → checklist y confirmación).
• Encontrar red médica (búsqueda por geolocalización, filtros “Abierto ahora”, distancia).

Métricas: tasa de éxito, tiempo por tarea (mediana/p90), errores y su severidad; además, notas de comprensión de términos (deducible, coberturas, documentos).

Iteración continua (48–72 h): a partir del feedback, ajusté microcopys y la jerarquía visual (prioridad de CTAs, orden de pasos, estados). Se repitieron ciclos cortos para validar mejoras.

• Microcopy: mensajes directos (“Descargar PDF”, “Reportar ahora”, tiempos estimados claros).
• Jerarquía visual: CTAs críticos sobre el pliegue, énfasis en “Ver mi póliza” tras vincular.
• Claridad de términos: tooltips y glosario breve en contexto (deducible, coberturas).

Journey map

Definición de objetivos

• Poner la póliza a un clic
• Guiar paso a paso en un siniestro
• Traducir lenguaje técnico a humano.
• Dar seguridad visual

Dificultades

Entre el roadmap de producto, las aseguradoras/marcas y los flujos clave, la complejidad se puso “nivel jefe final”.

Y eso que aún no sumábamos la gran diversidad de usuarios.

Ideación y prototipado

A partir de los hallazgos, diseñé flujos simples y probé con usuarios:

Home con tarjetas de póliza: accesibles y con botón de descarga inmediato.

CTA persistente de “Reportar siniestro”: siempre visible.

Checklist dinámico: mostrar solo lo indispensable, con microcopys empáticos.

Reembolsos con estatus claros: “Recibido”, “En revisión”, “Autorizado”.

Red médica filtrada: por cercanía y especialidad.

Los prototipos se validaron en sesiones rápidas de guerrilla testing: los usuarios lograban llegar al resultado deseado en menos de 2 minutos.

Punto de giro: de entender al usuario a alinear con el negocio

Justo ahora estamos parados en la bifurcación:

entendimos las necesidades del usuario y podemos diseñar una aplicación útil y efectiva para él.

Sin embargo, como UX no debemos descuidar las necesidades del negocio.

A partir de aquí, alineamos los flujos para crear valor para la persona y para la operación.

Doble frente: integrar usuarios existentes y captar nuevos (Tienda)

Para resolver la convivencia de usuarios con póliza previa y usuarios nuevos diseñé dos experiencias complementarias que comparten lenguaje visual, pero optimizadas para cada necesidad.

Usuarios existentes

Problema UX: personas ya aseguradas quieren usar una app más clara que la de su aseguradora original. Les frena: recordar el dato correcto (correo/teléfono), demoras del OTP, errores de coincidencia y no saber el siguiente paso.

Objetivo UX: vincular la póliza en 1–2 pasos, dar certeza inmediata (producto/vigencia) y llevar al primer uso (PDF, red médica, siniestro) sin fricción.

Flujo propuesto (paso a paso)

• 1) Entrada clara: Home/Onboarding con bifurcación “¿Ya tienes seguro?” → Vincular póliza.
• 2) Método de vinculación:
• Correo/Teléfono (recomendado): ingresa dato; mostramos el destino enmascarado para confirmar.
• N.º de póliza (alternativa): campo único con ejemplo visual y ayuda contextual.
• 3) Verificación OTP: input único (4–6 dígitos), teclado numérico, autofill, Reenviar en 00:30 y opción Usar otro canal.
• 4) Confirmación de póliza: nombre del producto y vigencia; CTAs: Descargar PDF y Usar beneficios.
• 5) Primer uso guiado:
• PDF a 1 clic + compartir.
• Red médica por geolocalización (lista/mapa, “Abierto ahora”, distancia).
• Reportar siniestro con checklist y tiempos estimados.

Microcopy

• “Ingresa el correo o celular con el que te aseguraste. ¿No lo recuerdas? Usa tu n.º de póliza.”
• “Te enviamos un código a +52 •• •• •• 12. Llega en ~10 s. Reenviar en 00:27.”
• “Listo, tu póliza está vinculada. ¿Qué quieres hacer ahora?”

Casos especiales (UI)

• Dato no coincide: ofrecer cambio de método (n.º de póliza) y contacto asistido prellenado.
• OTP no llega: reenviar con cooldown, cambiar a correo/llamada y mostrar estado del intento.
• Múltiples pólizas: lista con chips por aseguradora/ramo y selección de predeterminada.
• Póliza vencida: badge “Vencida” + CTA Renovar (lleva a Tienda con datos prellenados).

Métricas clave

• Embudo: open_app → start_link → otp_sent → otp_verified → policy_linked → first_view → first_action.
• TTFPV: tiempo a primera visualización de póliza.
• Éxito OTP / reenvíos / expirados y errores de coincidencia de dato.
• Adopción D+7: % PDF, % red médica, % inicia siniestro.

Tienda para los nuevos

Problema UX: captar personas sin póliza y llevarlas de interés a contratación sin abrumarlas con tecnicismos.

Objetivo UX: un funnel claro y corto: ver - cotizar - personalizar - confirmar - pagar, con lenguaje humano.

Flujo propuesto (paso a paso)

• 1) Entrada a Tienda: desde home o durante el onboarding si elige “Aún no”.
• 2) Explorar productos: tarjetas (Auto, Gastos Médicos, Vida, Hogar) con “para quién es” y “qué cubre” en simple.
• 3) Cotizar simple: preguntas cortas en bloques, con ejemplos y validaciones amistosas (evitar formularios largos).
• 4) Comparar planes: 2–3 opciones de varias aseguradoras con precio total, deducible y “qué sí / qué no cubre”; tooltips y glosario.
• 5) Personalizar: sliders para suma asegurada y deducible; recálculo en vivo con ejemplos claros.
• 6) Confirmar: resumen entendible, términos simples y enlaces a condiciones.
• 7) Finalizar: pago, envío de póliza digital y CTA “Ver mi póliza” que lleva al flujo de uso.

Microcopy recomendado

• “Elige la opción que te protege sin sorpresas.”
• “Ajusta el deducible: más bajo = pagas menos en el siniestro; más alto = tu prima baja.”

Casos especiales (UI)

• Sin oferta: mostrar alternativas y contacto humano.
• Dudas: glosario integrado y ejemplos cotidianos.
• Abandono: guardado automático del avance y recordatorios opcionales (opt-in).

Métricas clave

• Embudo: view - quote - personalize - bind (compras).
• Tiempo total de cotización y drop-off por paso.
• % de compras con ajustes vs plan base.

Arquitectura de experiencia compartida

Navegación por tareas: “Mis pólizas” y “Tienda” conviven en la barra inferior.

Diseño consistente: tarjetas, badges, botones y microcopy comparten sistema visual para disminuir curva de aprendizaje.

Accesibilidad: contraste AA, foco visible, áreas táctiles amplias, lenguaje llano.

Validación

Pruebas con usuarios existentes (vincular) y nuevos (tienda). Ajusté el orden de preguntas y la jerarquía del comparador para reducir fricción.

Diseño visual

Me enfoqué en un sistema limpio, con contraste alto y lenguaje visual cercano. Priorizamos botones grandes, íconos reconocibles y mensajes claros. Ejemplo de microcopy: en lugar de “Adjuntar documentación requerida”, usé “Sube tus fotos o recibos, nosotros validamos el resto”.

Validación e iteraciones

Durante pruebas beta con empleados:

80% descargó su póliza sin pedir ayuda.

70% completó un reporte de siniestro en menos de 3 minutos.

El feedback más repetido fue: “Por fin entiendo qué hacer”.

Con esa retroalimentación refiné la jerarquía visual y mejoré la legibilidad en pantallas pequeñas.

Recepción e impacto del lanzamiento

El lanzamiento móvil fue muy bien recibido por usuarios y clientes corporativos. A partir de la adopción y del feedback cualitativo surgieron dos decisiones clave de producto y marca:

Versión web (omnicanal): se solicitó y aprobó desarrollar Ammia Web para cubrir casos de uso en escritorio (consultas rápidas, carga de documentos desde PC, accesibilidad sin smartphone) y para unificar experiencia móvil–web con el mismo sistema de diseño.

Mascotas e ilustración de marca: se aprobó presupuesto para un ilustrador y se crearon las mascotas de Ammia. Estas piezas visuales aumentaron el atractivo de la interfaz, bajaron la barrera emocional y ayudaron a que la gente percibiera el seguro como algo amable y entendible, no como un trámite pesado.

Estas decisiones reforzaron la consistencia de marca, la recordación y la claridad de los mensajes clave (qué cubre, qué hacer, cómo resolver).

Resultados

En los primeros meses de uso:

Descargas de póliza aumentaron un 42%.

Tickets de soporte de “¿Dónde encuentro mi póliza?” bajaron en 60%.

El NPS en uso de seguro subió +10 puntos.

Conclusión

El caso de Ammia es un ejemplo de cómo, desde UX/UI, incluso siendo la única diseñadora, se puede tomar un proceso complejo y convertirlo en una experiencia clara y humana, reduciendo fricciones y devolviendo confianza al usuario en los momentos que más lo necesita.

Reflexión personal

Como diseñadora UX/UI trabajando sola, el mayor aprendizaje fue entender que diseñar para seguros no es diseñar pantallas, es diseñar calma en momentos de estrés. Ammia demostró que un buen diseño puede ser tan valioso como la cobertura misma.

Preguntas frecuentes

¿Qué software se usó?

El proyecto se inició en XD porque inició como un proyecto muy pequeño. Pero como se fue acumulando todo y generando cambios de UI se pausó y se envió a FIGMA

¿Usaste algún sistema de diseño?

Utilicé la guía de diseño de material y con ello se rediseñó un sistema de propio de la app.

¿Y la casuística?

Más de doscientos casos para combinar diferentes opciones