01
El contexto
B2POS es la herramienta que abre un vendedor cuando un cliente pregunta «¿lo puedo pagar en cuotas?». Carrito, calculadora de crédito, datos del cliente, scoring, ofertas de bancos, firma por SMS. Todo pasa en el mostrador, con una persona del otro lado y, muchas veces, una fila detrás.
Eso cambia lo que significa un buen diseño en este caso. El usuario no es el cliente: es un empleado de comercio que está trabajando, usando un Android barato o una PC de 2018, y que hace este flujo unas cuarenta veces por día después de apenas una hora de capacitación. Cada segundo de duda es un segundo más en el que el cliente puede replantearse la compra.
02
El problema
La plataforma original se pensó para el back office y después se llevó a la tienda. Eso trajo tres consecuencias.
Era lenta justo donde dolía.
El tiempo mediano para completar una solicitud era de unos nueve minutos. Las entrevistas nos ayudaron a entender en qué se iban esos minutos, y rara vez era por tipear (aunque también: implementamos un init que, al detectar compradores que volvían por segunda vez, trae sus datos desde Base). Era más bien por la duda, volver atrás para chequear algo y tener que volver a ingresar los datos después de que un error de validación vaciaba el formulario.
Los vendedores no podían responderle al cliente.
Cada banco tiene sus propias condiciones, reglas de anticipo y restricciones, y nada de eso estaba en el producto. Así que el vendedor adivinaba, o llamaba a soporte mientras el cliente esperaba. Cerca de un quinto de los tickets no eran bugs: era alguien que no entendía el proceso que le tocaba ejecutar.
Cada cadena quería que se viera como propia.
La plataforma se despliega en varias marcas, y el sistema visual se había llenado de parches puntuales que rompían cada release.
03
De qué me ocupé
Definir el problema, hacer las entrevistas, la dirección de diseño, el design system y su handoff a ingeniería web y mobile, y decidir qué medir después. Trabajo directo con los desarrolladores en vez de tirar archivos por encima del muro, y las librerías de tokens que entregamos las revisamos a mano, para que todo el producto hable el mismo idioma.
04
Cuatro decisiones
01
Cuatro marcas, claro y oscuro: ocho temas en lugar de uno
Es la decisión por la que más peleé. Ocho temas parecen un lujo cuando el backlog está lleno de features. Lo que convenció fue un argumento operativo: la luz de las tiendas no es neutra, y cada marca acumulaba overrides hardcodeados que hacían más lento cada release. Los temas se volvieron el mecanismo que frenó la filtración de la marca al código. Una capa semántica de tokens, ocho exports, y nada en el producto referencia un color crudo.
02
Más pasos, no menos
El instinto con un formulario de nueve minutos es comprimirlo. Las entrevistas dijeron lo contrario: la gente avanza más rápido y se equivoca menos en un flujo largo de pasos simples que en uno corto de pasos densos. Una decisión por pantalla hace que el vendedor siempre sepa qué se le pide y nunca pierda trabajo por un error más abajo. Sumamos pasos y el flujo se aceleró.
03
Las condiciones del banco van dentro del producto
En vez de escribir mejor documentación de soporte, pusimos las condiciones de cada banco justo donde surge la pregunta: al elegir una oferta. Los tickets de soporte bajaron un 40%, y los de no entender el proceso, un 19%. Ese segundo número significa que ahora el producto se explica solo.
04
Diseñar la medición, no solo las pantallas
La taxonomía de analytics se diseñó junto con las pantallas: nombres de eventos atados a las propias rutas de la app y un session id generado al abrir el carrito, conciliado con el id de la solicitud cuando se identifica al cliente. Sin esa costura, el carrito y la calculadora eran invisibles, y ahí vivía buena parte de las dudas.
05
El lanzamiento
No hicimos un corte de golpe. La versión nueva convivió con la vieja, y hoy el 40% de la flota, unos 32.000 dispositivos, ya la usa. Va por la v2.0.4, iterada con tests A/B y entrevistas en lugar de un único gran lanzamiento.
Cada medición es un logro o una instrucción. Los tests que no movieron ninguna métrica nos mostraron en qué partes del flujo los vendedores no tenían problemas, y así las cuatro decisiones encontraron su orden de prioridad.
06
Dónde está hoy
El handoff funciona como un pipeline, no como un documento. La misma capa semántica sale como librería de variables CSS para web y como tema de Flutter para mobile, generada con ayuda de IA y revisada a mano con los ingenieros que la usan, para que web y app no se separen.
En curso: un onboarding para toda la plataforma, una capa de dashboard y navegación, y una app mobile complementaria en test cerrado con 12.000 usuarios partners.
