Casos de estudio reales

Banco del Sol es un banco 100% digital argentino. Entré al equipo con ownership sobre la cuenta general y sus flujos principales. Al tomar ownership del producto de tarjeta, encontré el problema más relevante del producto: la tarjeta de débito física era el centro del onboarding, el primer objeto que recibía un usuario nuevo y la tarjeta que el banco promovía por defecto. La tarjeta virtual existía, pero nadie la promovía activamente. Era un feature secundario que los usuarios encontraban por accidente.

El modelo de tarjeta física tiene costos reales y crecientes: impresión, personalización, envío postal, reposición por pérdida o robo, soporte por blanqueo de PIN en cajero. Cada tarjeta física emitida representa un costo logístico concreto, y con el crecimiento de la base de usuarios, ese costo escalaba.

Al mismo tiempo, el contexto regulatorio en Argentina empezaba a cuestionar la obligatoriedad de emitir plástico para productos que podían funcionar completamente de forma digital.

El problema de fondo no era técnico ni regulatorio. Era de modelo: la tarjeta física se emitía automáticamente al abrir una cuenta, sin que el usuario la pidiera. Eso lo convertía en el producto por defecto y dejaba a la virtual en un rol provisorio.

Tuve ownership completo del producto de tarjeta, desde la definición del problema hasta la entrega. Participé activamente en las conversaciones con compliance para entender qué regulaciones aplican a la emisión de tarjetas de débito en Argentina, qué era obligatorio en plástico y qué podía resolverse digitalmente. Ese trabajo fue la condición de posibilidad del proyecto, sin entender el marco regulatorio no podíamos cambiar el modelo de emisión.

Analicé cómo operaban otros productos fintech que ya habían hecho este cambio: Mercado Pago, Ualá, Revolut. En todos los casos, la clave no era tecnológica sino de jerarquía de producto: la tarjeta virtual era el producto principal, con su propia identidad visual y flujo dedicado.

El estado que encontré era el opuesto: el flujo llevaba al usuario a la tarjeta física, y desde ahí podía activar la virtual como una opción más. Esa jerarquía comunicaba inadvertidamente que la virtual era secundaria.

La decisión más importante no fue de diseño. Fue de producto: convencer a las cabezas de la empresa de que la tarjeta física no debía emitirse automáticamente al abrir una cuenta. El modelo que encontré era usuario nuevo → cuenta abierta → tarjeta física emitida y en camino. Cambiar eso requirió trabajar el argumento desde el lado regulatorio, desde el costo operativo y desde la experiencia de usuario.

El nuevo modelo: usuario nuevo → cuenta abierta → tarjeta virtual activa por defecto → tarjeta física disponible solo si el usuario la solicita, con un flujo deliberadamente friccionado. Ese paso de fricción no es un error de diseño. Es la señal de que el usuario tomó una decisión consciente, no la consecuencia automática de abrir una cuenta.

Una vez resuelto el modelo de emisión, diseñé los estados del sistema: la tarjeta virtual como producto principal con su propio flujo, el estado de coexistencia cuando la física está en camino, y el sistema de seguimiento del envío postal para que la espera no hiciera sentir que la virtual era provisoria.

La decisión técnica más significativa dentro del producto fue el reveal con timer para los datos sensibles. La tensión principal de una tarjeta virtual es la seguridad del número, la fecha y el CVV. Analicé tres alternativas.

Bitso es el exchange de criptomonedas más grande de América Latina, con más de 8 millones de usuarios activos en México, Argentina y Brasil. El tab Cripto es una de las superficies de mayor tráfico de la app: el lugar donde los usuarios exploran el mercado, descubren nuevos assets y toman decisiones de trading. La sección 'New listings' era la vidriera de los assets recién listados, alta relevancia estratégica para el negocio porque un nuevo asset exitoso genera volumen de trading.

La sección existía pero tenía bajo engagement. Los usuarios la veían en el scroll pero no interactuaban, no entraban a ver el detalle, no la exploraban, no operaban. Había una desconexión entre la relevancia que el negocio le asignaba a los nuevos listings y el comportamiento real de los usuarios.

La pregunta era: ¿por qué? ¿Era un problema de visibilidad, de información, o de diseño?

Fui el Product Designer responsable del experimento completo. Formulé las hipótesis, diseñé las tres variantes, definí las métricas de éxito y analicé los resultados junto al equipo de data. El test corrió sobre el 100% del tráfico del tab Cripto, 8 millones de usuarios activos.

Antes de diseñar, analicé el comportamiento del usuario en la sección con los datos disponibles. El patrón era claro: los usuarios hacían scroll sobre las cards sin detenerse. No era un problema de visibilidad, la sección estaba en el primer tercio de la pantalla.

Mi hipótesis fue que el diseño trataba los assets como datos financieros en un momento donde los usuarios los tratan como identidades culturales. En crypto, especialmente con meme coins, la decisión de explorar un asset no arranca por el precio o el rendimiento, arranca por el reconocimiento. SHIB es un perro. PEPE es un sapo. POPCAT es un meme. Si el usuario no reconoce visualmente el asset, no hay motivación para hacer tap.

El gráfico de 24h que ocupaba la mitad de la card no aportaba valor en el momento de discovery, el porcentaje de cambio ya comunicaba lo mismo de forma más directa. El gráfico era ruido visual que consumía el espacio que debería tener la identidad del asset.

Diseñé tres variantes para aislar variables. Cada una testea una hipótesis distinta: si gana la 1, el problema era de componente. Si gana la 2, era de categorización. Si gana la 3, era de identidad visual.

Bitso operó una Web3 Wallet nativa que permitía a los usuarios almacenar tokens y NFTs con control total de su llave privada. Era un producto de alta complejidad técnica orientado a usuarios avanzados del ecosistema cripto. La decisión estratégica de discontinuar el producto implicó uno de los desafíos de diseño más complejos que enfrenté: comunicar el cierre de un producto activo y conseguir que casi todos sus usuarios completaran una acción técnica crítica en un plazo definido.

La fecha límite era el 15 de enero de 2025. Todo usuario con activos en la Web3 Wallet debía exportar su llave privada antes de esa fecha o perdía acceso permanente. No había recuperación posible después del cierre.

El objetivo del negocio era alcanzar el 90% de tasa de exportación exitosa, uno de los benchmarks más exigentes que puede tener un flujo de producto. Para ponerlo en contexto: 90% de éxito en una acción técnica compleja, con usuarios que en muchos casos nunca habían interactuado con llaves privadas, frases semilla o archivos de keystore.

El riesgo de diseñar mal este flujo no era una métrica baja, era la pérdida permanente de activos reales de usuarios reales.

Diseñé el sistema completo de comunicación y exportación. Desde el primer punto de contacto, el banner en el home de la Web3 Wallet con fecha límite visible, hasta el estado de error cuando la exportación fallaba.

Las decisiones más difíciles fueron sobre la exportación en sí: qué formato de archivo ofrecer al usuario, cómo nombrar el archivo descargado para que el usuario lo identificara y no lo perdiera, cómo estructurar la confirmación de que el proceso había sido exitoso, y cómo manejar los errores sin generar pánico.

El mayor riesgo del flujo no era técnico, era cognitivo. Un usuario en pánico comete errores. Y en un flujo donde un error puede significar pérdida permanente de activos, el diseño tenía que hacer dos cosas aparentemente contradictorias: transmitir urgencia, hay una fecha límite, sin generar ansiedad paralizante, que lleva a postergar o a cometer errores.

La solución fue disclosure progresivo: cada pantalla daba exactamente la información que el usuario necesitaba en ese momento del flujo, no más, no menos.

Diseñé dos variantes del banner de entrada para capturar dos tipos de usuario: el que responde a urgencia y el que necesita contexto antes de actuar. El checkbox en la pantalla de exportación fue fricción deliberada: en un flujo donde la velocidad es un riesgo, alguien que exporta sin entender puede perder el archivo o no guardarlo en un lugar seguro, agregar un paso de confirmación explícita reduce ese riesgo.

Agripay es una plataforma fintech diseñada específicamente para el sector agropecuario argentino: productores, corredores y empresas del campo. No es una app de inversiones. Es una plataforma de gestión agrícola: billetera de pesos y granos, cobros, documentos, pizarras de precios de commodities, logística.

Las inversiones eran un módulo nuevo. La oportunidad era integrar los Fondos Comunes de Inversión de Galicia (FIMA) directamente en la plataforma, permitir a los productores invertir sus excedentes sin salir de la app que ya usaban para gestionar su negocio.

El desafío era doble y las dos partes eran igualmente críticas.

Por un lado, la regulación: integrar productos financieros de Galicia Banco requería respetar estrictamente los requisitos de disclosure regulatorio, términos y condiciones, composición de cartera exacta, rendimientos históricos, advertencias legales. Cada pantalla tenía que ser validada con el equipo legal de Galicia. No había margen para simplificar lo que la regulación exigía mostrar.

Por otro lado, el usuario: un productor agropecuario que usa la app para gestionar cosechas, no para invertir. Alguien que entiende de soja, maíz y dólares MEP, pero para quien FCI, TNA y patrimonio total son conceptos abstractos que generan más distancia que confianza.

Fui Lead Product Designer del módulo completo. Lideré un equipo de tres: un diseñador UX y una diseñadora UI. Coordiné directamente con el equipo legal de Galicia para validar el cumplimiento regulatorio de cada pantalla. Definí la arquitectura del flujo: perfilado de inversor, visualización de cartera, detalle de cada fondo, suscripción y rescate, y calculadora de inversiones.

La pregunta central que guió todo el diseño fue: ¿cómo le explico inversiones a alguien que piensa en cosechas?

La respuesta no era simplificar el producto, era traducirlo. No eliminar la información regulatoria que Galicia requería, sino contextualizarla en el mundo del usuario.

Analicé cómo otros productos financieros habían resuelto la tensión entre regulación y accesibilidad. El patrón que encontré: los productos que funcionan separan claramente el lenguaje regulatorio obligatorio, que tiene que estar pero puede estar en un nivel de profundidad al que el usuario accede si quiere, del lenguaje de producto, que tiene que hablar el idioma del usuario.

La decisión más importante fue el tono del sistema de perfilado. El perfil 'Moderado' podría haber dicho: 'Inversor con tolerancia media al riesgo que busca rentabilidad balanceada'. Dice: 'Explorás nuevas oportunidades en el campo financiero. Equilibrás riesgo y recompensa, como un mate bien cebado, cosechando con inteligencia y audacia.'

Eso no es un accidente. Es investigación de usuario aplicada al copywriting. Un productor agropecuario entiende inmediatamente qué es un mate bien cebado: el nivel de preparación, el equilibrio, el tiempo que requiere. Es la misma metáfora que necesitaba para entender su perfil de inversor.

La calculadora de inversiones convierte porcentajes en pesos propios, la unidad de medida que el usuario entiende y en la que piensa su negocio.

Bitso lanzó un proceso de rebrand que redefinió su identidad visual completa: nueva paleta, nueva tipografía, nueva iconografía y un sistema de diseño unificado. El desafío no era solo definir el nuevo lenguaje visual, sino aplicarlo sobre un producto vivo, con 8 millones de usuarios activos en tres países, sin generar regresiones ni romper los modelos mentales que los usuarios ya habían construido durante años.

El crecimiento acelerado de Bitso dejó deuda visual acumulada en el producto. Distintos squads habían aplicado componentes y estilos de forma independiente, generando inconsistencias entre superficies y plataformas. El rebrand fue la oportunidad de resolver esa deuda de forma sistémica.

Pero resolver deuda visual en un producto activo tiene un riesgo real: cambiar lo suficiente para que el sistema sea coherente, sin cambiar tanto como para desorientar al usuario que ya conoce el producto. La pregunta que guió el trabajo fue: ¿cómo renovamos la identidad sin que el usuario sienta que le cambiamos la app?

Fui Product Designer responsable de la migración de las superficies principales del flujo de home y trading al nuevo sistema de diseño. Trabajé en coordinación directa con el equipo de brand design y con los otros product squads para garantizar consistencia cross-platform durante el proceso de rollout.

Antes de diseñar pantallas nuevas, realizamos un audit completo de los componentes existentes: cuáles estaban fuera de spec, cuáles tenían variantes no documentadas y cuáles podían migrarse directamente al nuevo sistema sin rediseño. Ese audit fue la condición de posibilidad del rebrand: sin saber exactamente qué tenías, no podías saber qué cambiar ni cuánto tiempo tomaría.

Definimos dos principios que guiaron todas las decisiones del proceso. El primero: jerarquía antes que estética. El rebrand cambiaba el lenguaje visual pero no podía cambiar los modelos mentales del usuario. Lo que era primario tenía que seguir siendo visualmente primario. Un usuario de Bitso que vuelve a la app después de la actualización no debería necesitar reaprender a navegar.

La decisión más importante fue la estrategia de migración: componentes primero, pantallas después. Reconstruir cada componente en el nuevo sistema y luego componer las pantallas desde ahí, en lugar de rediseñar pantallas enteras de cero. Eso redujo el riesgo de regresión y garantizó que cualquier cambio derivara del sistema, no de decisiones individuales de diseño.

La migración a design tokens fue el instrumento más crítico del proceso. Pasar de valores absolutos (colores en hex) a tokens semánticos (primary-action, surface-default, text-muted) fue la decisión que permitió escalar el rebrand a todos los squads sin requerir coordinación constante. Con tokens, cada squad podía actualizar sus pantallas de forma independiente y el resultado seguía siendo coherente.

Dos proyectos separados en dos empresas distintas, pero estructuralmente idénticos en lo que exigían: integrar sistemas de pago complejos de terceros — cada uno con su propio protocolo, marco regulatorio y modelo mental del usuario — en productos que no fueron diseñados originalmente alrededor de ellos.

PIX es el sistema de pagos instantáneos de Brasil, operado por el Banco Central do Brasil y adoptado por más de 140 millones de brasileños. Integrarlo en Bitso significó construir el primer puente entre el ecosistema crypto-nativo de Bitso y la infraestructura financiera formal de Brasil, un país donde PIX se convirtió en el rail de pago dominante en transacciones cotidianas.

MODO es la plataforma de pagos digitales interoperable de Argentina, usada por más de 20 bancos argentinos. Integrarlo en Banco del Sol significó permitir que los usuarios paguen en comercios físicos y online directamente desde la app, usando la misma infraestructura de QR que el resto del sistema bancario argentino ya operaba.

En ambos casos el problema central era el mismo: ¿cómo traés un protocolo de pago que los usuarios ya conocen de otro contexto a un producto donde su modelo mental es completamente distinto?

Un usuario de Bitso no piensa en la app como un lugar para pagar, la piensa como un lugar para operar y guardar crypto. Introducir PIX significaba extender el producto a un territorio que el usuario nunca asoció con Bitso. El riesgo de confusión era real: ¿entendería el usuario que ahora podía recibir y enviar reales brasileños via PIX desde un exchange cripto?

En Banco del Sol el desafío era diferente: los usuarios de BDS ya esperaban poder pagar desde la app. El problema era sumarlos al protocolo MODO, un sistema con su propio formato de QR, su propio flujo de autorización y sus propios estados de error, sin que se sintiera ajeno dentro de una app que ya había establecido sus propios patrones de interacción.

En ambos proyectos fui el Product Designer responsable de la experiencia completa de pago: desde el entry point y el discovery hasta los estados de confirmación, el manejo de errores y el diseño de los comprobantes.

Ambas integraciones requirieron coordinación estrecha con los equipos de compliance de ambos lados. Los protocolos de pago tienen requisitos regulatorios estrictos: qué información es obligatoria antes de la autorización del pago, cómo enmarcar las pantallas de confirmación, qué debe incluir el comprobante digital y qué límites de transacción aplican por usuario, por día y por país.

El enfoque de diseño en ambos casos siguió el mismo principio: no le pedís al usuario que se adapte al protocolo de pago. Adaptás el entry point, el lenguaje y el patrón de confirmación del protocolo a la lógica existente del producto.

Para PIX en Bitso: el entry point se ancló al concepto familiar de la billetera, los usuarios ya sabían cómo recibir y enviar activos. El diseño extendió ese modelo mental para incluir BRL via PIX, sin introducir un paradigma nuevo. Las claves PIX, los QR y la confirmación instantánea se presentaron usando el lenguaje de patrones que Bitso ya tenía establecido.

Para MODO en BDS: el entry point se posicionó en los flujos de pago que el usuario ya conocía, el mismo lugar donde esperaría pagar o transferir. El protocolo QR de MODO se envolvió en los mismos patrones de interacción que BDS había establecido para otras acciones de pago, haciendo que la nueva capacidad se sintiera como una extensión natural y no como un feature nuevo a aprender.

Ambas integraciones tenían requisitos de compliance complejos que formaron directamente las decisiones de diseño. Para PIX: el Banco Central do Brasil exige requisitos de disclosure específicos para transacciones de pago instantáneo, incluyendo límites por tipo de usuario y ventana horaria, patrones de confirmación obligatorios y formatos de comprobante exactos. Para MODO: el marco regulatorio argentino para pagos interoperables exigía flujos de autorización específicos, visualización de límites por tier de usuario e información clara de categoría de comercio en la vista de transacción.

En ambos casos, los requisitos de compliance no fueron un filtro post-diseño, fueron inputs de arquitectura que moldearon la estructura del flujo desde la primera decisión.