PayGo · C6 Bank · 2020–2021
Portal de gestión para comercios C6 Pay
Cuando PayGo entró al ecosistema de C6 Bank, el portal pasó a formar parte de la rutina financiera de miles de comercios, aunque todavía seguía la lógica del sistema heredado. Mi trabajo fue acercar esa estructura al día a día del comerciante dentro de lo que la plataforma podía ofrecer.
−28% menos tiempo en pantalla
Pantallas y reglas acumuladas en el sistema heredado
El portal había crecido por capas, con pantallas y reglas añadidas según lo exigía la operación, dejando ventas, cobros e historial organizados por la estructura interna del sistema y lejos de la secuencia usada por el comercio al cerrar la caja.
Experiencia del usuario
- Navegación poco intuitiva
- Arquitectura de información confusa
- Baja priorización de la información financiera
- Exceso de carga cognitiva en las pantallas
- Flujos largos para tareas recurrentes
Impacto en el negocio
- Alto volumen de consultas operativas
- Dependencia frecuente del soporte
- Baja eficiencia en la ejecución de tareas
- Inconsistencia con los estándares de C6 Bank
- Base limitada para la evolución del producto
Revisar datos en varias pantallas
El cierre de caja dependía de cruzar información entre distintas áreas del portal.
Interpretar la lógica del sistema
La estructura reproducía la organización interna del sistema, lejos de la rutina del comercio.
Recurrir al soporte
Dudas operativas simples terminaban frecuentemente en tickets de atención.
Encontrar ventas no bastaba para cerrar la caja
Con los próximos sprints en preparación, el descubrimiento ocurrió dentro de los refinamientos: reconstruí con ingeniería cómo llegaban los datos al portal y, con PM y CX, seguí las dudas que terminaban en tickets.
Ventas y cobros en áreas separadas
La estructura distribuía la información entre pantallas que el comercio debía cruzar durante el cierre.
Cierre armado fuera del portal
Estados y valores debían interpretarse y combinarse hasta formar una visión de caja.
Del resumen esperado a lo que cabía en el sprint
Durante la exploración en baja fidelidad, pregunté a los comercios qué esperaban encontrar en un “Resumen” y escuché que el valor del día, el total por recibir y los plazos debían aparecer ya calculados, muchas veces con Stone y PagBank como referencias.
Como el tiempo era corto y no todo cabía en los primeros sprints, llevé esos aprendizajes a los refinamientos con ingeniería. Así “Condiciones comerciales” pasó a ser “Tarifas” en el menú antes de que el resto del proyecto estuviera listo.
Tres decisiones para responder cuánto voy a recibir
En el resumen financiero, los valores aparecían en una cuadrícula semanal, mientras ventas, cobros e historial vivían en otras pantallas.
Ver lo que entra hoy y los próximos días
Mostramos valores de hoy, de los próximos 7 días y de los próximos 30 días.
Leer la caja en una sola secuencia
Reunimos posición financiera, evolución de valores e historial en la misma lectura.
Encontrar respuestas antes de los filtros
La primera pantalla respondía las dudas más frecuentes antes de los filtros.
La posición financiera antes de los detalles
En los tickets acompañados por CX, encontrar ventas y cobros era solo parte de la tarea, porque el comercio todavía debía confirmar si los valores cuadraban al final del día.
Encontrar la venta que no cuadraba
Cuando el total no cuadraba, el comercio debía encontrar la venta responsable por medio de varias consultas y ajustes de filtro en la pantalla antigua.
Puse los períodos más usados sobre el listado y mantuve operación y estado visibles cerca de los datos usados en la revisión.
La hora de la última sincronización quedó arriba para confirmar la actualización antes de buscar una diferencia.
CX
Aproximación con el equipo de atención al cliente para entender el perfil de los comerciantes, las dudas más recurrentes y los principales motivos de contacto con el soporte.
Ingeniería
Mapeo del funcionamiento del sistema legado para entender cómo llegaban los datos al portal. Muchas métricas requerían cálculo en el front-end en lugar de venir listas desde el back-end, lo que era aceptable en algunos casos, pero para métricas críticas necesitaba alinearme con ingeniería antes de definir la prioridad.
Análisis de referentes
Análisis de productos como Stone, Stripe y PagSeguro para entender cómo el mercado organiza la información financiera y construir una base de referencia para las decisiones de diseño.
Pruebas con usuarios
Validación de prototipos con cinco comerciantes para verificar que las principales decisiones realmente facilitaban la operación antes del desarrollo.
Lo que verifiqué antes de desarrollar
Tickets en el cierre de caja
La concentración de tickets definió la primera entrega.
Viabilidad de los indicadores
Mapeé origen y consistencia de datos con ingeniería.
Navegación revisada con diseño
Las críticas ajustaron jerarquía y navegación antes de implementar.
Pruebas con comercios
Probé el orden de información con cinco comercios.
Menos tickets y una revisión más rápida
En los tres meses posteriores al despliegue gradual, los tickets sobre cierre de caja cayeron 36%.
Con la PO, acompañé Google Analytics y observé una caída de 28% en el tiempo promedio de la pantalla de ventas.