Case Study

Lila’s desk

Lila’s Desk connects doctors with assistants for fast, flexible support. Doctors can post tasks or send direct requests, while assistants apply, collaborate, and get paid - all in one place.

Project
Web app
My role
Lead Product Designer
Responsibilities
IA, User Flows, UI Design
Lila's Desk assistant profile visual
Assistant illustration background
Work Lila's Desk

Unclear pricing negotiation

01 Challenge

Tasks delegated through the platform varied significantly in complexity and scope.

For some tasks, users didn’t know the expected price and wanted to compare multiple offers before making a decision. For other tasks, users already trusted a specific assistant and wanted to hire them directly with a predefined offer.

01 My approach

Limit negotiation in 2 steps send offer & respond to offer

Idea is to eliminate back-and-forth negotiation and reduce the hiring process to a predictable 2 step model.

The system was designed around two actions only:

  • making an offer
  • accept / decline an offer
2 steps = 01 Offer 02 Response

Separating bidding from direct offers

01 Solution

I introduced two distinct hiring flows based on different user intentions and goals. Bidding (Job Ad) VS Direct Request

Profile completion progress Onboarding steps card

Bidding (Job Ad)

Users publish a task as a Job Ad in order to receive multiple offers and compare available options.

→ optimized for price discovery

Assistant card and bid flow

Direct Request

Users select a specific assistant and send a predefined offer that can either be accepted or declined. Pricing expectations become immediately clear and negotiation remains structured and predictable.

→ optimized for trust-based collaboration

Fixed price task card
Edgecase

Hybrid scenario — targeted bids

Users may trust a specific assistant but still want pricing flexibility.

To support this behavior, users can share a Job Ad directly with selected assistants and receive targeted bids without changing the core hiring structure.

02 Challenge

Different work structures require different payment expectations

Some tasks had a clearly defined scope and fixed outcome, while others involved recurring support or ongoing collaboration with changing workloads.

Using a single payment structure for all scenarios would create confusion around

  • what exactly is being paid for
  • how work is measured
  • what level of commitment is expected from both sides

02 My approach

Match payment logic to the natural structure of work

Instead of forcing all tasks into the same pricing model, payment expectations are aligned with the actual nature of the collaboration.

Each payment structure feels intuitive based on:

  • predictability of the task
  • expected duration
  • level of flexibility required
Fixed Price Monthly Retainer Paid by Hour
02 Solution

Three payment structures based on type of collaboration

I introduced three distinct payment models: Fixed Price, Monthly retainer, Paid by Hour.

01 Fixed Price

Used for tasks with a clearly defined scope and outcome.

→ straightforward, short-term work

Paid by hour task card

02 Monthly Retainer

Used for recurring support with a predefined monthly workload.

→ structured long-term collaboration

Monthly retainer task card

03 Paid by Hour

Used for ongoing work with variable scope and flexible monthly hours.

Users can track hours throughout the month while still setting a maximum monthly limit.

→ high-trust, flexible collaborations

Paid by hour task card
03 Challenge

Reducing onboarding friction & maintaining platform trust

Users needed to complete multiple verification and profile setup steps before fully participating on the platform.

However, requiring users to complete everything upfront created unnecessary friction before they even understood the platform’s value.

At the same time, unrestricted access would reduce trust and platform reliability.

03 My approach

Allow exploration before full commitment

Instead of blocking users behind mandatory onboarding steps, allow them to enter and explore the platform early.

Goal was to let users:

  • browse assistants or available jobs
  • understand how the platform works
  • become invested in the experience

before requiring complete verification.

Fill necessary data Explore platform Finish profile
03 Solution

A two stage onboarding

Users can complete their profile gradually instead of finishing the entire onboarding process upfront. This creates a balance between early exploration and platform trust.

Actions that can be temporarily skipped during onboarding:

  • profile verification
  • payment setup
  • additional profile completion

These requirements become mandatory before users can:

  • apply for jobs
  • accept offers
  • start collaborations through the platform
Direct request review and pay interface
Lila's Desk task management dashboard
See Help Desk Ticketing System