Back
Handyman Service Marketplace
Kazi—Two-Sided On-Demand
Service Marketplace
Category:
UIUX Design
Client:
Kazi handyman
Duration:
Discovery to Launch
Role:
UIUX Designer
Platform:
Cross-Functional Squad
01
Context
01 / Project Background
Context & Background
In Nigeria, booking a plumber, electrician, or cleaner still runs on word of mouth and saved phone numbers. Kazi began there: a two-sided, on-demand service marketplace designed from zero. Customers are urban homeowners and renters in cities like Lagos and Abuja — busy, mobile-first, and already comfortable with apps like Bolt and Opay. They want a handyman fast, and they need to know the provider is verified, the price is visible before booking, arrival is trackable, and payment won't turn into a dispute. Providers are independent electricians, plumbers, cleaners, and carpenters who get work through informal referrals, so income is unpredictable; they need steady jobs nearby, a visible reputation, and on-time payment with a record of it. Both sides are hiring strangers on faith.
02
The Problem
02 / The Challenge
The Problem & Challenge
The screens were not the hard part. Making two apps with opposite goals feel like one product was. A customer wants certainty; a provider wants income. Both still had to share one design system, one wallet, and one map, and every shared piece had to serve both sides without favoring either. Three unknowns raised the stakes: trust, money, and pricing. Nigerians already hire strangers through WhatsApp referrals, so a brand-new app had to feel safer than a friend's recommendation. Customers fear paying for bad work, providers fear not being paid, and a single wallet had to calm both at once. And because the informal market runs on haggling, I bet that fixed prices shown upfront would read as relief rather than restriction. I designed the shared systems first, then built each role's screens around them, flagging every assumption I couldn't verify as something to test.
03
My Role & Team
03 / Collaboration
My Role & Team
I was the sole designer on Kazi, owning the product from 0→1 across branding, research, UX, visual design, and interactive prototypes. I shaped the core product decisions, including separate customer and provider apps, a shared wallet, upfront pricing, map-led job tracking, and provider verification during onboarding.
04
Process
04 / Design Process
Design Process & Explorations
Validation came from the brief, market context, and competitor analysis rather than interviews. I identified each user’s core concerns, studied how Nigerians currently find artisans through referrals and WhatsApp, and reviewed platforms like TaskRabbit and Urban Company. This led to three key assumptions: trust over speed, fixed pricing over haggling, and a shared wallet for secure payments. I then built the architecture around one core loop: request → job → completion → payment, using it to define both user journeys and the final product flows.
05
The Solution
05 / Shipped Interface
Solution
Kazi’s MVP connected customers and providers through two apps sharing one wallet, covering the full journey from service request to payment and review. Customers could discover and compare providers, request services, pay securely, track jobs, confirm completion, and rate providers. Providers completed verification, managed availability, accepted nearby jobs, navigated to locations, tracked earnings, and rated customers. Both apps shared one design system with consistent components, typography, and visual language. Features such as chat, promo codes, subscriptions, and multi-city support were intentionally excluded from the MVP.
Design System
Typography & Color
06
Uiux design
Visual Solution
07
Impact & Results
06 / Outcomes & Metrics
Impact & Key Results
Kazi is at concept stage, so there are no launch numbers to report. What exists today is a complete, clickable product: two interactive prototypes — one customer, one provider — that walk the full loop of request, payment, tracking, completion, and rating; a single design system and wallet that make the two apps feel like one product; and an MVP scope defined tightly enough to hand to a developer or put in front of real users. The metrics I'd watch first at launch are booking completion (how many customers who start a request finish it), provider onboarding (how many complete verification and go live), repeat bookings (whether customers return to the same provider), and time to first job (how quickly a new provider gets paid).
08
Reflection
07 / Key Takeaways
Reflection & Lessons Learned
Trust is the product, not a feature. In a marketplace, the screens only matter if both sides believe the other will show up and pay; once every decision was designed around that fear — upfront pricing, a wallet that settles both ends, verified onboarding, live tracking — the rest got easier. The lesson I'd carry forward is that designing for two sides means solving two fears simultaneously, and a fix that calms the customer while worrying the provider is not a fix at all. What I'd do differently: put the prototype in front of real customers and tradespeople earlier, and let their words shape the flows instead of my assumptions.
