Cuando un cajero decide usar otra app en lugar de la tuya, no es una preferencia. Es una pérdida directa de ingreso
Eso fue lo que descubrí en las pruebas de usuario de Bitmored,
una plataforma de pagos y servicios financieros con producto
existente en Android y escritorio.
El encargo inicial era desarrollar la versión web. Pero entre el
diagnóstico, las conversaciones con el equipo interno y las pruebas
con usuarios reales, el proyecto se convirtió en algo distinto: equilibrar
regulación financiera, viabilidad técnica y experiencia de uso en
un producto que la gente realmente quisiera usar.
El encargo inicial
Un cliente llegó con un encargo aparentemente claro:
desarrollar la versión web de su plataforma de pagos. Algo
intuitivo, seguro y escalable.
Me incorporé como diseñador y lo primero que hice fue entender
qué tenían antes de proponer cualquier cosa. Bitmored ya operaba
con aplicaciones en Android y escritorio. Tenían clientes reales,
procesos establecidos y un equipo de soporte que resolvía el
día a día. No era un producto desde cero, era un negocio funcionando
con herramientas que habían llegado a su límite.
Eso cambió completamente cómo encaré el proyecto. No se trataba
de construir algo nuevo. Se trataba de entender qué estaba fallando
y por qué.
El cuello de botella no era la interfaz
Antes de proponer soluciones, necesitaba entender cómo
operaba el negocio realmente.
El cliente había incluido al equipo de soporte en las revisiones
semanales del proyecto. Ellos tenían algo que los wireframes
no podían mostrar: sabían exactamente qué problemas tenían los
clientes porque los atendían todos los días.
Lo que me contaron cambió el enfoque. Gran parte de las tareas
administrativas dependían de soporte para ejecutarse. No porque
así estuviera diseñado, sino porque el producto no daba las herramientas
para hacerlo de otra forma.
A partir de ahí propuse separar el producto en dos roles claros:
cajeros enfocados en la operación diaria, y administradores con
acceso a gestión, métricas y control. No era solo una decisión
de UX, era una decisión de cómo debería funcionar el negocio
internamente.
El momento que cambió el proyecto
Con una versión funcional del producto, organicé pruebas
de usabilidad con seis usuarios: principalmente dueños
de negocios que usaban la plataforma, algunos con
cajeros a cargo. También incluí un usuario externo sin
experiencia previa en sistemas similares.
Las pruebas seguían un guión con tareas reales: hacer una
recarga, reenviar un comprobante, revisar el estado de caja,
abrir una sucursal, asignar saldo a un cajero.
En las primeras dos sesiones detecté que los usuarios no
encontraban la sección de administración. Lo corregí de inmediato
antes de continuar.
Pero el hallazgo más importante vino después, y no estaba en el guión.
Varios usuarios mencionaron el mismo problema desde ángulos
distintos. Un dueño de negocio comentó que él sí usaba la
plataforma, pero sus cajeros se negaban: la sesión se
cerraba sola y volver a entrar era tedioso. Para servicios
como recargas, usaban otra app. Otro usuario lo describió
con más impacto: cuando un cajero está bajo presión y la
sesión se cierra, comete errores al reingresar su contraseña
y termina negando el servicio a su cliente.
Ese no es un
problema de experiencia de usuario. Es ingreso perdido en tiempo
real.
Regulación vs experiencia
Al presentar los hallazgos al equipo, mi primera propuesta fue
simple: extender el tiempo de sesión. Si el problema era que la
sesión se cerraba muy pronto, la solución más obvia era darles
más tiempo.
Fue ahí donde los dueños me explicaron algo que yo desconocía: no
era una decisión de producto, era una restricción regulatoria. Las
plataformas financieras tienen límites establecidos sobre el tiempo
de inactividad antes de cerrar sesión.
Investigué más por mi cuenta. Encontré que existía la posibilidad
de un sistema escalonado: distintos niveles de seguridad según el
tipo de operación. En papel era la solución ideal porque atacaba
el problema de raíz. Pero al revisarlo con los dueños y el desarrollador
principal, quedó claro que no era viable. La forma en que Bitmored
procesa sus servicios internamente hacía que implementar esa distinción
fuera extremadamente complejo, y probablemente requeriría validación
legal.
Descartar esa idea fue una decisión importante. No porque fuera mala,
sino porque entender por qué no era viable en ese contexto es parte
del trabajo.
Diseñar dentro de las restricciones
Con el sistema escalonado descartado, el enfoque cambió. Si
no podíamos modificar las reglas, podíamos diseñar mejor
alrededor de ellas.
Por lo que describían los usuarios, el cierre llegaba en momentos
en que todavía estaban operando, atendiendo a un cliente, completando
un flujo. El sistema no tenía forma de saberlo.
Las decisiones que tomé a partir de ahí fueron directas: detección
de actividad real para que el tiempo solo corra en inactividad
genuina, aviso antes del cierre con opción de renovar sesión,
guardado de progreso si la sesión expira en medio de un flujo,
y autenticación biométrica para reducir la fricción del reingreso
cuando sí es necesario.
Ninguna de estas decisiones rompía el marco regulatorio. Todas
atacaban el problema real: un cajero bajo presión no debería
perder una operación por un timeout mal manejado.
Resultados
Lo que se puede documentar hoy
El producto está actualmente en desarrollo. No hay métricas
de adopción todavía, y sería fácil inventarlas. No voy a
hacer eso.
Los usuarios describieron la plataforma como intuitiva y fácil
de aprender. Varios mencionaron que les gustaba y la veían versátil.
Uno dijo directamente:
"Me gusta la plataforma, me parece muy versátil, me
gusta."
Y más de uno preguntó cuándo iba a estar lista porque ya querían
usarla.
Para una plataforma que todavía no existe en producción, esa
es la señal más honesta que se puede documentar: usuarios reales,
con una alternativa que ya conocen, eligiendo la nueva versión
antes de que esté disponible.
El problema que hacía que los cajeros prefirieran otra app tiene
una solución concreta en este diseño. Cuando el producto se lance,
actualizaré este caso con datos reales. A veces eso es lo más
honesto que se puede documentar en esta etapa.
Aprendizajes
La regulación es parte del problema, no un obstáculo. Entré al
proyecto sin conocimiento de las restricciones financieras que
afectan la experiencia de usuario. Salí con la costumbre de
revisarlas desde el inicio. En fintech no puedes diseñar la
experiencia ideal y luego ver qué permite la regulación. Tienes
que diseñar dentro de ella desde el principio.
Las pruebas de usuario no son para validar tu diseño, son para entender
el problema real. El hallazgo más importante de este proyecto no
surgió de mis wireframes ni de mi auditoría. Surgió de escuchar a
usuarios hablar libremente sobre su experiencia con el producto que
ya usaban. Si las pruebas hubieran sido solo para confirmar mis decisiones,
me habría perdido el problema más costoso del producto.
Con clientes reales, entender antes de proponer no es opcional. Cuanto
más grande es el cliente y más compleja es la operación, más cara
es una suposición equivocada. Este proyecto me enseñó a invertir
más tiempo al inicio entendiendo cómo funciona el negocio internamente
antes de tocar ningún wireframe.
