Designing launch-critical conversion flows for a two-sided service marketplace

The challenge was not simply that the product had friction. It was that some trust requirements appeared before users had enough motivation to complete them.

Customers could be blocked by account creation before submitting a request. Providers could be asked to verify before seeing whether real jobs were available. Long mobile forms, unclear offer states, and cancellation/payment moments also created risk around conversion.

The design question became:

How might we preserve the trust mechanisms the marketplace needed while moving friction closer to moments of user intent?

I helped translate the launch strategy into the core marketplace and conversion flows needed for beta:

• Customer request creation
• Provider job discovery
• Provider activation and verification
• Offer submission
• Offer comparison and acceptance
• Payment / acceptance-state communication
• Autosave and draft recovery
• Completion, cancellation, and review states

I also helped shape the product’s launch-ready identity so the marketplace felt more credible and coherent.

Under launch constraints, the better question was:

What is the minimum viable experience users can move through without hesitation or confusion?

That shifted the work toward the flows most likely to affect early marketplace liquidity: request creation, provider activation, offer comparison, proposal submission, recovery states, and acceptance moments.

The guiding principle became:

Friction should appear when users understand why it exists.

After mapping the marketplace loop, I focused the redesign around five decisions that affected launch readiness: onboarding timing, verification timing, offer comparison, acceptance/payment clarity, and provider effort recovery.

The original flow introduced major requirements before users had experienced enough value.

Customers could be asked to create an account before submitting a request. Providers could be asked to complete verification before seeing whether real jobs were available.

I proposed moving these requirements closer to moments of clear intent:

For customers, account creation moved to the point where it unlocked receiving offers.

For providers, verification moved closer to offer submission and payment eligibility.

This preserved trust while making onboarding feel connected to a clear user goal.

The offer flow was one of the highest-trust moments in the product.

Customers needed to compare providers quickly, but the decision could not be reduced to price alone. They also needed to understand who the provider was, whether they could trust them, what was included, and what would happen after accepting.

I structured the offer card around four questions:

• Who is this provider?
• Can I trust them?
• What exactly are they offering?
• What happens if I accept?

The revised card prioritized provider identity, rating, verification status, response time, quoted price, proposal message, included services, and clear next actions.

The goal was to make each offer feel like a service agreement, not just a price quote.

Accepting an offer was a high-trust conversion moment.

Users needed clearer expectations around what happens next: when the job is confirmed, how payment is handled, when the provider is notified, and what happens if the job is cancelled or disputed.

I recommended clearer microcopy and state communication so accepting an offer felt like a protected next step, not a loss of control.

Suggested microcopy:

The provider will not be paid until the job is confirmed.

Provider setup and proposal creation required detailed mobile forms. Losing progress during these flows could hurt provider activation.

I proposed autosave and draft recovery across long provider-side flows so providers could continue where they left off instead of losing work.

Key states included:

Saving...

Saved automatically

Draft restored

Continue where you left off

A full redesign would have improved the ideal product experience, but it risked delaying beta launch.

I helped separate the work into what needed to be solved before launch, what could improve after beta, and what should wait until the marketplace had more usage data.

This made shipping part of the design constraint.

The project gave Servidos a clearer UX foundation for beta launch.

Since launching in January 2026, Servidos has averaged approximately 10% week-over-week traffic growth, according to company-reported analytics.

The work clarified how customers enter the marketplace, when providers encounter verification, how offers communicate trust, how acceptance/payment states are explained, and which UX improvements were critical before launch.

The main outcome was decision clarity: the founder had a sharper product path for launching the marketplace while preserving trust, improving conversion flow, reducing harmful friction, and avoiding a full redesign delay.

The work also helped establish a launch-ready visual identity foundation for the product.

Servidos taught me that early-stage product design is not about designing the most complete version of a product.

It is about identifying the smallest set of decisions that make the product usable, trustworthy, and shippable.

The project pushed me to think beyond screens and into system behavior: when to ask for trust, when to reduce effort, when to preserve progress, and when to defer complexity.

The biggest lesson was that friction is not always bad. In a marketplace, some friction creates safety, some creates trust, and some protects the business.

The designer’s job is to decide where that friction belongs.