MANZILUEM Edgenta · Jeddah
MANZIL
From request to repair, all in one click.
Manzil is an on-demand home services platform: AC repair, cleaning, plumbing, laundry, pest control. What makes it hard is not the booking. It is that a customer, a technician and a coordinator all have to be looking at the same job at the same time, from three different apps, and none of them can afford to be wrong about it.
Booking a technician in Jeddah worked roughly the way it worked twenty years ago: you asked a neighbour, you called a number, and then you waited without knowing whether anyone was coming. Three groups were losing something in that gap, and each of them blamed one of the others.
"I need an AC repaired today. I do not know who is good, what it should cost, or when they will actually turn up."
So they call three numbers, take the first person who answers, and have no recourse when the work is poor.
"Some weeks I have six jobs, some weeks I have none. I never know what I am earning this month."
So skilled technicians leave for salaried work, and the supply side keeps thinning out.
"I am assigning jobs over WhatsApp and tracking them in a spreadsheet. I find out about problems from the customer."
So dispatch is guesswork, double bookings happen, and nobody can prove what went wrong.
Written as one sentence, the brief was this: managing on-demand services like AC repair and cleaning is challenging because there is no centralised place where all three parties see the same truth. Users cannot locate reliable workers, workers face inconsistent job offers, coordinators struggle with assignment and monitoring, and without a shared platform the miscommunication compounds into frustration for everyone.
That framing is what made this a three-product brief rather than a booking app with an admin panel bolted on. If any one of the three surfaces is weak, the other two stop being trustworthy.
Six weeks of groundwork before a single high fidelity screen. Research across all three personas, journey maps, information architecture, wireframes, prototypes, then usability testing to check the assumptions had survived contact.
I audited TaskRabbit, Dari and Urban Company against Meem Facility Management on market share, value proposition, advantages and disadvantages. All four converge on the same table stakes: service requesting, professional vetting, payment integration, customer support, ratings and reviews. Building those well is entry, not advantage.
The separation was in focus. TaskRabbit spreads across everything from furniture assembly to event staffing. Dari narrows hard onto regional Saudi needs like beauty and cleaning. Urban Company sits between them with a structured, predefined catalogue aimed at urban centres. The gap Manzil could occupy was regional specificity plus enterprise-grade coordination, which is exactly what a facility management company already has and a consumer marketplace does not.
Three products, one designer, three developers. Everything could not ship, so the feature list went onto an urgency and impact matrix and the argument happened there instead of in a meeting.
The interesting call is the bottom right. Admin dashboards and usage insights are the things a client normally asks for first, and they went last, because a dashboard reporting on a system nobody trusts yet is a report about nothing. Availability, pricing and tracking had to be real before measuring them meant anything.
The journey map runs four stages: awareness, activation, service request, service execution. Mapped against narrative, touch points, emotional state, pain points and opportunities, the emotional low is not the booking. It is the wait between booking and arrival, where the customer has committed money and has no information. Every feature in the top-right quadrant above exists to fill that specific gap.
Same data, same job, three entirely different jobs to be done. Pick a product to see what it had to solve.
A customer arrives with a broken thing, not a service category. So the home screen leads with reorder services, because the second booking is the one that builds the business, then popular services with prices visible on the card. Search accepts plain language: home cleaning, laundry, pest control.
Booking is a three-step bar the whole way through: service, available slot, payment. The step indicator never disappears, so the effort always feels bounded.
The worker app exists to answer three questions fast: what is the job, where is it, and what am I earning. The scope of work module was the single most requested change from the technician side, because arriving at a job without knowing what was actually agreed is how a service call turns into an argument.
Compensation is explicit rather than implied: base pay, incentives tied to jobs completed and feedback, and cash-on-delivery tracked separately so the worker is never carrying an unreconciled balance.
The console is where the spreadsheet died. Assignment management shows every pending job with worker, supervisor, delivery method, time and a status that carries a word rather than just a colour: assigned delivery, assigned worker, pending assignment, partially assigned, rejected. In a dispatch tool, ambiguous status is the actual failure mode.
Worker management splits internal staff from external service providers, since they have different onboarding, different pay structures and different levels of trust, and the coordinator needs to know which one is turning up.
The flow diagrams are the part of this project I would show first in an interview. Three trees, one per role, drawn so that every branch on the admin side has a matching branch on the worker or client side. If a coordinator can change a scope of work, the worker tree needs a node where that change arrives. Drawing it this way is how you find the missing states before engineering does.
A deliberately small system, because one designer supporting three products across two languages cannot maintain a large one.
The icon set is drawn in two weights, outline and bold, so the same symbol can carry both inactive and active state without a second asset. On a platform with a dense service catalogue and a dark navy chrome, that one decision removed a large category of visual inconsistency.
Navy carries structure, periwinkle carries action, amber carries progress, and green and red are reserved strictly for job state. Nothing decorative uses any of them.
The thing I am most satisfied with here is not a screen. It is that a coordinator can now answer a customer's question without phoning the technician, because all three surfaces are reading the same job. That was the entire point, and it is the sort of outcome that is invisible in a portfolio shot.
I started with the customer app because it is the visible one. The coordinator console is what actually decides whether the platform works, and it should have been drawn first.
Designing bilingual in parallel was the right call, but I still laid out in English and checked in Arabic. Reversing that order would have caught several layout problems earlier.
The journey map said the emotional low was the wait between booking and arrival. Everything valuable I designed lives in that gap, and I found it in research rather than in a screen.
Five explicit states beat any colour system in a dispatch tool. This is now the first thing I check in any operational interface.
A debt recovery platform serving three parties with opposing interests, plus a conversational AI agent.
Read case study →
Pakistan's largest health platform, rebuilt around symptoms instead of specialties. +30% conversion.
Read case study →
Fourteen HR modules in one subscription platform, designed end to end in six weeks.
Read case study →
NFT event ticketing that kills counterfeits and scalping, sold without ever leading with blockchain.
Read case study →
School payments and a learning app inside a platform with 16 roles and 4 languages.
Read case study →