CASO DE ESTUDIO

PagoConectado

Diseño de una experiencia de pago que ayuda a ambas partes a registrar, verificar y comprender una transacción cuando el acceso a internet es inestable.

Categoría

Diseño de Producto · Fintech · Experiencia sin conexión

Rol

UX/UI y Diseño de Producto

Contexto

Caso de estudio colaborativo de diseño de producto para pagos con baja conectividad

Métodos

Persona, JTBD, mapeo de escenarios, flujos de usuario, modelado de estados y prototipado de alta fidelidad

Portada del caso de estudio PagoConectado que presenta una experiencia fintech de pago sin conexión
PagoConectado — dos partes, una evidencia compartida y un pago con certeza.

PROBLEMA

El desafío

Los pagos digitales suelen asumir una conectividad estable. En tiendas rurales y otros contextos con baja señal, esa premisa se rompe: una transacción puede iniciarse localmente mientras su confirmación, entrega o sincronización continúa incierta. El desafío de diseño consistió en preservar la continuidad sin ocultar lo que el sistema podía y no podía confirmar.

  • La conectividad podía desaparecer durante el pago.
  • Emisor y receptor necesitaban la misma evidencia.
  • La sincronización pendiente podía generar incertidumbre o un pago duplicado.

EVIDENCIA

Lo que reveló la definición del producto

La conectividad no es un momento binario

Evidencia: El journey podía pasar por condiciones online, offline y de reconexión antes de que la transacción quedara completamente sincronizada.

Impacto: Un mensaje genérico de carga o éxito no explicaría el estado real del pago.

La confirmación debe ser compartida

Evidencia: Ambas partes necesitaban acordar el monto y reconocer el mismo registro local de la transacción.

Impacto: El feedback unilateral podía generar disputas o incertidumbre en el punto de venta.

Un estado pendiente necesita un siguiente paso claro

Evidencia: Una transacción registrada localmente aún podía estar esperando la sincronización de red.

Impacto: Las personas necesitaban saber qué estaba completo, qué seguía pendiente y si debían actuar de nuevo.

DECISIONES

Respuesta de diseño

El modelo de interacción separa el registro local de la sincronización de red y mantiene a ambas partes alineadas mediante estados explícitos y evidencia compartida.

Hallazgo

La conectividad puede perderse antes de que la red confirme la transacción.

Decisión de diseño

Separar el registro local de la sincronización online y etiquetar cada estado de forma explícita.

Valor para el usuario

Las personas pueden continuar el intercambio sin confundir un registro local con un pago completamente sincronizado.

Hallazgo

Emisor y receptor necesitan reconocer la misma transacción.

Decisión de diseño

Introducir un handshake antes de completar y proporcionar evidencia equivalente a ambas partes.

Valor para el usuario

Ambas personas acuerdan el monto, la contraparte y el estado antes de cerrar la venta.

Hallazgo

La sincronización tardía puede generar dudas sobre si se debe repetir el pago.

Decisión de diseño

Conservar la transacción en el historial y mostrar estados pendiente, sincronizado o requiere acción.

Valor para el usuario

Las personas conservan la trazabilidad y entienden cuándo el pago está completo sin crear duplicados.

Comprador y comerciante mostrando evidencia coincidente de una transacción de PagoConectado en sus teléfonos
La evidencia compartida ofrece a ambas partes un registro consistente mientras el sistema comunica si la sincronización está completa.

FLUJO FINAL DE INTERACCIÓN

Ingresar pago Revisar detalles Handshake Registrar localmente Compartir evidencia Sincronizar

VALOR

Resultado y aprendizaje

El prototipo establece un modelo de interacción coherente para pagos que pueden registrarse localmente antes de la conciliación con la red. Su valor no está en prometer un procesamiento offline invisible, sino en comunicar explícitamente la evidencia, la responsabilidad y el estado del sistema en cada etapa.

  • La confianza depende de estados comprensibles, no solo de una pantalla final de éxito.
  • La evidencia compartida reduce la ambigüedad entre emisor y receptor.
  • El diseño offline-first debe explicar qué ocurrió, qué está pendiente y qué sucederá después.