Making a complex payment workflow easier to understand.
Payments involved multiple stakeholders, different processes and a mix of customer-facing and internal workflows. The challenge wasn't simply to improve a screen. It was to understand the end-to-end payment process before deciding what to change.
Payments involved more than just paying an invoice
The challenge wasn't simply about improving a payment screen. There were multiple perspectives involved:
- Customers needed to understand what was happening with their payments
- Finance needed to manage and follow up on payment-related processes
- Product needed to improve the experience without disrupting existing workflows
- Engineering needed to work within the technical constraints of the existing payment infrastructure
Before designing a solution, I needed to understand how the payment process actually worked across these different perspectives.
Before designing, I mapped the process
I worked closely with the Finance team to understand:
- How payments were currently handled
- What happened when a payment was successful
- Where problems occurred
- Which steps were manual
- What information Finance needed
- What information customers needed
- Which parts of the process depended on internal systems or teams
Mapping the payment journey
I started by understanding how payments actually worked across the different stakeholders. I mapped the journey from the customer's perspective alongside the internal Finance processes.
Three areas of friction shaped the direction
The discovery work helped us identify the areas where the biggest improvements could be made.
Information and actions were fragmented
Important information about payments was spread across different parts of the experience, making it harder to get a complete picture.
Internal processes influenced the customer experience
The experience couldn't be designed independently from the processes used by Finance and the systems supporting payments.
Not every problem needed to be solved in the same way
Some issues were UX problems. Others were process or technical problems.
Understanding that distinction helped us focus the design effort on the areas where product design could have the biggest impact.
Focus the experience around
what users need to know and do
With the key opportunities defined, I started iterating on different ways to improve the experience.
Make status clearer
Help users understand where a payment is in the process.
Make information easier to find
Bring related payment and invoice information together.
Make next actions obvious
Help users understand what they can do when something requires attention.
A clearer place to understand and manage payments
The final experience brings together the information and actions users need throughout the payment journey.
Give users a clear overview
Users should immediately understand what they owe, what has been paid and what requires action.
Bring key payment tasks together
Invoices, payment methods, billing details and transaction history were brought into a more coherent experience.
Balance security and convenience
Rather than adding authentication everywhere, we explored where additional security was actually needed and how to avoid unnecessary friction.
We didn't launch to everyone immediately
Rather than doing a full rollout, we started with the highest-volume accounts for two weeks.
Validate the experience
Were users able to understand and use the new experience?
Validate the implementation
Did the solution behave as expected in real-world scenarios?
Overall, the initial rollout was positive. The solution performed as expected from a design perspective, while the rollout also surfaced some technical issues that needed to be addressed before expanding it further.
This was valuable because those issues were discovered with a smaller group of high-volume accounts rather than after a full rollout.
After addressing the technical fixes, the improvement could be prepared for the wider user base. The project improved the payment experience while also creating a safer way to introduce the change to customers.
Payment problems aren't always interface problems.
The most valuable part of the work was understanding the wider ecosystem before deciding what the product itself needed to change.