PROJECT OVERVIEW
I architected and redesigned an existing payments product through Plexable. The work brought biller and client experiences into one coherent system without pretending the platform started from zero.
CLIENT
GoPay
MY ROLE
Product architect and design lead, via Plexable
SCOPE
Product architecture, mobile experiences for billers and clients, invoicing and payment flows, wallet and dashboard patterns, and design-system direction
VALIDATION
Delivered product architecture and mobile workflow system
TIMELINE
2024 engagement
TEAM
I led the product architecture through Plexable. The studio and GoPay teams carried that direction across the biller and client mobile experiences.
The context
GoPay already served a complex billing and payments domain. The design challenge was to raise the product's clarity and consistency across two audiences with different responsibilities, while respecting existing operations and regulated workflows.
My responsibility
I defined the product structure, separated biller and client responsibilities, and shaped the mobile flows that connected invoicing, payment, account visibility, and recurring operational tasks.
Modernising the product without rewriting its history
CONSTRAINTS & TRADE-OFFS
Shared financial logic. Different daily jobs.
● RESEARCH & CONTEXT
Architecture before interface
I started with the operating model: who issues an invoice, who acts on it, which states both sides share, and where permissions diverge. That structure determined the interface.
● PRODUCT DECISIONS
Three decisions that organised the platform
● PROCESS & EVIDENCE
The product map, biller/client responsibility split, core payment journeys, and reusable patterns show how a shared domain model became two focused mobile experiences.
WHAT I’D IMPROVE
What improved
Biller and client responsibilities became explicit in the product structure.
Shared financial objects and interface rules created consistency across both apps.
WHAT I LEARNED
What I learned
Product modernisation begins by understanding the operating model, not by replacing every screen.
Role separation works best when the underlying domain model remains shared.
More work
WHAT'S NEXT STARTS WITH A CONVERSATION.