Zart: A home-services marketplace built on trust
I lead mobile design at Zart, a marketplace that connects people with vetted plumbers, electricians, carpenters and painters. The brief said booking app. I argued that booking a stranger is easy and trusting one is hard, and the team built a trust platform instead.
A customer uses Zart a few times a year. A tradesperson uses it every working day. So it is two experiences on one set of jobs: a quick, reassuring one for the person hiring, and a working one for the person doing the job.
Two people, two products
- CustomerQuick, occasional, needs reassurance
- TradespersonDaily, practical, needs control
- SharedSame jobs, same data, same stages
Treating them as one user with one app would have served neither. The customer side finds a trade in seconds and shows why a person can be trusted. The tradesperson side is a dashboard of jobs, a schedule, and messages tied to the job they are about.
Verified by Zart's own team
- 1A photo and a government ID
- 2Checked by the operations team
- 3A badge on the profile, with the evidence behind it
The customer describes the job, and Zart narrows the field to verified people who fit it and work nearby. Nobody is handed a list of strangers and left to gamble.
Selected screens: from the first search to getting paid
What the research changed
- Reliability beats priceProfiles lead with verification and track record
- Messages get lostEvery message belongs to a job
- Unclear scope starts disputesBooking states scope and timing before anyone commits
Customers cared more about whether someone would turn up and do the job properly than about the lowest quote. Tradespeople were losing details across calls and chats. And disputes tended to start with scope or timing that was never agreed. Fixed job stages came from the same work: structured workflows gave more consistent service, so every job moves through the same stages whatever the trade.
How I ran it
- WorkshopsAlignment sessions with stakeholders and the operations team
- MappingA tradesperson's working day, and the customer's journey
- TestingBooking prototypes with users, and a look at competing marketplaces
Customer mode and tradesperson mode became how everyone described the product, which settled most arguments about what belonged where. I turned job stages and verification steps into flows and states engineering could build, and helped shape how the platform would grow to cover more trades.
Decisions I took
I've led mobile design at Zart from the first workshops to the shipped app, and still oversee it, working with the operations team and engineering. Above is what the research changed, followed by the decisions that shaped the product and what each one cost.
-
Reframe it from a booking app to a trust platform
Why The brief said booking app. Booking a stranger is easy and trusting one is hard, so verification, stated expectations and job tracking became the product rather than features for later.
Cost More had to ship before the first release, and the team had to be talked round to a bigger first version.
-
Split it into a customer mode and a tradesperson mode
Why A customer uses Zart for minutes, a few times a year. A tradesperson uses it every working day. One app for both would have served neither, so they share jobs and data but not screens.
Cost Two experiences to design and keep consistent, and every change to a job has to be checked on both sides.
-
Let the customer describe the job, and let Zart narrow the field
Why A list of strangers is the gamble all over again. The customer says what they need, and Zart offers verified people who fit the job and work near the address.
Cost Matching is only as good as the skills and locations on file, which the operations team has to keep clean.
-
Have Zart's own team do the verification
Why A badge means something only if a person checked. A tradesperson submits a photo and a government ID, and the profile carries the result and their history from then on.
Cost A manual queue that grows with every tradesperson who joins.
-
Tie every message to a job
Why Tradespeople were juggling calls and chats with no record, and details got lost. On Zart a message belongs to the job it is about.
Cost No general inbox. A conversation that is not about a job has nowhere to go.
-
Give every trade the same job stages
Why Structured workflows gave more consistent service in testing, so a plumbing job and a painting job move through the same stages.
Cost Some trades fit the stages less neatly than others.