Workflow de autorización de operaciones
Diseñé una plataforma para centralizar y automatizar procesos internos de autorización, reduciendo la fricción operativa entre múltiples áreas.
Mi rol: Senior Product Designer
Duración: 12 meses
Herramientas: Figma · Miro
Equipo: Product Manager · Business Process Engineering · Backend · Frontend · Stakeholders de negocio
El reto
Contexto
Esta iniciativa formó parte de un programa de transformación digital para actualizar procesos internos relacionados con la contratación de productos financieros.
Problema
Antes del proyecto, las solicitudes de revisión documental y autorizaciones se gestionaban mediante correos electrónicos y plataformas aisladas, provocando una experiencia fragmentada para los equipos internos, comunicación aislada y falta de trazabilidad de las operaciones y sus estados.
Objetivos
Centralizar la gestión de autorizaciones en una única experiencia
Reducir tiempos de gestión de operacionesObtener trazabilidad de las operaciones y el proceso
Entendiendo el problema
Durante el Discovery identificamos cuatro problemas principales.
Procesos fragmentados
Los usuarios alternan constantemente entre diferentes plataformas para completar una sola operación.
Documentación duplicada
Era necesario descargar documentos desde uno o varios sistemas y volver a cargarlos manualmente en otros.
Proceso aislado
La solución se visualizó como una iniciativa independiente. Descubrimos que es parte de un macro proceso y teníamos que estar alineados con éste y otros proyectos.
Autogestión aislada
Los líderes de áreas validadoras realizaban gestión manual de las operaciones en herramientas aisladas y con dependencia de equipos técnicos.
Un proceso aislado
La solución debía integrarse dentro de un proceso mayor, involucrando múltiples áreas del banco.
El desafío de diseño
Restricciones técnicas
El backend permitía únicamente flujos lineales y limitaba la gestión simultánea entre departamentos.
Dependencias
El proyecto dependía de otras iniciativas que evolucionaban en paralelo y de funcionalidades que aún no existían.
Mi rol como Product Designer
〰️
Mi rol como Product Designer 〰️
Discovery
Workshops de entendimiento con negocio
Mapeo de procesos AS-IS
Entrevistas con usuarios y stakeholders
Identificación y presentación de riesgos
Diseño
Wireframes y prototipos
Diseño de experiencias para tres perfiles
Colaboración con Design System y Content Strategist
Handoff y seguimiento con equipo de desarrollo
Definición
Facilitación de workshops TO-BE
Arquitectura de información
Priorización de funcionalidades
Definición de flujos
Validación
Pruebas de usabilidad
Evaluación SUS
Design Quality Assurance
Ajustes iterativos
Los usuarios
-

SOLICITANTE
OBJETIVO
Obtener aprobaciones de áreas internas
NECESIDAD
Tener la información lo más actualizada posible para avanzar en sus procesos
-

GESTOR
OBJETIVO
Revisar y aprobar documentos y operaciones
NECESIDAD
Revisar la documentación rápidamente
-

ADMINISTRADOR
OBJETIVO
Gestionar la capacidad operativa con estándares de calidad y nivel de servicio
NECESIDAD
Asignar las tareas de forma balanceada y eficaz
Decisiones de producto
¿Qué descubrimos?
〰️
¿Qué decisión tomamos?
〰️
¿Por qué?
〰️
¿Qué valor generamos?
〰️
¿Qué descubrimos? 〰️ ¿Qué decisión tomamos? 〰️ ¿Por qué? 〰️ ¿Qué valor generamos? 〰️
Después de las sesiones de entendimiento, en conjunto con los Stakeholders y equipo técnico se tomaron estas principales decisiones
Mantener plataformas familiares
Hallazgo
Los usuarios ya operaban diariamente dentro de determinados sistemas.
Decisión
Integrar el Workflow dentro de esas plataformas.
Razón
Reducir curva de aprendizaje y acelerar adopción.
Visualización de documentos
Hallazgo
Se necesita además, revisar cierta documentación por tipo de solicitud
Decisión
Habilitar el filtrado de documentos desde de una herramienta transversal
Razón
Evitar ruptura de flujos y tareas del usuario.
Integración a proceso principal
Hallazgo
La iniciativa no es una solución aislada, forma parte de un macro proceso
Decisión
Alineación con el proceso principal para la integración del workflow
Razón
A nivel experiencia de usuario buscamos tener todo el flujo unificado en una sola plataforma.
Priorizar el MVP
Hallazgo
El alcance inicial contemplaba 14 operaciones a desarrollar.
Decisión
Reducir el MVP a tres operaciones críticas.
Razón
Permitir una salida temprana sin comprometer los objetivos principales del negocio.
Trade-offs
Las pruebas de usabilidad mostraron que los usuarios esperaban gestionar documentos desde la misma operación.
Debido a restricciones técnicas de un proyecto dependiente, esta funcionalidad quedó fuera del MVP y se incorporó al backlog como oportunidad futura.
Idealmente las operaciones debían asignarse automáticamente.
Sin embargo, debido a restricciones del MVP y prioridades del roadmap, se decidió implementar un modelo manual que permitiera lanzar la solución sin retrasar el proyecto.
Gestión documental
Asignación manual
La solución
Plataforma para solicitantes
Integración a proceso principal
Habilitación de paneles de operación dentro del caso específico del cliente.
Actualización del estado de las operaciones en tiempo real
Se introdujo un historial de mensajería con área validadora
Plataforma para gestores
Se crearon bandejas operativas avanzadas
Se dio acceso a la documentación mínima necesaria para las operaciones.
Seguimiento del historial de comentarios con el solicitante.
Impacto
RESULTADOS CUALITATIVOS
Los usuarios calificaron las solución como más intuitiva
Disminuyó la incertidumbre durante el proceso
Se redujo el retrabajo de carga de documentación
RESULTADOS PARA NEGOCIO
Consolidación de procesos en una única plataforma
Reducción del 12.28% de tiempo de jornada operativa
Migración del 20% de la operativa actual
Adopción del 15% en el primer trimestre de implementación
Aprendizajes
El diseño de procesos complejos implica entender los requerimientos de negocio y alinearlos con las necesidades de los usuarios. Tuve la oportunidad de desarrollar la habilidad de comunicar efectivamente riesgos y puntos de dolor desde la experiencia de usuario y cómo implica a su vez riesgos para los objetivos del negocio.
Pude establecer conversaciones, debates y colaboración constante con stakeholders y equipo técnico para equilibrar necesidades de usuario, viabilidad técnica y objetivos del programa. Donde también adquirí una visión diferente sobre los Trade-offs técnicos, éstos deben convertirse en decisiones explícitas de producto, no en limitaciones ocultas.
Por último amplié mi visión como una diseñadora de producto más estratégica, gracias a la implementación del pensamiento sistémico para alinear más de una iniciativa hacia los mismos objetivos.