Helping freelancers publish their first service
Osdire · Freelance Marketplace
- Role
- Product/UX Designer
- Period
- June 2025–July 2026
- My Contributions
- Design system · End-to-end product design, pre- and post-launch
- Platforms
- Responsive web application
- Collaborators
- CEO, Marketing, Frontend, Backend and QA
- Methods
- Funnel analysis, session recordings, think-aloud interviews, journey mapping, prototyping, usability testing and UX QA
4x
Fourfold increase in successful service publishing
Background
Osdire is a two-sided marketplace where everyone starts as a buyer by default and becomes a freelancer by completing onboarding, profile setup, and publishing a first service — a flow I designed end to end. Pre-launch, with much of the backend already defined and engineering protecting scope for a fast MVP ship, I flagged the category-selection step as a friction risk. The team made the reasonable call to ship on schedule and revisit it after launch.
Approach
1. Untangled a broken metric before trusting it
Post-launch, the profile-setup step was removed to shorten onboarding — a coordination gap rather than a considered call, since it silently broke the GA event tracking "profile setup completed." Working with marketing, I traced the dead event, cleaned up the reporting, and shifted analysis onto service-publishing data instead, paired with 13 session recordings and a small round of think-aloud interviews with freelancers, arranged quickly through the team's existing marketing relationships since a full research recruitment cycle wasn't realistic on the timeline we had.
2. Confirmed the original risk with real evidence
The four-level category hierarchy I'd flagged before launch was, in fact, the single biggest point of loss in the funnel — even among freelancers who'd shown clear intent to publish, more than 40% dropped at this one step. Across the recordings, the same pattern showed up again and again — one user cycled through six different sub-category choices before giving up; several tried to preview later steps to gauge how much more was ahead and, unable to, dropped rather than commit. Metadata options appearing before someone had settled on a category didn't help — they reopened doubt that had only just been resolved.
3. Reframed the step, within the same backend constraints
Structural changes to this flow were still off the table, so instead of a classification exercise, Step 1 became an expression one: freelancers describe what they do in a few words first, and the system suggests likely categories from that, rather than asking them to navigate a rigid hierarchy blind. I moved metadata later in the flow so it read as an optional refinement rather than a second category decision, added lighter guidance around the offer title after noticing people treated a first draft title as unexpectedly high-stakes, and closed the rest of the journey with smaller steps and a readiness check instead of an ambiguous submit.
The whole cycle — tracing the broken metric, confirming the real problem, designing and shipping the fix — happened in about a week. The team needed a fast turnaround, not a long research cycle, and that pace is part of the story, not a caveat on it.
Before:
Users had to understand the hierarchy before they could categorise their service.
After:
Users could begin with the service they already understood, while the interface helped translate it into the platform's structure.
Service category
Start typing and choose the category that best describes what you do.
Outcome
Service publishing increased fourfold after release — delivered within about a week of tracing the real problem.
Takeaway
The friction I'd flagged before launch turned out to be real — but proving it meant untangling a broken measurement setup first, and doing it fast enough to matter.
Beyond the redesign
The more durable outcome of this period wasn't the interface fix — it was proposing a weekly sync between engineering, marketing, and design leads, so a coordination gap like the one that broke this flow couldn't happen again without everyone seeing it coming first. That became one of the first real cross-functional habits at the company.
Separately, I led discovery for an internal admin platform spanning finance, moderation, marketing, and technical teams — running cross-functional workshops and stakeholder interviews, then using an object-oriented UX approach to model one shared system instead of isolated department screens. It stayed a concept and alignment artifact rather than a shipped product. It's where I learned to model a product as one shared system serving multiple roles and permissions at once, rather than one flow at a time.
My wider contribution to Osdire
This optimisation formed part of a broader product role across the marketplace. I also contributed to:
- Buyer project creation and matching
- Search and service discovery
- Custom offers and negotiation
- Orders and project delivery
- Payments, wallet and billing
- Internal moderation and operational tools
Across these areas, I combined user research, interaction design and product delivery—turning customer and business needs into prioritised workflows, specifications, user stories and testable product behaviour.