Gabriela García

Todos los casos

04 / Fianzas digitales · Plataforma operativa

ASERTA

Digitalizar el alta y la emisión con una experiencia clara.

Mejora de una plataforma existente para digitalizar trámites, organizar expedientes y facilitar el trabajo operativo. El diseño conecta documentos, revisión, firma y emisión de fianzas.

Implementación incremental

  • Modal «Confirma los riesgos a garantizar» con tres riesgos editables, un selector para añadir otros y el botón «Crear solicitudes y continuar».
Reconstrucción para portafolio · datos de muestra.
Rol
Product Designer
Alcance
Alta de clientes y emisión de fianzas
Desarrollo
Por MVP · reviews después de cada sprint
Evidencia
Cortes para DEV · handoff · observaciones de frontend

El reto

Digitalizar el trámite sin trasladar su complejidad a la persona

El objetivo era digitalizar los trámites de alta y emisión, almacenar los expedientes y agilizar el trabajo con una buena experiencia. La plataforma ya existía; el rediseño abordó los recorridos, la información necesaria y las condiciones para avanzar.

El reto de experiencia era dar continuidad al proceso: organizar los documentos por participante, mostrar qué debía revisarse, permitir correcciones y explicar qué hacer ante una excepción.

Mi contribución

Del conocimiento operativo al handoff

Participé en la mejora de la experiencia de una plataforma existente. Mi trabajo comenzó al traducir la exploración operativa del área de negocio a una lectura accionable para diseño: actores, documentos, reglas, excepciones y dependencias.

Participé en el diseño de los recorridos de Alta y Emisión, con sus estados y excepciones, y en el acompañamiento del desarrollo por MVP: cortes para DEV, notas de handoff y observaciones de frontend en las reviews posteriores a cada sprint.

Propuesta de valor

Etapas, revisiones y recuperación claras

Digitalizar Alta y Emisión, organizar expedientes y dar continuidad al trabajo mediante etapas, revisiones y recuperación de errores claras.

Decisiones y evidencia

Hacer legible un flujo con reglas y excepciones

Exploración operativa como punto de partida

El área de negocio había realizado una exploración previa del proceso operativo. Ese conocimiento fue la base para comprender el trámite antes de intervenir la interfaz.

  1. 01 · Exploración de negocio

    Antecedentes del proceso, necesidades operativas y puntos críticos.

  2. 02 · Transferencia a diseño

    Sesiones para hacer explícitos lenguaje, roles, reglas y casos límite.

  3. 03 · Modelo del proceso

    Etapas, decisiones, documentos y responsables conectados en un recorrido.

  4. 04 · Diseño de flujos

    Pantallas, estados, recuperación y handoff alineados con la operación.

Diseñar una plataforma operativa exigía modelar el sistema, no sólo las pantallas

  • Actor

    Solicitante, participantes y áreas internas.

  • Expediente

    Documentos, vigencia y estado de revisión.

  • Regla

    Qué habilita, bloquea o solicita autorización.

  • Recuperación

    Cómo corregir, guardar y retomar.

Síntesis para portafolio. Los ejemplos visuales del caso utilizan información de muestra.

Alta · Dar contexto a cada etapa

La navegación distingue carga, cotejo, resumen y firma. Los documentos se agrupan por participante, con las acciones de carga junto a cada requisito. La propuesta hace visibles las etapas y la documentación pendiente.

Pantalla de Alta con las etapas Carga de documentos, Cotejo, Resumen y Firma; los documentos del fiado aparecen agrupados, con una acción para subir cada requisito.

Alta · reconstrucción de la carga de documentos a partir del diseño original, con datos de muestra y tipografía adaptada.

Emisión · Mantener la revisión humana dentro del flujo

La secuencia conecta el documento fuente con riesgos y textos, vista previa y emisión. El documento y la información interpretada se presentan en la misma pantalla, con opciones para editar datos, volver a leer el documento o sustituirlo. La información extraída es un punto de partida que la persona revisa y corrige.

Pantalla de Emisión con un documento fuente de muestra a la izquierda y los datos interpretados del beneficiario y del documento a la derecha, con opciones para volver a leer o volver a subir.

Emisión · reconstrucción para portafolio. Documento y datos sustituidos por muestras; tipografía adaptada.

Modal «Confirma los riesgos a garantizar» con tres riesgos editables, un selector para añadir otros y el botón «Crear solicitudes y continuar».

Revisión antes de continuar

Los riesgos detectados en el documento aparecen como una lista editable. La persona puede eliminar los que no correspondan o añadir otros antes de crear las solicitudes.

Reconstrucción de la confirmación de riesgos. Datos de muestra, sin códigos internos.

Excepciones · Diseñar también lo que puede salir mal

Los archivos contemplan documentación incompleta, inconsistencias, solicitudes de corrección, esperas y fallos en distintas etapas. Cada pieza define qué información recibe la persona y qué acción tiene disponible.

Modal «Corrección de información» con un campo para describir el dato a corregir y los botones Cancelar y Enviar.
Corrección durante la firma Si la persona encuentra un dato incorrecto, puede describirlo y enviar una solicitud de corrección sin abandonar el proceso.
Modal «Autorizaciones requeridas» con motivos de muestra y los botones «Dejar pendiente» y «Solicitar autorización».
Autorización requerida Cuando una condición impide emitir, el modal explica el motivo y ofrece dos caminos: dejar la operación pendiente o solicitar la autorización.

Reconstrucciones de Alta y Emisión. Motivos y sistema generalizados.

Handoff · Especificar el comportamiento para desarrollo

El diseño acompañó el desarrollo por MVP y las reviews posteriores a cada sprint. Los cortes para DEV y las observaciones de frontend conservaron decisiones sobre campos, acciones, condiciones y estados, dando continuidad al trabajo más allá de la entrega inicial.

Nota de handoff «Modal · Confirmación de riesgos»: describe el contenido del modal, sus acciones y cuándo se habilita el botón principal.

Del diseño al comportamiento

La nota acompaña a la pantalla y especifica qué contiene el modal, qué hace cada acción y en qué condiciones el botón principal se habilita o se desactiva.

Extracto adaptado de una nota de handoff del archivo de Emisión. Se omitieron los nombres de sistemas internos.

Impacto y alcance real

Del proceso operativo a una implementación incremental

El desarrollo se realizó por MVP, con reviews después de cada sprint. Los flujos y sus reglas se llevaron a una implementación incremental; el handoff y las observaciones de frontend documentan la continuidad entre diseño y desarrollo.

Evidencia de implementación

Alta
Corte para DEV · 18 dic 2024
Emisión
Cortes para DEV · 1 abr y 9 jun 2025
Proceso
Desarrollo por MVP, con reviews al cierre de cada sprint

Aprendizajes

Las excepciones también son experiencia

Digitalizar un trámite exige definir qué se solicita, quién revisa la información y cómo se retoma el trabajo cuando aparece un error. La extracción de datos necesita una revisión humana visible y posibilidades de corrección.

Documentar correcciones, autorizaciones y cambios de estado permite llevar al handoff el comportamiento del proceso, además de sus pantallas.

Lo que no puede afirmarsepor falta de medición

Implementación incremental, impacto sin medir

  • No hay métricas posteriores a la implementación: no se atribuyen ahorros de tiempo, reducción de errores, adopción ni resultados de negocio.
  • Los cortes para DEV documentan entregas de diseño y su secuencia, no desempeño en producción.
  • Las pantallas son reconstrucciones con datos de muestra; no reproducen reglas internas ni documentos reales.