Un estudio conceptual de Webtrix: cómo debe guiar un panel de pagos transfronterizos a un equipo financiero que paga a proveedores en varias divisas.
Tipo
Estudio conceptual (producto ficticio)
Duración
6 semanas
Herramientas
Figma, Maze
Equipo
Estudio de diseño de Webtrix
El encargo
FlowPay es una plataforma B2B ficticia de pagos transfronterizos, imaginada para una empresa mediana que paga a proveedores en Marruecos y en el extranjero en dírhams, euros y dólares. La usamos como estudio: ¿cómo es un panel de pagos cuando el verdadero trabajo del equipo financiero es tener certeza, no ir rápido?
El ejercicio abarca todo el panel, desde la creación de un pago hasta los informes, y plantea una sola pregunta a cada pantalla: ¿elimina una decisión que el usuario no debería tener que tomar?
Dónde se rompen los flujos de pago
Las herramientas de pago suelen crecer un requisito a la vez. El resultado típico es una interfaz saturada, una navegación que sigue el organigrama del proveedor en lugar de la tarea del usuario y un largo formulario paso a paso, peor aún en el móvil. Partimos de estos problemas, habituales en la categoría, y diseñamos frente a ellos.
- Crear un pago requiere siete pasos, y los mismos datos se vuelven a introducir para los proveedores recurrentes
- El diseño móvil es una pantalla de escritorio reducida, no una pantalla diseñada para el móvil
- Los usuarios nuevos no saben qué opción de pago se aplica a cada divisa
- Los pagos masivos existen, pero están tras varios menús
- Los informes requieren exportaciones manuales porque nada se actualiza en tiempo real
Qué analizamos
Un estudio documental de dos semanas: revisión de cómo los productos de pago existentes gestionan los pagos multidivisa, documentación pública de proveedores de pagos y notas de flujo de trabajo sobre cómo un equipo financiero prepara, aprueba y concilia un pago a proveedores.
Lo que reveló la revisión
- Las opciones de pago se presentan por proveedor y no por lo que el usuario quiere lograr (pagar ahora, programar, dividir)
- Los pagos recurrentes son la tarea más habitual, pero se diseñan como si fueran el primer pago
- Los equipos financieros buscan primero el pago masivo y rara vez lo encuentran
- Los informes son una exportación, no una vista en vivo
Direcciones exploradas
Realizamos un sprint de diseño de dos días para explorar cómo podría funcionar el flujo de pago: bocetos rápidos, mapas mentales y votación con puntos para comparar las ideas con la pregunta planteada arriba.
De ahí salieron tres direcciones. Elegimos «StreamFlow»: un concepto que trata la creación del pago como un flujo guiado y contextual en lugar de un formulario rígido paso a paso.
El flujo de pago, en tres pasos
Mapeamos el recorrido desde el inicio de sesión hasta la confirmación del pago. El objetivo de diseño es reducir el flujo de siete pasos a tres, manteniendo todas las verificaciones que un equipo financiero exigiría.
- Datos del pago — valores predeterminados inteligentes y autocompletado según el historial
- Revisar y confirmar — toda la información en una pantalla, con edición en línea
- Confirmación — estado en tiempo real con tiempo de procesamiento estimado
Wireframes
Objetivo de diseño: tres pasos en lugar de siete, manteniendo todas las verificaciones.
Sistema visual
Una interfaz de pagos debe transmitir fiabilidad sin resultar fría. El sistema visual combina una paleta de color sobria con una jerarquía tipográfica clara, para que importes, divisas y estados se lean de un vistazo.
Plan de validación
El prototipo de alta fidelidad está construido en Figma. Este estudio no se ha probado con usuarios reales; el plan siguiente es cómo lo validaríamos antes de cualquier desarrollo, usando Maze para sesiones no moderadas.
5
Participantes previstos por ronda de pruebas
3
Rondas de pruebas previstas
90%
Objetivo: tasa de éxito en las tareas
Iteraciones de diseño
Iteración 1: Creación de pagos simplificada de cinco campos a tres, con valores predeterminados inteligentes para proveedores recurrentes. Objetivo de diseño: completar más rápido la tarea más habitual.
Iteración 2: Diseño móvil rediseñado en una sola columna, con áreas táctiles más grandes y secciones plegables. Objetivo de diseño: que móvil y escritorio lleguen al mismo resultado.
AntesDespuésEl diseño propuesto
La propuesta, «StreamFlow», es una experiencia de pago limpia y que inspira confianza en todos los dispositivos. Sus funciones principales:
- Flujo de pago guiado en 3 pasos con ayuda contextual
- Seguimiento de transacciones en tiempo real con notificaciones push
- Procesamiento de pagos masivos para clientes empresariales
- Panel de informes personalizable con opciones de exportación
- Modo oscuro con objetivos de contraste WCAG AA
- Diseño responsive mobile-first con navegación por gestos
Objetivos de diseño
7 → 3
Pasos del flujo de pago (diseño)
-30%
Objetivo: tiempo para completar un pago
-40%
Objetivo: contactos a soporte de usuarios nuevos
Son objetivos de diseño de un estudio conceptual, no resultados medidos: el diseño no se ha lanzado ni probado con usuarios reales.
Cada paso debe ganarse su lugar: si un campo se puede inferir, no se pregunta.
Lo que nos enseñó el estudio
- Planificar las pruebas de usabilidad antes de pulir la interfaz; es más barato cambiar un wireframe
- Los usuarios de finanzas priorizan la confianza y la claridad por encima del adorno visual
- Mobile-first no significa solo móvil: los usuarios avanzados siguen necesitando toda la capacidad en escritorio
- Implicar pronto a los ingenieros mantiene el diseño viable
Si esto se construyera
- Validar el flujo con el plan de pruebas anterior antes de cualquier desarrollo
- Convertir el sistema de diseño en una biblioteca de componentes compartida
- Conectar el panel a datos contables y bancarios reales mediante integraciones
- Añadir la categorización de pagos con IA solo cuando existan datos limpios
