Resultado de validación usabilidad de usuario

Validación de los prototipos Figma del cliente asegurado (Android y web) con una experta en UX/UI y producto. No es un test con usuario final asegurado. El Design System es común a ambos canales; el recorrido principal fue móvil; web se recorrió de forma corta para comparar.

IA de referencia: Arquitectura de información · Cliente L1. Auditorías posteriores (20 sep 2026): Cumplimiento Axe y Nielsen · prototipo cliente · Cumplimiento Axe y Nielsen · prototipo back-office.


Fecha	18 de septiembre de 2026
Sesión	Solventa app · Validación interfaz gráfica — grabación, 18 sep 2026, 17:45 GMT-05
Facilitador	John Edwin Guerrero Ayala (grupo 8, MISW4501)
Participante	Karen Guerrero — diseño gráfico; maestría en diseño, experiencia de usuario e interfaz; liderazgo técnico y de producto. Industrias: seguros, fintech, banca, alimentos, educación, entre otras.
Artefactos	S6 (sin tocar): Screens Android · Screens web · S7 (tras la sesión): Screens · S7 validación · Android · Screens · S7 validación · web

La transcripción (VTT) no se versiona en el wiki. La grabación de la sesión está en Drive. Las notas del facilitador de la misma sesión se integran aquí; no sustituyen los hallazgos de Karen.

Conclusión

Los cuatro destinos (Inicio, Pólizas, Siniestros, Perfil) se entienden cuando el chrome es visible. El fallo no es el sitemap: es falta de contexto en las vistas (qué ramo, qué estado, en qué paso) y CTAs sueltos en Inicio. Web se percibió más clara y más cómoda que Android porque nombra el producto y el estado; Android dejó a Karen perdida hasta que vio el tab bar y la lista de pólizas.

En ambos canales no se leen los pasos cotización → oferta en firme → póliza → pago, ni si se puede dejar renovación automática. La navegación mezcla cards y tabs sin dejar claro si es el mismo flujo.

El prototipo S7 del cliente y el back-office no se recorrieron en esta sesión. Las auditorías posteriores (20 sep 2026) cruzan estos hallazgos con WCAG y Nielsen: Cumplimiento Axe y Nielsen · prototipo cliente · Cumplimiento Axe y Nielsen · prototipo back-office. En el back-office, Clientes pasó a ser CRUD de usuarios web/móvil; Cotizaciones y Pólizas cargan cada una su cola.

Hallazgos · Android

Prioridad, no orden de la sesión.

Orientación y tipo de objeto

No identificó Inicio frente a otras pantallas hasta que se le señaló el tab bar inferior (Inicio, Pólizas, Siniestros, Perfil).
Tras aceptar / emitir: los mensajes de éxito le parecieron estándar, pero no sabía qué tipo de póliza era. En Inicio tampoco reconoció si era home, un resumen o el seguro que acababa de elegir.
En Pólizas sí entendió Protección de dispositivo y Microseguro de vida una vez vio la lista (“las que activamos”). El objeto se lee en la billetera; no en el éxito ni en el home.
Home confuso: oferta, pólizas y el resto de bloques no tienen contexto. Hay que decidir si Inicio es resumen; hoy parece una lista plana de acciones.

Shell A (pre-login / onboarding)

Numeración del onboarding incorrecta. Registro y consentimiento piden un stepper real (“en qué paso estoy”); los números actuales no coinciden con el flujo.
El onboarding no presenta funcionalidad ni beneficios de la app. Debe ser más amigable: qué cubre Solventa antes de pedir datos (PDF §5.2), no pedir cámara/GPS en el splash.
Idioma y región: confunde valores de ejemplo (prima/fecha) con la selección. No queda claro qué es el paso anterior (splash) frente a este.
El prototipo no dejó navegar con teclado: limitación de Figma, no de producto.

Cotización e Inicio

No encontró Nueva cotización hasta que el facilitador la señaló en Inicio. El form de dispositivo (tipo, valor, marca) le pareció bien de componentes; el problema es de arquitectura de información y flujos.
En Figma Play, nueva-cotizacion no hace scroll hasta el extremo inferior: no se llega a Cotizar. Limitación del prototipo; el form en sí no se cuestionó.
Hay que definir el objetivo de Inicio: resumen, métricas de siniestros, cotizaciones u ofertas. Hoy percibe demasiados llamados a la acción; agrupar reportar siniestro con su objeto, no como CTA suelto junto a cotizar.
Tras Aceptar oferta vuelve a Inicio y no entiende si “se actualizó”: falta el hilo cotización → póliza en la misma vista.

Pólizas

El listado debe llevar descripción o resumen del tipo (ramo), no solo un título de producto.
Según el tipo, la póliza (lista o detalle) debe recomendar qué hacer en un siniestro y qué información aportar. Ejemplo: accidente de tránsito — qué hacer y qué evidencia pide la aseguradora. Eso es contenido del ramo, no un destino nuevo.
Primera cotización desde Pólizas: si aún no hay póliza, el destino debe permitir solicitar cotización (mismo CTA nueva-cotizacion, no un quinto tab). Hoy solo se descubre desde Inicio.

Siniestros

El FAB Reportar le resultó reconocible (patrón Android).
Ubicación: importante según el ramo (p. ej. vehículo). Los permisos JIT le parecen el mecanismo correcto.
El aviso debería cambiar de campos y de recomendaciones según la categoría (dispositivo vs vehículo vs vida). En accidentes de vehículo el usuario no conoce el proceso de la aseguradora; eso es contenido del ramo, no un destino nuevo.

Copy, branding y jerga

Menos wording y componentes de marketing genéricos. Branding y copy orientados a aplicación de seguros.
Reiterar beneficios en login / Inicio (patrón banca) y luego entrar al flujo.
La app debe ser más descriptiva o ofrecer ayuda en la vista (asistente o “¿qué es esto?”) para bajar fricción con la jerga. No es un quinto destino ni el mapa de asistencia (G-07).
Canal Colombia: términos de ley colombiana (habeas data, ramo, prima, siniestro, póliza). El i18n de otros mercados es posterior; no se inventan ramos ni destinos por idioma.

Consentimientos

Cada consentimiento debe ofrecer enlace al documento o una vista completa de las connotaciones legales de pedir esos datos (alta habeas data y perfilamiento hipotecario). El switch solo no basta.

Hallazgos · Web

Recorrido corto, mismos cuatro destinos en TopNav.

Más clara y más cómoda que el móvil

El tab de navegador (Inicio, Pólizas, Siniestros) le resultó más cómodo de navegar y de entender.
Percibió SOAT motocicleta, póliza activa, vencimiento y siniestro en curso. Eso confirma que el problema de Android es cards sin ramo ni estado, no el número de destinos.
Cards y “oferta lista” le parecieron actuales. Los beneficios se leen mejor aquí.
Ir a siniestros como atajo desde Inicio le pareció adecuado (redirección a otro tab).

Flujo de emisión, pago y renovación

El salto Aceptar → Ver mi póliza no se entiende: no sabe si ya aceptó, si faltaban pasos o si es un estado de éxito que se insertó.
Pedir el mismo stepper / estados visibles que en el alta.
Transversal con Android: no se comprenden los pasos cotización → oferta en firme → póliza creada → pago, ni configurar renovación automática. L1 hoy muestra avisos de vencimiento/renovación en lectura (HU-64 / HU-65); el gap de usabilidad es que ese hilo no está etiquetado en el flujo.

Vida Crediticia / consentimiento

No sabe si el consentimiento es un paso del seguro hipotecario o un bloque suelto. En producto suele ser términos y un checkbox.
Percibe un solo flujo partido en varias cards de Inicio, no destinos distintos. El consentimiento de perfilamiento debe vivir dentro de hipotecario, no como card paralela de “otro producto”.
Mismo criterio legal que en Android: documento o vista completa, no solo el control.

Lenguaje y perfil

Pago paramétrico: “no sé si cualquier usuario sabe qué es un paramétrico”. Hay que explicarlo (en canal: Pago automático). Sugiere acompañamiento (asistente) cuando el lenguaje no es familiar, sin un quinto destino ni mapa de asistencia L1.
Nueva cotización en el header: cuestionó si esa es la acción a priorizar; el detalle de siniestros le gustó.
Perfil: idioma y región como opción explícita; si el consentimiento es crítico de negocio, enlace al documento detallado (no solo el switch).

Transversal (Android y web)

Qué se sostiene	Qué hay que cambiar en las vistas
Cuatro destinos. Nueva cotización no es tab.	Toda card de `Cotizacion`, `Oferta`, `Poliza` y `Siniestro` muestra ramo + estado.
Form de dispositivo (Android) usable.	Nueva cotización descubrible desde Inicio y desde Pólizas vacías (primera vez).
Web nombra el producto y por eso se entiende / navega mejor.	Paridad de contenido L1: dispositivo, no SOAT/Hogar (esos ramos no están en el catálogo L1 / PDF §2.2).
Hipotecario y cotización de dispositivo son flujos distintos.	Hipotecario = un flujo con consentimiento como paso. Un flujo no se parte en cards sueltas + tabs.
Pago por evento clima/vuelos vive en Siniestros.	Etiqueta de canal Pago automático; no “paramétrico”.
Avisos de vencimiento / renovación ya existen como lectura.	Hilo visible: cotizar → aceptar → emitir → pagar → renovación automática (qué paso es, qué falta).
FAB y TopNav reconocibles.	Lista y detalle de póliza: resumen del ramo + recomendaciones de siniestro de ese tipo.
Consentimiento de alta y de perfilamiento ya son pantallas.	Enlace o vista al texto legal; términos de ley colombiana en canal.

Navegación cards vs tabs. A veces se avanza entre tarjetas de Inicio y a veces se cambia de destino. El usuario no sabe si sigue en el mismo flujo. Regla: un flujo (alta, cotización-emisión, hipotecario, aviso de siniestro) usa pasos + padre del tab; el salto a otro destino es atajo explícito (“Ir a siniestros”), no otra card del mismo tamaño.

Fuera de L1 / del prototipo

No se convierten en destinos ni en ramos nuevos:

Navegación por teclado en el prototipo Figma.
Scroll incompleto de nueva-cotizacion en Figma Play.
Mapa de asistencia, abogado en sitio (G-07 y post-mvp). La ayuda en la vista (glosario / “¿qué es esto?”) sí es regla de contenido; no abre un quinto destino.
Configurar renovación automática como autoservicio (HU-66 / HU-67, post-mvp). El hallazgo se registra; L1 sigue en lectura de avisos (HU-64 / HU-65) pero debe mostrar el paso.
SOAT / Hogar como productos de la web: ruido de prototipo; el portafolio del caso es viaje, dispositivos, microvida, clima/vuelos y protección de pagos (PDF §2.2).

Las reglas de IA que salen de esta sesión están en Arquitectura de información · Cliente L1.

Cambios de UI · Screens vs S7 validación

Comparación visual del prototipo S6 (Screens) con las vistas editadas en S7 (Screens · S7 validación). Screens no se modifica: es la línea base de la sesión del 18 Sep 2026. Las capturas son del 20 Sep 2026.

Figma: Android S6 · Android S7 · web S6 · web S7

Vista	S6 (Screens)	S7 validación
Inicio	Lista plana de CTAs; en web SOAT/Hogar	Resumen por objeto (cotización / póliza / siniestro / hipotecario) con ramo + estado. CTA Nueva cotización. Reportar es FAB (Android) o atajo al tab (web).
Nueva cotización	Un solo form (dispositivo en Android; SOAT en web)	Selector de ramo + descripción + campos de ese riesgo. Prima = precio del seguro, no valor del bien. Stepper paso 1 de 4.
Ver oferta	Título de oferta sin paso ni ramo	Ramo + paso 2 de 4; aceptar emite la póliza.
Póliza emitida	Éxito genérico	Paso 4 de 4, ramo + número; el objeto vive en Pólizas.
Lista pólizas	Título de producto; web con Hogar/SOAT	Columna/fila con ramo + estado; recs de siniestro.
Lista siniestros	FAB en el flujo (Android); «paramétrico»	FAB Material 56 dp anclado; Pago automático.
Pago automático	Pago paramétrico	Título de canal + umbral en lenguaje de usuario.
Vida hipotecario	Consentimiento como otro producto	Paso 1 de 3 del mismo flujo + enlace al texto legal.