Referencia de diseño para construir los canales de Solventa: tokens, componentes, pantallas y flujos, con el identificador exacto de cada frame en Figma.

Fuentes de diseño

Stack de implementación. Web: AngularJS + TypeScript, unitarias con Karma y E2E con Cucumber/Gherkin. Móvil: Android nativo (Kotlin + Jetpack Compose), Clean Architecture + MVVM + Repository, unitarias con JUnit. No es híbrido ni comparte código de UI entre canales. Detalle en Estrategia de pruebas §4.

Páginas relacionadas: Arquitectura de información · Prototipo navegable · Cumplimiento axe/Nielsen · cliente · · back-office · Validación con usuario

1. Guía de estilos (design tokens)
2. Catálogo de componentes UI
3. Inventario de pantallas por plataforma
4. Flujos de navegación
5. Consideraciones técnicas

Ambos archivos comparten paleta, tipografía y escala. La diferencia está en cómo se declaran: el archivo móvil usa cuatro colecciones de variables con primitives aliasados por rol semántico; el web usa una sola colección de color con modos Light/Dark.

Material 3 con primary #005050. Cada token existe en Light y Dark; en Android los roles apuntan a un primitivo mediante alias.

Regla de pares. Un fill primary siempre lleva texto on-primary; nunca texto primary sobre fill primary. Los pares verificados en S7 cumplen WCAG 2.2 §1.4.3 AA: on-surface / surface 16.4:1, on-surface-variant / surface 8.9:1, on-primary / primary 9.3:1.

Deuda registrada. El helper de campos (#6e7979 sobre #f7faf9) da 4.28:1 a 12 px; AA exige 4.5:1. Corregir subiendo el tamaño o oscureciendo el token. Ver Cumplimiento axe/Nielsen.

Hanken Grotesk para UI, JetBrains Mono para montos e identificadores. No se usa Inter.

Por qué mono en cifras. Los dígitos tabulares alinean verticalmente en tablas y listas, y distinguen POL-90102 de texto corrido. Todo monto pasa por el formateador de locale: el núcleo entrega prima y código de moneda, el canal formatea (PL-01).

El archivo móvil declara además padding/xs…xl con los mismos valores, para distinguir separación de relleno al bindear.

Breakpoint = ancho de canvas en el que cambia el layout web. No aplica a la app Android, que es nativa a 390.

El back-office solo existe a 1440: es herramienta de escritorio.

Material Symbols (Rounded). El archivo móvil publica 15 iconos como componentes individuales bajo Icon/*:

placeholder · back · home · description · emergency_home · person · check · cancel · info · chevron_right · visibility · add · lock · menu · error

Un icono nunca comunica estado por sí solo: siempre lleva texto asociado.

Cada uno vive en su propia página del archivo de design system, con variantes formales y slots de texto expuestos como propiedades.

Select con seis ramos. Las opciones son los ramos L1 renombrados tras la validación con usuario: Protección de dispositivo, Microseguro de vida, Clima y vuelos, Vida hipotecario, Pagos, Viaje. Reemplazan a «SOAT» y «Hogar», que no se entendían fuera de contexto colombiano.

Definidos en la página Chrome del archivo web.

Estados de campo documentados en la galería: DEFAULT, FOCUS, ERROR (con mensaje) y DISABLED (40 % de opacidad). Badges de cliente: Vigente · En curso · Oferta · Rechazada · Pendiente. El stepper de emisión marca Cotizar → Oferta → Emisión → Póliza → Aviso.

Cuatro sets propios en la página Back-office · Asesor / Operador. Nacen porque el cliente administra sus pólizas mientras el asesor opera carteras de terceros: la arquitectura de información es distinta, no una variante de la de cliente.

Todos reutilizan Button y Footer del cliente como instancias, y bindean la misma colección Color: el back-office hereda el design system, no lo duplica.

82 frames en total. El identificador abre el frame directamente en Figma.

Canvas 390 × 844. Página Screens del archivo de design system.

Estados de permiso y denegación (HU-101, HU-24) — misma ruta, otra UI:

Overlays (bottom sheets; cierran con Close y no empujan el NavHost): overlay-idioma-region [102:738] · overlay-permiso-ubicacion [102:782] · overlay-permiso-camara [102:811] · overlay-permiso-fotos [102:840] · overlay-consentimiento-datos [111:773] · overlay-consentimiento-vida-crediticia [111:784] · overlay-cerrar-sesion [54:768]

Canvas 1440. Página Screens.

Overlays web (diálogos que cierran con Close, no rutas): overlay-idioma-region [7:318] · overlay-consentimiento-datos [7:326] · overlay-consentimiento-vida-crediticia [7:334] · overlay-cerrar-sesion [7:342] · overlay-ubicacion-navegador [62:391]

Responsive (página Responsive) — demuestra que la IA se conserva y solo cambia el layout:

Canvas 1440, solo desktop. Página Back-office · Asesor / Operador.

Gestión de clientes y listas (ampliación posterior del equipo):

Cotización por ramo — cinco variantes del formulario, una por ramo L1: asesor-cotizacion-viaje [254:1191] · -vida [254:1289] · -clima [254:1387] · -pagos [254:1485] · -hipotecario [254:1583]

Asesor · cartera	Operador · cola de avisos

Ambos archivos tienen una página Screens · S7 validación con la versión revisada tras la inspección de accesibilidad y la prueba con usuario: 34 frames en web y 39 en móvil. Cada uno cierra con su propio tablero de hallazgos — web 178:382, móvil 216:811.

Esta es la versión vigente para implementar el canal cliente. Las páginas Screens originales quedan como historial del prototipo de la semana 6.

Qué cambió respecto a Screens

Galería de los seis recorridos críticos (PDF §5.1) en ambos canales. El resto de frames se consulta en Figma.

Web · login	Web · registro	Web · consentimiento-datos

Móvil · onboarding	Móvil · login

Web · idioma-region	Web · inicio	Móvil · idioma-region	Móvil · inicio

Web · nueva-cotizacion	Web · ver-oferta	Web · poliza-emitida

Móvil · nueva-cotizacion	Móvil · ver-oferta	Móvil · poliza-emitida

El indicador «paso N de 4» y el CTA de continuidad cierran el salto Aceptar → Ver mi póliza que detectó la validación.

Web · aviso-siniestro	Móvil · aviso-siniestro	Móvil · permiso-camara	Móvil · evidencia-siniestro

La diferencia de canal se ve aquí: el móvil pide permiso JIT al usar la cámara; el web adjunta archivo y usa el prompt del navegador.

Web · parametrico	Móvil · parametrico	Web · oferta-hipotecario	Móvil · oferta-hipotecario	Web · detalle-poliza

flowchart TB
  Splash["splash-solventa"] --> Idioma["idioma-region"]
  Idioma -->|"Mexico"| IdiomaMx["idioma-region-mx<br/>$1,234.56 MXN"]
  Idioma --> Onboarding["onboarding<br/>datos + documento"]
  IdiomaMx --> Onboarding
  Idioma -->|"Ya tengo cuenta"| Login["login"]
  Onboarding --> Consent["consentimiento-datos<br/>habeas data"]
  Consent --> Inicio["inicio"]
  Login -->|"credenciales invalidas"| LoginErr["login-error<br/>estado, no ruta"]
  LoginErr --> Login
  Login -->|"exito"| Inicio

  Inicio -->|"CTA Nueva cotizacion"| Cotizar["nueva-cotizacion<br/>paso 1 de 4"]
  Cotizar --> Oferta["ver-oferta<br/>prima, moneda, venceEn"]
  Oferta -->|"vencida"| Cotizar
  Oferta -->|"Aceptar"| Emision["emision-progreso"]
  Emision -->|"aprobada"| Emitida["poliza-emitida"]
  Emision -->|"rechazada HU-13"| Rechazo["suscripcion-rechazada<br/>motivo persistido"]
  Emitida -->|"Ver mi poliza"| Detalle["detalle-poliza"]
  Emitida -->|"Ir al inicio"| Inicio
  Rechazo --> Inicio

  classDef navOff fill:#ffdad6,stroke:#ba1a1a,color:#410002
  class Splash,Idioma,IdiomaMx,Onboarding,Consent,Login,LoginErr,Emision,Emitida,Rechazo navOff

Los nodos en rojo tienen la NavigationBar oculta: shell A pre-login y shell D/E durante la emisión. El cliente no puede cambiar de tab a mitad del proceso.

flowchart TB
  Lista["lista-siniestros<br/>destino raiz"] -->|"FAB Reportar"| Aviso["aviso-siniestro<br/>formulario + foto"]
  Aviso -->|"adjuntar foto"| PermCam{"permiso-camara<br/>dialogo del SO"}

  PermCam -->|"Permitir"| Evidencia["evidencia-siniestro"]
  PermCam -->|"Denegar"| PermFotos{"permiso-fotos<br/>galeria"}
  PermFotos -->|"Permitir"| Evidencia
  PermFotos -->|"Denegar"| SinCam["evidencia-camara-denegada<br/>misma ruta, otra UI"]

  Evidencia -->|"geoetiquetar"| PermGps{"permiso-ubicacion"}
  PermGps -->|"Permitir"| ConGps["evidencia con GPS"]
  PermGps -->|"No permitir"| SinGps["evidencia-geo-denegada<br/>misma ruta, otra UI"]

  ConGps --> Confirma["confirmacion-siniestro<br/>siniestroId"]
  SinGps --> Confirma
  SinCam --> Confirma
  Confirma --> Lista
  Confirma --> Inicio["inicio"]

  classDef permiso fill:#cce8e7,stroke:#005050,color:#00201f
  classDef degradado fill:#ffdad6,stroke:#ba1a1a,color:#410002
  class PermCam,PermFotos,PermGps permiso
  class SinCam,SinGps degradado

Tres reglas que el diagrama hace explícitas:

• El permiso se pide al usar la función, nunca en splash ni al instalar (PDF §5.2).
• Todos los caminos llegan a confirmacion-siniestro: ningún permiso denegado bloquea el envío del aviso.
• Denegar no crea una ruta nueva — es la misma pantalla con otra UI.

flowchart LR
  Inicio["inicio<br/>card Vida Crediticia"] --> Consent{"consentimiento-hipotecario<br/>perfilamiento"}
  Consent -->|"No otorgar"| Inicio
  Consent -->|"Otorgar"| Adaptador["HU-54 adaptadores<br/>Open Finance / Open Data"]
  Adaptador -->|"responde a tiempo"| OfertaOk["oferta-hipotecario"]
  Adaptador -->|"falla o excede el limite"| OfertaDeg["oferta-hipotecario<br/>banner de degradacion"]
  OfertaOk -->|"Aceptar"| Emision["emision HU-20"]
  OfertaDeg -->|"Aceptar"| Emision

  classDef degradado fill:#ffdad6,stroke:#ba1a1a,color:#410002
  class OfertaDeg degradado

Sin consentimiento no se invoca ningún adaptador. Si el perfilamiento se degrada (HU-56), la oferta se entrega igual con valor de respaldo y el banner lo advierte: la degradación nunca es silenciosa ni cancela la originación.

flowchart TB
  Login["login"] --> Inicio["inicio"]

  Inicio --> Polizas["lista-polizas"]
  Inicio --> Siniestros["lista-siniestros"]
  Inicio --> Perfil["hub-perfil"]
  Inicio -->|"CTA Nueva cotizacion"| Cotizar["nueva-cotizacion"]

  Polizas --> Detalle["detalle-poliza<br/>solo lectura"]
  Detalle --> AvisoV["aviso-vencimiento"]
  Detalle --> AvisoR["aviso-renovacion"]

  Siniestros --> AvisoS["aviso-siniestro"]
  AvisoS --> Evidencia["evidencia-siniestro<br/>archivo adjunto"]
  Evidencia -->|"Usar ubicacion del navegador"| Prompt{"overlay-ubicacion-navegador"}
  Prompt -->|"Permitir"| Geo["evidencia-siniestro-geo"]
  Prompt -->|"Bloquear"| Evidencia

  Perfil --> Overlays["overlays: idioma,<br/>consentimientos, cerrar sesion"]

  Cotizar --> Oferta["ver-oferta"]
  Oferta -->|"Aceptar"| Emision["emision-progreso"]
  Emision --> Emitida["poliza-emitida"]
  Emitida --> Detalle

  classDef navOff fill:#ffdad6,stroke:#ba1a1a,color:#410002
  classDef overlay fill:#ebeeee,stroke:#6e7979,color:#181c1c
  class Emision,Emitida navOff
  class Prompt,Overlays overlay

En 390 el TopNav colapsa a hamburger → nav-menu / 390, con los mismos cuatro destinos. Los overlays son diálogos que cierran con Close, no rutas: no empujan el historial.

Diferencia con Android: aquí la evidencia es un archivo adjunto y la ubicación usa el prompt del navegador, no el permiso del sistema operativo.

flowchart TB
  BoLogin["bo-login"] --> Shell["shell-asesor<br/>Mi cartera: KPIs + cola"]

  Shell --> Clientes["Clientes"]
  Shell --> Cotizaciones["Cotizaciones"]
  Shell --> PolizasBO["Polizas"]
  Shell --> Avisos["Avisos"]

  Clientes --> ListaCli["lista-clientes-vacia<br/>cliente-detalle"]
  ListaCli --> FormCli["cliente-form<br/>cliente-form-editar"]
  ListaCli --> Baja["cliente-baja"]

  Cotizaciones --> ListaCot["lista-cotizaciones"]
  ListaCot --> Cotiza["asesor-cotizacion<br/>5 variantes por ramo"]
  Cotiza -->|"dato invalido"| CotErr["asesor-cotizacion-error<br/>CTA bloqueado"]
  CotErr --> Cotiza
  Cotiza -->|"Continuar a emision"| EmisionBO["asesor-emision<br/>stepper"]
  EmisionBO -->|"aprobada"| PolizaOk["poliza emitida"]
  EmisionBO -->|"rechazada"| EmisionRech["asesor-emision-rechazo"]

  PolizasBO --> ListaPol["lista-polizas"]
  ListaPol --> Renovar["bo-renovar-poliza"]
  ListaPol --> Cancelar["bo-cancelar-poliza"]
  Renovar -->|"no vigente"| RenovarNo["bo-renovar-no-vigente<br/>bloqueo"]
  Cancelar -->|"ya cancelada"| CancelarNo["bo-cancelar-ya-cancelada<br/>bloqueo"]

  Avisos --> Cola["bo-cola-avisos<br/>bo-cola-avisos-vacia"]
  Cola -->|"Rechazar"| Decision{"bo-aviso-decision<br/>modal sobre la cola"}
  Decision -->|"sin motivo"| SinMotivo["bo-aviso-decision-sin-motivo<br/>CTA deshabilitado"]
  SinMotivo --> Decision
  Decision -->|"con motivo"| Cola
  Cola -->|"Aprobar"| Pago["bo-pago-parametrico"]
  Pago -->|"reintento misma clave"| Reintento["bo-pago-reintento<br/>mismo comprobante"]

  Shell -.->|"rol sin permiso"| SinPermiso["shell-asesor-sin-permiso<br/>conserva el shell"]

  classDef bloqueo fill:#ffdad6,stroke:#ba1a1a,color:#410002
  classDef modal fill:#ebeeee,stroke:#6e7979,color:#181c1c
  class CotErr,RenovarNo,CancelarNo,SinMotivo,SinPermiso bloqueo
  class Decision modal

Los nodos en rojo son bloqueos de negocio, no errores técnicos: el CTA queda deshabilitado y la pantalla explica por qué, con una salida alternativa. shell-asesor-sin-permiso conserva el TopNavAdmin y solo sustituye el contenido — es la consecuencia visible de la autorización del servidor (HU-75), no su implementación.

A diferencia del cliente, el asesor conserva la navegación durante la emisión: puede atender otro caso sin perder el progreso.

Los canales no son la misma interfaz redimensionada. Estas diferencias son deliberadas y se validan con pruebas de regresión visual.

Ni el cliente web ni el móvil tienen campana de notificaciones ni destinos Open Finance / Risk Analysis.

Tokens como código. La colección Color tiene modos Light/Dark: en Android se exporta a Theme.kt / colors.xml (values-night), y en web a custom properties bajo prefers-color-scheme. El valor nunca se escribe a mano en un componente.

1. El canal formatea, el núcleo no. El núcleo entrega prima y código de moneda; NumberFormat / Intl aplican el locale. Cambiar de locale no cambia la prima.
2. El canal no inventa estado. Emisión, suscripción y siniestro muestran el estado real del núcleo. Si el núcleo rechazó, nunca se muestra «emitida».
3. Idempotencia visible. Reintentar un pago o un aviso devuelve el mismo comprobante o siniestroId; la UI lo comunica en vez de ocultarlo.
4. Autorización en el servidor. Ocultar un botón no es un control: shell-asesor-sin-permiso refleja lo que el servidor ya denegó (HU-75).
5. Estado nunca solo por color, y contraste AA en los pares del design system.
6. Permisos JIT, nunca en splash, y denegar jamás bloquea el recorrido.

El canal web consume :BFFWeb y el móvil :BFFMovil; ninguno llama al núcleo directamente. Cada BFF valida el JWT que emite ms-identidad y expone payloads pensados para su pantalla — el móvil los lleva acotados por operar en redes variables. Ver Vista funcional y Backlog BFF.

• Portal de socio (aliados): no diseñado.
• Back-office en 768 / 390: es herramienta de escritorio.
• axe-core y TalkBack no corren sobre Figma; la verificación automatizada queda para el canal implementado (PF2).
• Modo oscuro: los tokens existen en ambos modos, pero las pantallas están compuestas en Light.