Product Design · UX Strategy · Fintech
Diseñar claridad en un sistema financiero complejo.
Plataforma white label de trading y revisión de cartera para agentes de bolsa. Mi trabajo fue definir qué pregunta responde cada módulo y diseñar la jerarquía que sostiene esa respuesta sin bloquear la operatoria.
Test vencido
Volvé a realizarlo para poder operar.
$ 12.458.320,50
+2,34% (+$ 284.120,00)
El contexto
El producto ya tenía la información correcta. Lo que faltaba era una arquitectura de lectura que ayudara a interpretarla.
Virtual Broker es un prototipo frontend white label para agentes de bolsa, orientado a trading y revisión de cartera. Contempla roles diferenciados (inversor, productor y configurador) y una demo accesible desde la vista inversor.
Al revisar el dominio, el problema no era ausencia de datos. Era superposición: cartera, saldos, movimientos, liquidado, por liquidar, futuros y flujos de operación convivían sin una regla clara de prioridad. Cada concepto es legítimo; el riesgo aparece cuando todos compiten al mismo nivel visual.
Eso convierte el trabajo de diseño en algo más parecido a modelar comprensión que a decorar pantallas. Antes de definir componentes, necesitaba responder: ¿qué necesita entender alguien en este momento? ¿qué puede esperar? ¿qué acción es crítica ahora?
El desafío
Había una tensión estructural: el dominio exige precisión y densidad, pero la lectura cotidiana exige velocidad. Si fallás en la jerarquía, el usuario interpreta mal un número, y en finanzas eso no es un detalle cosmético.
Qué estaba en juego
- Mezclar liquidado y por liquidar como si fueran lo mismo
- Forzar al usuario a reconstruir contexto antes de cada operación
- Tratar alertas de negocio (perfil vencido, contratos) como errores del sistema
- Diseñar cada módulo de forma aislada y perder consistencia entre sesiones
Preguntas que la experiencia debía sostener
- ¿Cuál es mi posición actual?
- ¿Qué parte ya está liquidada y qué parte sigue pendiente?
- ¿Qué movimientos ocurrieron y en qué estado están?
- ¿Qué instrumento estoy viendo y qué lo diferencia de otros?
- ¿Qué cambia si ejecuto esta operación?
- ¿Qué información requiere atención ahora (test vencido, contratos, activación)?
Restricciones de diseño
- Mantener precisión en cifras y estados
- Soportar densidad de datos en tablas financieras
- Funcionar en distintos tamaños de pantalla sin perder jerarquía
- Evitar ambigüedad entre valores temporalmente distintos
- Mantener consistencia entre módulos (cartera, detalles, operar)
- Permitir acciones críticas sin perder contexto previo
Cómo pensamos el problema
No arranqué por estética ni por componentes. Arranqué por preguntas. Cada módulo del producto debía tener una pregunta dominante; todo lo demás quedaba subordinado o en otro contexto.
Principio
Una pregunta por pantalla
Inicio responde «¿cómo estoy?». Cartera responde «¿de qué está compuesta mi tenencia?». Movimientos responde «¿qué pasó?». Operar responde «¿qué estoy por ejecutar?». Si una pantalla intenta responder dos preguntas principales, la jerarquía se rompe.
Principio
La jerarquía comunica el modelo
No traté la UI como contenedor neutro. La posición de un dato (arriba o abajo, grande o chico, solo o agrupado) es parte del significado. Total arriba, desglose abajo; estado como badge, no como nota al pie.
Principio
Diseñar estados, no solo vistas felices
Bloqueos operativos, activación pendiente, tablas vacías y confirmaciones sensibles son parte del producto real. Diseñarlos después convierte restricciones de negocio en fricción confusa.
Principio
Sistema antes que excepción
Cuando un patrón funcionaba (drawer de detalle, badge de estado, card de resumen) lo extendí a otros módulos. Cuando un instrumento requería excepción (filtros de futuros, toggle solo liquidado) la documenté como variación consciente, no como parche.
Problemas que fuimos resolviendo
Problema
El usuario veía muchos números pero no sabía cuál importaba primero.
Pensamiento
Separé lectura de posición (total + variación) de lectura de composición (tabs, tablas, drawers). Cada capa responde a un momento distinto de la sesión.
Resolución
Inicio y cartera con jerarquía explícita: total dominante, desglose y detalle en niveles secundarios.
Problema
Liquidado y por liquidar podían leerse como duplicados o intercambiables.
Pensamiento
Traté los estados temporales como categoría de información, no como columnas más. Naming explícito, anidamiento bajo el saldo y columnas consistentes en futuros.
Resolución
Modelo visual donde total, liquidado y por liquidar tienen roles distintos y reconocibles.
Problema
Operar exigía recordar datos vistos en otra pantalla.
Pensamiento
El paso de confirmación no es un trámite: es el momento de reducir error. Recontextualicé instrumento, monto, riesgo y aceptación en un solo lugar.
Resolución
Flujo de operación con revisión concentrada, declaración contextual y estados de carga y bloqueo definidos.
Problema
Restricciones de cuenta se percibían como fallas del sistema.
Pensamiento
Un bloqueo operativo necesita explicar qué falta, por qué existe y cómo resolverlo sin interrumpir permanentemente la lectura financiera.
Resolución
Alertas y modales con copy de negocio, CTA claro y jerarquía subordinada al contenido principal.
Entender el modelo de información
El primer problema no era visual. Era decidir qué conceptos debían convivir, cuáles necesitaban separación y qué información debía dominar cada contexto.
Capas derivadas de la estructura real del menú inversor, módulos de cartera e instrumentos.
Diseñar la jerarquía
Problema
Mostrar todos los valores con el mismo peso visual obligaba al usuario a interpretar la estructura antes de interpretar los datos.
Decisión
Establecí una jerarquía donde el total principal domina la primera lectura (resumen de cuenta o cartera) y los desgloses (liquidado, por liquidar, disponible) completan el contexto en un nivel secundario, visualmente subordinado.
Trade-off
Jerarquía explícita
Mayor jerarquía implica decidir explícitamente qué información pierde protagonismo. Algunos datos relevantes pasan a drawers, tabs o filas secundarias.
El inicio como punto de orientación
¿Qué necesita saber primero una persona cuando entra a su cuenta?
El módulo Inicio no es un resumen genérico. Funciona como punto de orientación: total de cuenta, variación, accesos a flujos de fondos y señales que requieren acción (test de inversor vencido, contratos pendientes de firma).
La jerarquía prioriza el valor total y su cambio. Las acciones frecuentes (ingresar dinero, retirar fondos, informar depósito, compensar cartera) quedan al alcance sin competir con la lectura principal. Alertas contextuales aparecen cuando hay bloqueos operativos, con CTA claros y opción de descartar.
En mobile, el mismo contenido se reorganiza en grid de acciones y cards apiladas, manteniendo el total como primer elemento de lectura.
Test vencido
Volvé a realizarlo para poder operar.
$ 12.458.320,50
+2,34% (+$ 284.120,00)
Posición, cartera y contexto
$ 8.942.150,00
+1,82%
| Especie | Cantidad | Importe |
|---|---|---|
| AL30 | 1.200 | $ 342.000,00 |
| GGAL | 500 | $ 218.500,00 |
La vista Cartera responde a otra pregunta: cómo está compuesta mi tenencia. El resumen de cartera muestra el valor agregado y su variación; debajo, la sección de instrumentos desglosa inversiones, saldos, cauciones y futuros/opciones en tabs diferenciados.
Una cifra aislada dice poco. El desafío fue mantener visible el resultado principal sin desconectarlo de su composición: distribución por tipo de activo, saldos por moneda con drill-down a detalle, y tablas de instrumentos con columnas de liquidado y por liquidar cuando aplica.
El drawer de detalle de saldo extiende la lectura sin abandonar el contexto: disponible, en garantía, y desglose de liquidación cuando corresponde.
Diseñar estados temporales
En saldos e instrumentos, liquidado, por liquidar y total no representan el mismo momento. La experiencia necesitaba evitar que el usuario los interpretara como equivalentes intercambiables.
La decisión fue triple: naming explícito (sin abreviaturas ambiguas en desktop), proximidad jerárquica (liquidado y por liquidar anidados bajo el saldo o la fila principal) y consistencia de columnas en tablas de futuros y opciones.
En mobile, las tablas densas se resuelven con filas expandibles que conservan el total visible y revelan el desglose bajo demanda.
| Ticker | Posición | Liquidado | Por liquidar | Importe |
|---|---|---|---|---|
| DLR/ENE25 | 10 | $ 45.200,00 | $ 12.800,00 | $ 58.000,00 |
| SOJ/ABR25 | 5 | $ 32.100,00 | $ 8.400,00 | $ 40.500,00 |
Movimientos: densidad sin ruido
La vista de movimientos organiza la actividad histórica en tres tabs (monetarios, instrumentos y actividad) con tabla ordenable, selector de columnas persistente, filtros por fecha y búsqueda.
Una vista histórica necesita densidad suficiente para ser útil, pero demasiada información destruye la capacidad de detectar eventos relevantes. Prioricé alineación numérica a la derecha, estados con badges semánticos (pendiente, disponible, aprobado, rechazado) y drawer de detalle para profundizar sin saturar la tabla.
- Tabs por tipo de movimiento
- Ordenamiento por columna
- Selector de columnas con persistencia
- Filtro por rango de fechas
- Búsqueda y exportación
- Drawer de detalle por fila
| Liquidación | Concepto | Importe | Estado |
|---|---|---|---|
| 12/03/25 | Compra | -$ 28.500,00 | DISPONIBLE |
| 10/03/25 | Transferencia | +$ 150.000,00 | PENDIENTE |
| 08/03/25 | Renta | +$ 4.200,00 | APROBADO |
Futuros e instrumentos complejos
El módulo Futuros/Opciones agrupa cuatro sub-tabs confirmados en el producto: Futuros A3, Opciones A3, Otros futuros y Otras opciones. Cada uno comparte patrones de tabla (ticker, posición, liquidado, por liquidar, último precio, importe) pero con categorías y filtros propios (financieros, agropecuarios, commodities).
Reutilizar componentes no significa tratar todos los instrumentos como si fueran iguales. Mantuve headers y columnas consistentes para facilitar el reconocimiento, pero preservé filtros, agrupaciones y toggles específicos (como «Solo liquidado» en vista detallada, donde el instrumento lo requería.
Diseñar acciones críticas
El flujo de operar atraviesa selección de categoría, instrumento, configuración de la orden y confirmación. Cuanto más sensible es una acción, menos debería depender de que el usuario recuerde información de una pantalla anterior.
El paso de confirmación concentra datos de la operación, declaración de riesgo contextual según el tipo de instrumento, checkbox de aceptación y CTA de confirmación con estado de carga. En modo productor, el flujo se extiende a selección de clientes, asignación y revisión por lote.
Cuando el perfil de inversor está vencido, OperarBlockedModal intercepta la acción con explicación y CTA para renovar: un estado restringido que comunica restricción de negocio, no error del sistema.
Activación de cuenta
Activá tu cuenta crypto
Tu cuenta crypto está lista para activarse. Aceptá los términos para comenzar a operar.
Activar cuentaEl módulo crypto introduce un flujo de activación en dos pasos: anuncio de novedad y confirmación con aceptación de términos. El usuario puede entender el producto antes de poder operar en ese mercado.
Un estado restringido no debería sentirse como un error. El modal comunica qué falta, por qué existe la restricción y cuál es el siguiente paso (activar cuenta) con validación explícita de términos antes de confirmar.
Comunicación dentro del producto
El configurador incluye gestión de popups y comunicaciones dirigidas a usuarios. En la interfaz del inversor, alertas como test vencido o contratos pendientes compiten con información financiera.
En una interfaz ya densa, cada mensaje adicional compite con datos que pueden tener impacto financiero. Las alertas usan el mismo lenguaje de cards del sistema, CTA primario naranja, copy directo y opción de dismiss para no bloquear la lectura principal de forma permanente.
Tenés contratos por firmar
Firmalos para tener tus productos al día.
Contenido financiero principal continúa debajo de la alerta
Diseñar un sistema, no pantallas
El producto cuenta con documentación de design system (colores semánticos, tipografía Inter, WidgetCard, StatusBadge, drawers, modales, tablas y patrones de feedback, que sostiene la consistencia entre módulos.
La consistencia importaba porque el usuario alterna entre lectura de cartera, revisión de movimientos y ejecución de operaciones en la misma sesión. Reconocer un badge de estado, un drawer o un botón primario reduce fricción cognitiva entre contextos distintos.
- WidgetCard para agrupación de contenido
- StatusBadge para estados de movimientos y órdenes
- Drawers laterales para detalle sin navegación
- Modales para acciones bloqueadas o confirmaciones
- DecimalText para cifras con jerarquía tipográfica
- EmptyStateBanner para estados vacíos informativos
WidgetCard
Agrupación de módulos
StatusBadge
Estados semánticos
DecimalText
Cifras jerárquicas
Drawer
Detalle sin navegar
Responsive y densidad
Responsive no significaba hacer la versión de desktop más angosta. Significaba redefinir qué información debía permanecer visible en cada contexto.
En tablas financieras, mobile prioriza columnas esenciales y expande el detalle en la fila. Los drawers de operar ocupan pantalla completa en mobile. El menú lateral se convierte en header con navegación por ítems. Las cifras mantienen split de enteros y decimales para legibilidad en tamaños reducidos.
Trade-offs
Trade-off
Más información vs. más comprensión
Mostrar liquidado, por liquidar y total en la misma vista reduce navegación, pero aumenta carga cognitiva. La solución fue jerarquía visual y anidamiento, no eliminación de datos.
Trade-off
Consistencia vs. especificidad
Futuros A3 y otros futuros comparten estructura de tabla, pero los filtros por categoría y el toggle «Solo liquidado» responden a necesidades distintas del instrumento. Un sistema compartido escala; la especialización evita perder matices.
Trade-off
Densidad vs. escaneabilidad
Las tablas de movimientos necesitan volumen para ser útiles. Selector de columnas, ordenamiento y badges de estado permiten al usuario reducir ruido sin que el producto imponga una vista única.
Trade-off
Simplicidad vs. precisión
Colapsar liquidado y por liquidar en un solo número simplificaría la UI, pero borraría una distinción que el dominio financiero requiere. Mantuve ambos con naming explícito.
Impacto
Este es un prototipo sin métricas de producto en producción. El impacto que puedo sostener es de diseño: qué quedó resuelto en la experiencia, qué decisiones quedaron documentadas y qué base quedó lista para escalar.
Si en el futuro existen datos de adopción, errores operativos o tiempos de tarea, esta sección puede complementarse con evidencia cuantitativa. Hoy el valor del trabajo está en la claridad del modelo y la cobertura de estados.
Entregable
Modelo de información aplicado
Cinco capas (estado, actividad, instrumentos, temporalidad y acciones) traducidas a navegación, jerarquía y patrones visuales en inversor, productor y configurador.
Entregable
Flujos críticos con estados definidos
Operar, confirmación, bloqueo por perfil, activación de cuenta y alertas in-app tienen recorridos completos: no solo el camino feliz, sino restricción, carga, error y dismiss.
Entregable
Sistema de patrones reutilizable
WidgetCard, badges, drawers, DecimalText y empty states documentados en /design-system, reduciendo improvisación al sumar módulos como crypto o nuevos instrumentos.
Entregable
Densidad financiera sin sacrificar escaneo
Tablas de movimientos y futuros con columnas configurables, ordenamiento y jerarquía numérica, útiles para usuarios que necesitan volumen sin perder la capacidad de detectar un estado relevante.
Entregable
Base responsive coherente
La misma pregunta dominante por módulo se mantiene en mobile; cambia la densidad, no el modelo mental. Drawers full-screen, filas expandibles y grids de acción adaptados por breakpoint.
Entregable
Menor ambigüedad entre conceptos financieros
Liquidado, por liquidar, disponible y en garantía dejaron de competir visualmente. Eso no elimina la complejidad del dominio, pero reduce el riesgo de interpretación incorrecta.
Para el equipo
- Lenguaje compartido entre diseño, producto e ingeniería para discutir jerarquía y estados
- Menos retrabajo al extender módulos: el patrón ya existe antes de la nueva feature
- Prototipo navegable que permite validar flujos antes de inversión de desarrollo
Reflexiones
Aprendizaje
La simplicidad no consiste en mostrar menos
En productos financieros, eliminar información produce una experiencia visualmente limpia pero conceptualmente incompleta. La claridad viene de la jerarquía, no del vacío.
Aprendizaje
La jerarquía es parte del modelo
Dónde aparece un dato comunica su importancia y su relación con otros. El total arriba, el desglose abajo; el estado como badge, no como texto suelto.
Aprendizaje
Los estados necesitan contexto
Liquidado junto a por liquidar solo funciona si el usuario entiende que son momentos distintos. El naming y la proximidad importan tanto como el número.
Aprendizaje
La consistencia tiene límites
Un sistema compartido ayuda a escalar, pero futuros, opciones y saldos en moneda local no deberían forzarse a una abstracción que borre diferencias operativas.
Aprendizaje
Diseñar acciones implica diseñar consecuencias
Confirmar una operación requiere recontextualizar la decisión: qué se opera, en qué condiciones y qué acepta el usuario al avanzar.
El diseño se desarrolló iterando sobre el prototipo existente: mapeo de flujos, restricciones del dominio financiero, requerimientos de producto y feedback interno. No hubo acceso formal a usuarios finales en esta etapa; las decisiones se validaron contra coherencia del modelo, viabilidad técnica y claridad de lectura.
Más proyectos
B2B • Marketplaces • SaaS / herramientas de gestión
Diseñando el flujo que convierte campañas y postulaciones en colaboraciones
Campaña en vivo, postulaciones entrando, creador por elegir. Diseñé el puente entre marca y creador sin perder contexto hasta colaborar.
Productos de uso masivo • Proyectos propios
Transformando información local fragmentada en un producto de discovery escalable
Info local fragmentada frenaba el descubrimiento de albergues. Organicé filtros, confianza y contenido para escalar con búsqueda orgánica.