Antes: 6 sistemas desconectados · Después: onboarding unificado + marketplace de productos
Seis sistemas desconectados que un ejecutivo de sucursal operaba en paralelo, convertidos en una sola herramienta de originación omnicanal. Liderado desde adentro cuando el director de diseño salió — con un equipo de menos de un mes de formación.
Octubre 2019: soy promovido a UX manager de productos digitales. Noviembre 2019: llega un nuevo DGA con una visión clara, unificar los sistemas de originación del banco, empezando por sucursales. Enero 2020: el Director de UX sale de Scotiabank.
En ese momento, uno de los proyectos más ambiciosos de la Dirección de Banca Digital de Scotabank no tenía director de diseño. Tenía un equipo con menos de un mes de formación, un roadmap de cuatro Program Increments, y yo como el punto de contacto entre diseño, producto y tecnología.
Mi trabajo en OneBank tuvo dos dimensiones inseparables: diseñar el sistema y construir el equipo que lo haría posible. Ninguna de las dos podía esperar a que la otra terminara.
Fungí como director de diseño interino — trabajando codo a codo con los directores de producto y tecnología, reportando la estrategia directamente al DGA — hasta que llegó el nuevo director de diseño.
No era el plan. Pero lo que necesitabamos.
El estado actual de la originación en sucursal era, en la práctica, un problema de ventanilla. Cuando un ejecutivo quería abrir una cuenta, ofrecer una tarjeta de crédito o vender un seguro, tenía que navegar entre múltiples herramientas: SIC, TOTAL VIEW, eIAP, SEA, COUNSELOR, SCOTIA PRO. Sistemas que no se comunicaban entre sí, con lógicas distintas, y que pedían la misma información del cliente una y otra vez.
Los datos del banco revelaban algo que cambiaba completamente la conversación estratégica. El 65% de las ventas ocurrían en sucursal. Solo el 20% eran ventas digitales, uno de nuetros KPI como banca digital. El 15% restante era call center y otros canales.
Si desarrollábamos soluciones para la sucursal, las ventas de sucrusal se convertiria en ventas digitales y pasarían del 20% al 85%. La sucursal era el canal más poderoso que el banco tenía, y estaba siendo subatendido por sistemas fragentados.
Pero detrás de ese número había un problema más profundo. Los sistemas legacy generaban fricción en el día a día de los ejecutivos de cuenta, y esa fricción tenía un costo visible para los clientes: más tiempo de espera. Un rediseño completo de la experiencia digital era la palanca para resolver ambas cosas al mismo tiempo.
Coordinado con el área de research realizamos workshops con 16 ejecutivos de 5 territorios — con experiencias que iban desde menos de un año hasta más de once — confirmaron el problema con claridad brutal. los sistemas no era eifcientes, el ejecutivo sabia lidiar con ellos, pero eso se traducia en más tiempo para cada proceso.
Los hallazgos se dividieron en dos sets que estructuraron todo el diseño posterior: lo que dolía hoy, y cómo imaginaban que debería funcionar una herramienta que realmente los ayudara.
"Tengo que tener varios sistemas abiertos y cuando uno falla debo reiniciar la maquina"
"Que se pueda tomar información ya capturada. Poder tener un aplicativo para todo sin tener que estar cambiando o volviendo a pedir datos"
Los ejecutivos no podían moverse sin que un sistema respondiera. Un fallo en cualquier punto paralizaba la atención al cliente.
Múltiples ventanas abiertas, múltiples flujos simultáneos. La atención al cliente competía con la administración de sistemas.
Los flujos más difíciles simplemente no se usaban. La complejidad del sistema desincentivaba la venta de ciertos productos.
Los cuatro atributos que los ejecutivos describieron se convirtieron en los principios de diseño de OneBank.
Que sepa lo que el otro sabe. Que la información capturada en un punto esté disponible en todos los demás sin volver a pedirla.
Un solo aplicativo para todo. No sistemas en paralelo, no cambios de contexto, no reiniciar la máquina cuando algo falla.
Que reconozca al cliente y al ejecutivo. Que el sistema sepa quién es el cliente antes de que el ejecutivo empiece a preguntar.
Que guíe, no que obstaculice. Un sistema que reduce la carga cognitiva del ejecutivo en lugar de aumentarla.
El modelo tradicional de originación en Scotiabank era producto-primero: el cliente llegaba pidiendo una tarjeta de crédito, y el ejecutivo abría el flujo de TDC. Si ese mismo cliente quería también una cuenta, el ejecutivo abría otro flujo — y volvía a pedir nombre, RFC, domicilio, teléfono.
La pregunta que cambió el modelo fue: ¿por qué le pedimos al cliente su información en función del producto, si la información del cliente es la misma?
El ejecutivo pide datos desde cero según el producto elegido
La respuesta fue OneBank Foundational: un onboarding estructurado como módulos independientes que se componían según lo que cada producto necesitaba. Una vez completado el flujo, el cliente estaba validado — y cada producto solo pedía la información específica que requería, sin volver a preguntar lo que ya sabía.
Uno de los ejercicios más reveladores del proyecto fue mapear los formularios de todos los productos para entender qué datos tenían en común y por qué se pedía cada uno. El análisis de Insurance, N2, TDC y Pre-aprobados mostró que los datos personales eran casi idénticos en todos — pero cada producto los pedía de manera diferente, con distinto orden y distinta lógica de validación.
El caso más claro fue la identificación. La tarjeta de crédito pedía país de nacimiento, entidad federativa, sexo y vigencia del INE. Pero todos esos datos se pueden obtener de la CURP.
La decisión fue diseñar un solo camino estándar: pedir la CURP y derivar los datos. Eso que parece una desición técnica; pero en realidad es de diseño experiencia: hacer que el cliente llene menos datos y haga menos clics.
El equipo de diseño de OneBank tenía menos de un mes de haberse formado cuando arrancó el proyecto. Un Sr. UX Designer a cargo del Onboadining Foundational, dos UX Designers trabajando en tarjeta de crédito y débito, y dos Jr. UX Designers responsables de Pre-aprobados y Seguros. Completaban el equipo un UX Researcher y un Service Designer para la investigación.
Mi trabajo como lead no era diseñar. Aunque en la práctica tuve que hacerlo, mi responsabilidad real era crear las condiciones para que el equipo diseñara bien.
No para revisar entregables — para mapear necesidades individuales, detectar bloqueos antes de que se volvieran problemas, y entender cómo cada persona operaba mejor. Un Jr. designer que no sabe pedir ayuda puede frenar un sprint entero si nadie lo nota a tiempo.
Diseñadores, researcher y service designer en la misma sala revisando exploraciones, discutiendo decisiones y definiendo soluciones reutilizables. El objetivo no era solo alinear — era construir un lenguaje compartido entre todos los tracks del proyecto.
La decisión más importante de la etapa de ideación fue diseñar los patrones antes que los flujos completos. Si definíamos bien el template de un paso del stepper, los cuatro productos podían adoptarlo sin rediseñarlo. Eso fue lo que hizo posible avanzar en paralelo.
El diseño de OneBank se dividió en dos capas: el flujo foundational que unificaba el onboarding de cualquier producto, y el marketplace que aparecía una vez completado — permitiendo al ejecutivo ofrecer y contratar cualquier producto sin volver a pedir datos.
Valida si el cliente ya existe en el sistema. El campo de residencia en México aparece solo si el producto (como Seguros) lo requiere. El módulo no pregunta lo que no necesita.
Número celular y correo para validar al usuario. El número fijo aparece como campo adicional solo en TDC — invisible para los demás productos.
CURP como fuente de verdad. Los campos derivados (entidad, sexo, vigencia del INE) se pre-llenan automáticamente o se omiten según el producto. Dos caminos: CURP primero o datos primero.
Estandarizado con geolocalización de Google Maps. Los campos opcionales de N2 (ciudad o poblado, tipo de domicilio) aparecen al final sin interrumpir el flujo base de los demás productos.
Comenzamos a reusar componentes y las experiencias, aún con diferencias visuales, comenzaba a ser más homogéneas en la estructura de los datos que pedíamos. Incluso se emepzo a rutilizar en los canales Web y Móvil. de manera sistemática, comenzabamos a unificar cada momento de la experiencia.
Una vez completado el onboarding, el cliente llegaba a un marketplace personalizado — no a un formulario de producto específico. El ejecutivo veía los productos pre-aprobados del cliente con líneas de crédito ya calculadas, y podía iniciar la contratación de cualquiera sin volver a pedir datos.
El MVP mostraba la lista de productos. El Release 2 agregó los pre-aprobados en primer plano, el perfil del cliente con productos ya contratados, y una navegación por categorías: Tarjetas, Cuentas, Seguros, Préstamos.
La pantalla del ejecutivo y la del cliente convergían en la misma sesión. El banco como marketplace personalizado para cada cliente.
El mayor avance en la simplificación de formularios no vino de una decisión de diseño, vino del área de riesgo, que nos ayudó a cuestionar y revisar si ciertos campos eran realmente obligatorios por regulación o solo por costumbre.
Demostrar por qué un workshop con 16 ejecutivos era necesario antes de escribir una sola pantalla fue una conversación que tuve que dar varias veces. Los resultados lo justificaron, pero conseguir ese espacio también fue parte del trabajo.
El modelo lego de CIF + Products (OneBank foundational) fue uno de los hallazgos más valiosos del proyecto, pero emergió durante el diseño, no como punto de partida. Si lo hubiera formalizado como principio de arquitectura desde la primera semana, habría sido más fácil venderlo a producto y tecnología desde el principio.
También habría involucrado a los equipos de backend y riesgos en los workshops iniciales — no solo como validadores, sino como diseñadores del problema.
OneBank era la base de una transformación más larga. El onboarding unificado resolvía la entrada, pero el verdadero potencial estaba en lo que venía después: un ejecutivo que, terminado el onboarding, podía ofrecer cualquier producto del banco sin fricción, con información del cliente ya validada y con pre-aprobaciones calculadas en tiempo real.
Salí del banco cuando pre-aprobados estaba en proceso de implementación y TDC aún no había comenzado. La visión del Release 2 empezaba a mostrarse y compartirse. La conversación sobre cómo llegar ahí era una cuestion de negociación con T.I. del banco y los stakeholders involucrados en sucursales y los productos.