ABOUT
.webp)
Improving Payment Approvals: From a Simple Request to a Scalable Success
In the fast-paced world of payment processing, every minute counts. What began as a straightforward request—"Add three reminder emails for approvers"—quickly unfolded into a deeper exploration of how we could transform our payment approval process. By asking the right questions and putting users at the center, we uncovered inefficiencies and built a solution that not only boosts successful payments but also accelerates approval times. This case study highlights the journey from initial insight to a robust, scalable design that makes a real difference for everyone involved.
Location
Stockholm, Sweden
Industry
Fintech, SaaS
Role
Sole Product Designer
Methology
Data-Driven Decision-Making, Iterative Testing
01. SCALING THE SOLUTION
It all started with a simple request. But as I dug deeper, I discovered that this wasn’t just about reminders—it was about rethinking the entire payment approval process.
Uncovering the Real Problem
Instead of taking the request at face value, I asked:
-
What is really hindering the approval process?
-
Are we adding value, or merely adding noise?
This led me to map out the entire payment flow—distinguishing between parallel and sequential approvals—and to identify the hidden inefficiencies slowing everything down.
02. DEFINE & PRIORITISE
THE APPROVAL FEATURE TODAY WITH THE PAYMENT FLOW
OUTCOMES & LEARNINGS
Designing the Right Thing vs. Designing Things Right
A stakeholder request is often just the starting point—digging deeper helps uncover the true problem.
Empathy & Data Go Hand in Hand
Balancing qualitative insights with measurable data ensures we meet user needs effectively.
A Feature is Never
‘Finished’
Continuous iteration based on user behaviour and feedback is crucial for long-term success.
HOW APPROVALS WORK AS A FEATURE
04. FINAL ITERATION & HANDOVER
The final design for the MVP version was ready for handover to the tech team. This phase focused on ensuring clarity in implementation while balancing feasibility, scalability, and user experience.
USABILITY TESTING
I also I conducted a usability test with five users to understand their thought processes and why they made certain decisions. In summary, I successfully validated my design choices and effectively pushed back on suggestions that didn’t align with user needs.
A/B TESTING
Throughout the design process, multiple stakeholders weighed in with different priorities:
-
Tech Team: Concerned about the complexity of enabling reminders by default when signatures weren’t yet configured, they wanted to make the UI easier.
-
Commercial Team: Advocated for having the toggle turned on by default.
-
Operations & Support: Focused on reducing user confusion and preventing extra support tickets.
To accommodate these inputs, I developed three different prototypes, each with variations in toggle placement, default states, and explanatory text.
03. IDEATE & TEST
Is a Simple Toggle Enough?
At first glance, the simplest approach seemed to be a toggle switch—turn reminders on or off. However, because reminder emails only work if the approval flow is enabled and at least one signature is required, this simple toggle became more complex upon closer inspection.
Digging Deeper: Interval & Ends After
After talking to clients and analyzing different use cases, we decided the toggle needed more than just an on/off state. We introduced two key variables:
-
Interval: How often should reminders be sent (e.g., every 3 days)?
-
Ends After: When should we stop sending reminders (e.g., after 3 attempts or after a certain number of days)?
REQUEST
More often than not, we would get requests from the Commercial or Sales team.
"Add three reminder emails for approvers"
- HEAD OF ENTERPRISE
HOW WE GOT THERE: THE DESIGN PROCESS
CENTERING THE APPROACH
The design directly addressed their pain points, turning frustrations into efficiencies.
Approvers
Enjoy a streamlined, intuitive reminder system that cuts through the clutter.
Client Operations Team
Now handle fewer support tickets and enjoy smoother payment cycles.
Users
Experience a hassle-free journey, with fewer delays and more transparency.
OUTCOME
20%
Decrease in payment approval time
THE APPROVAL FEATURE FLOW AFTER
This is my typical approach to handing over designs to the tech team. I structure the flow using user stories, as they clearly outline the user’s needs, goals, and expected interactions, making it easier for developers to understand the why behind each feature. User stories also help bridge the gap between design and development, ensuring that functionality aligns with real user scenarios.
By this stage, the lead developer has been involved since the early iterations, and the product managers are well-informed of my findings, playing a key role in making tough decisions. My primary stakeholders in this case are the Client Ops team, who influence the final implementation to ensure operational efficiency.
Thank you for reading!
Would you like to know more? Connect with me on Linkedin, or send me a message below.
