I designed Oloja from the ground up — a service marketplace connecting customers with providers through transparent offers, negotiation and escrow-protected payments.
I received the initial product brief from stakeholders and translated it into the product experience. I spoke directly with the target audience, designed the customer and provider experiences, created the design system, and prepared the product for development.
The product did not ultimately launch, due to technical and company-level constraints — that's part of this story, not hidden from it.
Oloja was designed to connect customers who needed services with providers who could deliver them.
But both sides had reasons to hesitate. Customers didn't know if a provider could be trusted, whether a price was fair, or what would happen after they paid. Providers didn't know how they'd get discovered, whether an enquiry would turn into paid work, or whether they'd get paid at all.
The challenge was to design a marketplace that worked for both sides of the transaction — not just a platform for discovering services.
“Optimising one side of a marketplace can easily create friction for the other.”
I spoke with members of Oloja's target audience through Zoom conversations to understand how they currently find, evaluate and pay for services.
Users didn't want to rely only on the platform's promise that a provider was trustworthy. Ratings, reviews and previous work could help them evaluate providers before committing.
Users wanted to compare different providers and offers rather than being locked into a single quote.
Providers wanted access to relevant customers and opportunities to earn through the platform.
Being visible to more customers could mean spending more time answering enquiries that never became paid work.
Customers wanted protection when paying for work; providers wanted confidence that their payment would be secured.
"Create a marketplace for customers and service providers" — the brief said. It didn't say how the marketplace should actually work. I explored three transaction models before settling on the structure for Oloja.
Ratings, reviews, work history
Public offers, comparable proposals
Escrow, payment states
Customer confirmation
Instead of keeping provider proposals hidden inside private conversations, offers were designed to be visible within the marketplace.
Customers could compare proposals before choosing. Providers could understand the competitive context.
The trade-off: providers had less control over keeping pricing private — in exchange for a marketplace with real pricing transparency.
Unrestricted chat was limited until a transaction had actually progressed.
Providers could otherwise lose significant time answering questions about projects that never became paid work.
The trade-off: customers had less free-form conversation before choosing a provider — prioritising a clearer transition from interest to commitment.
Payment was built around escrow rather than sending money directly to the provider on commitment. The customer pays, funds are held, the provider completes the work, the customer confirms, and only then is payment released.
Protection for both sides — customers weren't handing money directly to a stranger, and providers had a defined payment mechanism once work was accepted and completed.
The trade-off: escrow adds transaction states and requires the customer to actively confirm completion — extra structure in service of the trust model.
Every major decision had to account for customers and providers at the same time.
Because I owned the product design end-to-end, I also created the Oloja design system — foundations, components and patterns that could support multiple user types, transaction states and future iterations.
Discovery, task creation, offers, provider profiles
Opportunities, offers, work management, earnings
Payment, escrow, confirmation, completion states
Navigation, components, states, design system
I completed the UX/UI design and design system, and handed the work over for development.
The product did not ultimately launch, due to technical and company-level constraints outside the design work itself.
Instead, this case study demonstrates the work I was responsible for: research → product exploration → UX architecture → UI design → design system → development handoff. The designs were prepared as a complete product experience, not isolated screens.
How often does a customer choose a provider after receiving offers?
Do providers who sign up actually submit offers?
How many accepted jobs successfully reach completion?
Where do customers drop out of the payment or escrow flow?
Where does trust break down between customers and providers?
Do customers return, and do providers keep participating?
Marketplace design isn't simply about connecting two people. You're designing the rules that govern what happens between them.
Those decisions became as important to the product as the screens themselves.
Translated an initial brief into a structured product experience.
Spoke directly with the target audience on trust, pricing, provider needs.
Designed customer and provider experiences from the ground up.
Designed the mechanics behind offers, negotiation, payment, completion.
Created the reusable system supporting the entire product.
Brief and research through design and development handoff.
