JoJolly: end-to-end HRTech for Italy's hospitality sector, built alone in 4 months
Italy's hospitality sector was hiring illegally because the official alternative was too slow and too complex. I rebuilt the product from scratch, turning a 6-step compliance process into a 3-decision flow.
Role
Sole Senior Product Designer
Timeline
4 months to production
Team
Engineers · PM · No prior design function
Status
Shipped
Key results
Users at peak
Active contracts
Total raised
The platform was competing against phone calls and cash, not other HR tools
Owners needed staff fast, sometimes same-day. Going official meant six compliance steps and a 91% funnel drop-off. So they called someone they knew and paid cash. Workers took those shifts unprotected, uninsured, sometimes unpaid. On the worker side, the problem was different: they couldn't see job details before applying, so they applied blind and churned when reality didn't match.
"What felt like bureaucracy to an owner was legal protection to a worker. The design had to serve both without making either feel like they were doing the other's paperwork."
No interview budget, so I built a methodology from what was available
I triangulated three sources. One finding shaped everything: I was working toward a funding deadline, which meant product maturity features had to be elevated alongside user needs. I made that tradeoff consciously and documented it so the team understood what we were optimising for.
User surveys
Both segments. Owners were already using informal hiring. The platform was losing to doing nothing.
Support tickets + reviews
Primary friction signal. Showed where users broke, not always why.
Stakeholder interviews
Engineers and investors. Reframed prioritisation around what the product needed to demonstrate to close the round.
Make compliance invisible: absorb the legal layer entirely into the system
The goal wasn't to simplify Italian labour law. It was to remove the need for users to understand it at all. I considered a transparency-first approach, showing users the full compliance layer with clear explanations, and rejected it. The funnel data showed 91% drop-off. Clarity wasn't the problem. Presence was. Contracts, insurance, and tax were all handled automatically in the background. Both sides experience one thing: request, match, confirm.
Owners needed speed
Every extra step was a reason to go informal. The flow had to be faster than making a phone call.
Workers needed certainty
"Will I get paid, how much, and when" answered before they committed. Not after.
Two sides, one system, three decisions
End-to-end UX, visual design, and brand across iOS and Android. The compliance layer ran invisibly underneath. Each side had a different trust problem to solve.
Make hiring feel like a confirmation, not a decision
I mapped every legal requirement for a compliant hospitality contract in Italy. Three steps was the minimum that satisfied compliance: define the role, review candidates, confirm the hire. My job was to make those three steps feel like one decision, faster than a phone call.
I considered two alternatives first. A single-screen form had too much upfront cognitive load. A conversational flow was too slow for same-day hiring. Three discrete steps with the matching burden on the platform won. The candidate card surfaced the signals that moved owners to confirmation fastest: verified documents, previous ratings, relevant work history. Compliance trust came from verified badges, a full payment breakdown before confirming, and a flow that felt complete rather than rushed.
Why this was hard
Every legal step I removed from the visible flow still had to happen somewhere. I worked with legal and engineering to define what could be automated and what required explicit user acknowledgment. The line between invisible and uninformed was the hardest call on the project.
Job request confirmation
Candidate search and matching
Experience tier selection
Payment breakdown before confirming
The interdependency
A design decision for workers was a supply decision for owners
Workers couldn't receive shifts until their profile was verified. Owners couldn't confirm a hire until a worker's documents cleared. These looked like two separate onboarding flows. They were the same system.
Too much friction for workers
Fewer verified profiles. Owners couldn't find candidates. The platform felt unreliable on the supply side.
Too little friction for workers
More profiles but lower verification quality. Owners hired workers whose documents later failed compliance checks.
Transparency in outcomes, invisibility of process
Research was clear: workers' single question was "will I get paid, how much, and when." I answered it before they accepted the shift. Projected earnings, deductions, and payment timing in plain numbers at confirmation, not buried in settings or revealed after committing.
There was internal pressure to abstract job details into compatibility signals to keep application volume high. I pushed back. Support tickets showed that workers who applied blind and felt misled churned. Transparency was the retention strategy. Workers landed on full listings with everything visible before applying. Informed workers who committed, stayed.
Why this was hard
Showing everything upfront reduced match rates short-term. I made the case at the cohort level: informed workers who committed returned. Churn was more expensive than fewer applications per job. The data after launch supported it.
Job listing with full details
Pay breakdown and shift details
Active shift card
Post-shift review
Progressive disclosure: information surfaces when it's actionable, not upfront
As regulatory requirements grew, more documents and mandatory disclosures were added. There was pressure to surface everything to users for transparency. I argued against it. Showing the full compliance layer early caused drop-off. Each piece of information needed to appear at the moment the user could act on it, not before.
I monitored closely for any signal that users felt blindsided. It didn't come. I tracked support tickets and post-shift reviews specifically for signals of confusion or surprise around contracts and payments. Nothing surfaced. The invisibility held. Users never felt the weight of Italian labour law. They saw a request, a match, and a confirmation. That invisibility was the design achievement.
Why this was hard
The line between "invisible" and "hidden" is a trust decision. If users ever felt surprised by a deduction or a contract term, the whole system would break. I monitored support tickets and post-shift reviews for any sign of confusion. It never came.
Built a design function from zero in four months
The app had no design culture when I joined. I built the foundation and credibility at the same time, collaborating daily with engineers on constraints, the PM on prioritisation, and investors on what the product needed to demonstrate to close the round.
Research practice
Built from scratch. Surveys, support analysis, stakeholder interviews with no budget.
Visual language + brand
Defined end-to-end, from components to brand voice across iOS, Android, and web.
Investor collaboration
Shaped which features demonstrated product maturity. Design became part of the funding argument.
Shipped in 4 months
Production-ready across three platforms. Design culture established, not just deliverables.
Four months to production meant making peace with known gaps
The compliance edge cases
We designed for the standard case and let real usage surface edge cases. Right call given the timeline, but some users hit walls we'd already seen coming. I'd want more time on that layer in a second pass.
The research constraint
Support tickets showed where users broke, not what they worked around silently. I was designing with evidence of failure, not behaviour. It got us to €3M and 20k users, but I'd fight harder for structured interviews next time, even async and pre-release.
What this project taught me about two-sided products
Designing for compliance is designing for trust
The legal layer wasn't a constraint on top of the design problem. It was the design problem. Making it invisible required knowing exactly where it could be absorbed by the system and where it had to surface.
Two-sided products need two different trust strategies
Same compliance layer, completely different design expression on each side. Holding both user mental models at once without collapsing them into one is harder than it sounds.
Design credibility in engineering-led teams is earned, not given
The product argument to investors was stronger because design was part of it, not just the visual layer on top. That doesn't happen automatically in teams that haven't worked with a designer before.