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.