Transactions Redesign
Payana

Round 1 — Understanding the current experience.

Open questions about how they were actually using transactions, and what they expected from it. The pain points that came back were consistent — and pretty damning.

The interviews told us what users felt. The product analysis told us why.

Alongside the interviews, I mapped the transaction model from scratch — how a single payment action generates multiple bank disbursements, how pay-ins and pay-outs relate, how a rejection propagates through the system. You can't design something legible without first understanding what it actually is. This step wasn't optional.

Round 2 — Validating the direction.

Before touching high fidelity, I showed those same users two rough mockups of a unified view. The reaction was fast.

Understanding the transaction model.

Payana's payment model isn't like a standard bank transfer. Users don't pay one supplier at a time — they batch invoices from multiple suppliers into a single payment action. Payana handles the disbursements. One click from the user kicks off a whole cascade of individual bank transfers in the background.

That created the core visibility problem: what you saw in Payana bore no obvious relationship to what your bank statement showed. A single $90 lote in Payana could be five separate movements at the bank — and your accounting team had no way to reconcile them without picking up the phone.

We mapped three possible transaction models before deciding on the structure.

This wasn't just a visual problem — it was an architectural one. How do you represent a transaction that contains invoices from multiple suppliers?

The rejection flow was the most operationally significant problem.

When a pay-out got rejected — at the Cobre level or the bank level — the whole resolution was manual: support got a WhatsApp notification, copied the transaction code, edited data in a back-office tool, and reprocessed the payment. The user had no idea what happened or why.

The redesign flipped that entirely. Rejection reason right there in the transaction detail. Users can edit beneficiary data and reprocess on their own. If they need a refund instead of a retry, that path is there too — no support call needed. Every reprocess a user completes is a ticket that never got opened.

First approach: close to the existing, but unified.

My first wireframe stayed close to the existing experience — deliberately. I wanted a baseline before adding anything. The unified list already solved the core problem: everything in one place, grouped by date, parent transactions expandable to show what was underneath.

Dev constraints can improve design.

My first instinct was a dropdown to expand sub-transactions inline. After testing and talking with engineering, we ran into a performance constraint — dropdowns don't scale at the volume Payana handles. That limitation pushed us toward a panel-based detail view, which honestly worked out better: more space, cleaner list, no performance issues.

The “Recorrido del dinero” (money path) was the most important design decision.

In a payments product, uncertainty kills trust. If you can't tell whether your payment is processing, stuck, or gone — you start doubting the whole platform. I built a step-by-step timeline — visible in both the list and the detail panel — that shows exactly where the money is: received, dispersing, rejected, retried, dispersed. For rejections, the path makes the failure explicit and the fix immediate — reprocess from the same screen, no support call needed.

Search as a first-class feature.

Search wasn't a filter — it was a navigation tool. A user looking for a specific supplier, NIT, ID, or tag needed results across all transaction types at once. Search results came back categorized — Proveedores, Destinatario adicional, Transacciones — so you could jump straight to what you were after.

Final design — everything in one place.

One unified, scannable list of every payment — grouped by date, status always visible, sub-transactions a click away in a side panel that keeps you in context.

Funnel Reproceso (direct reprocess flow).

18.4% of users who opened the transactions tab completed a reprocess. That feature didn't exist before. 18.4% completion on something that previously required a support call is a real number — it means users are actually handling their own payment failures now.

Funnel Search Reprocess.

3.54% of users who came through search completed a reprocess — lower than the direct path, but informative. Users who search are usually exploring, not acting on a specific known problem. That shaped how we thought about the next iteration of search.

The data also surfaced a 56% drop-off between the list and the detail view — which became the next question: what's stopping half of users from going deeper? That's the kind of thing post-launch analysis is supposed to generate.