Reinventing payables.

In late 2020 Kargo set out to reinvent its platform. The existing system had run into scalability limits, and enough problems had piled up that expanding into a new vertical would have broken it.

Some numbers, data, and statements have been altered to respect confidentiality agreements.

My role: Product Designer, Researcher
Project type: Redesign, Interaction Design, Payment Dashboard
Collaborators: Engineers, Product Manager, Operations, Accounts Payable, Finance
Date & place: January–March 2021 · Kargo Technologies

Screens from the redesigned payment module: scheme detail, payment request list, fee review, and payment request approval

Summary

How might we create a robust payment system that is accurate, fast, reliable, integrated, and scalable?

Rather than patch the payment dashboard again, we rebuilt the platform so that every module could be reworked. I owned the payment module inside the payment platform squad — specifically the disbursement system, the foundational module the rest of it would sit on.

Outcome

~60%

Faster disbursement

Reported improvement in disbursement speed after the redesign.

~75%

Fewer rejected payments

Payment requests rejected each month for the wrong disbursement amount.

100%

Disbursement in-platform

Every disbursement now runs on the platform, up from roughly 70%.

What changed

Review payments in one connected workflow

The new information architecture and infrastructure were rebuilt so the system works around the user. Data is reachable in one click instead of a dozen tabs, tax variables are embedded in the payment scheme, and redundant pages were replaced with access limits and status combinations.

The rebuilt payment system mapped across sales, accounts payable, and finance workspaces, with the earlier weaknesses struck out — The same audit, answered: slow becomes fast, inaccurate becomes reliable.

Payment request accuracy improved by roughly 80%.
Transporter complaints about payment amounts and transfer details dropped by about 90%.

Calculate tax within the payment request

Calculating tax is now a couple of clicks. Truck documents no longer live in a separate Google Drive either — they can be opened straight from the license plate.

Automated tax calculation inside a payment request — Tax calculation, automated.

Review fees and supporting documents in one place

Validating a fee request is smooth now. Reviewers move through documents and their requirements in one place, because every document is centralized and attached to its fee type.

Reviewing fees and creating a payment request with attached documents — Fee review and payment request creation.

Control when disbursement amounts can change

Disbursement amounts can be adjusted at the stages that allow it — and nowhere else. The main shipment fee is generated automatically from the disbursement stage set in the scheme, and it is immutable, so typos stop causing rejected payment requests.

Adjusting a disbursement amount within the stages permitted by the payment scheme — Amounts follow the scheme, not free text.

Deep dive

Context

Quick fixes left payments spread across disconnected tools

It's a literal embodiment of quick fixes.

That was the most concise description of our payment dashboard at the time. These were the first impressions of the system at a glance:

A replication of Excel sheets
Decentralized document management
Unstandardized inputs and flows
Prone to disbursement errors, because the amount to disburse was free text input

Audit of the legacy payment workflow across accounts payable and finance workspaces, labelled slow, inaccurate, and inefficient — Snapshots of the system(s) the payment team ran operations on.

Two legacy systems, an Excel tracker, and multiple Google Drives all feeding into one unresolved payment system — Four sources of truth, one question mark.

Research

Understand how the payment team worked

I partly contributed to this mess — I knew the risk of a quick fix and saw the signs, but didn't act on them during my first three months in the payment squad. So the offensive tone is necessary. We learned it the hard way.

Once we had identified the surface problems, I planned the discovery side of the project.

Hand-drawn storyboard of the discovery process, from management wishlist discussion through contextual inquiry to journey mapping — Discovery process for the project.

Reframing

Rebuild the payment workflow around shared rules

Looking at each problem on its own, every one of them looked straightforward to fix. But we had already learned that another quick fix fixes nothing, so we tied the pieces into a single story and worked out where to intervene:

Build a new module for payment schedules so payments can scale
Streamline the whole process, rather than improving the interface for its own sake

Set goals for accuracy, speed, and adoption

We also sharpened the project goals so we could work backwards from them.

Goal, signal, and metric table covering accurate disbursement, faster disbursement, module adoption, and automation — Goals and signals. Metrics remain confidential.

Agree on principles before delivery

I drafted design principles to keep us pointed at those goals, and the team agreed on them before the delivery kick-off.

Three design principles around a central goal of automation: task-focused contextual design, avoiding dead ends when de-scoping, and not reinventing wheels — Automation is the goal.

Delivery

Validate flows with the people handling payments

Solution validation leaned on the funnel technique in qualitative usability tests with operational staff, plus design reviews with upper management — breaking down and prioritizing macro and micro jobs-to-be-done for each role.