RAMEENA JALIL

Product Designer

WORK

ABOUT ME

PLAYGROUND

HELLO.UXBYRAY@GMAIL.COM

Two‑Sided Care Marketplace

Designing an end‑to‑end job lifecycle for a two‑sided
care platform, focusing on trust, accountability, and payments.

Designing an end‑to‑end job lifecycle for a two‑sided care platform, focusing on trust, accountability, and payments.

Enter password to view case study

Context & Background

Context & Background

Mashcare is a care marketplace connecting families with care providers (babysitting, tutoring, aged care).

Prior to Mashcare, coordination happened via emails and informal channels, leading to low trust, no tracking, and payment disputes.

Duration: 1.5 month (including feedback cycles)

Core Problem Statement

Core Problem Statement

Families and care providers lacked a structured, trustworthy system to manage the full care job lifecycle, from hiring to completion and payment, resulting in coordination breakdowns and disputes.

Team

Team

  • Me (Lead Product Designer)

  • Project Coordinator from dev team

  • 1 Australian Sales Stakeholder

  • C-Level Executive, Mash Care

Primary user:

Primary user:

Family / Client (initiates jobs, hires, pays, reviews)

Family / Client (initiates jobs, hires, pays, reviews)

Secondary user:

Secondary user:

Care Provider (applies, performs work, gets paid)

Care Provider (applies, performs work, gets paid)

While Mashcare serves two user types, the experience was intentionally designed with the Family as the primary persona to keep the system coherent, while protecting care provider trust.

While Mashcare serves two user types, the experience was intentionally designed with the Family as the primary persona to keep the system coherent, while protecting care provider trust.

Constraints & Realities

Constraints & Realities

  • No existing platform (0→1)

  • Two‑sided marketplace complexity

  • Payments handled inside platform

  • Subscription‑gated access

  • High trust & safety requirements

  • No existing platform (0→1)

  • Two‑sided marketplace complexity

  • Payments handled inside platform

  • Subscription‑gated access

  • High trust & safety requirements

Core Workflow Overview

Core Workflow Overview

Key Flows & Screens

Job Creation (Family)

Job Creation (Family)
Designed to reduce misaligned expectations later in the lifecycle.

Designed to reduce misaligned expectations later in the lifecycle.

Applicant Review & Hiring

Applicant Review & Hiring
Once a provider is hired, other applicants are locked out to avoid conflicts.

Once a provider is hired, other applicants are locked out to avoid conflicts.

In Progress → Completion → Payment

In Progress → Completion → Payment
Payment is released only after job completion is confirmed.

Payment is released only after job completion is confirmed.

Dispute / Review (Exception Handling)

Dispute / Review (Exception Handling)
Disputes were treated as a first‑class state, not a hidden support flow.

Disputes were treated as a first‑class state, not a hidden support flow.

Key Design Decisions & Trade‑Offs

Key Design Decisions & Trade‑Offs

Prioritizing Family as the Primary Persona
Prioritizing Family as the Primary Persona

Decision: Designed Mashcare with the Family as the primary persona to anchor the core job and payment lifecycle.

Why: Families initiate jobs, confirm completion, and release payments, making them central to system clarity.

Trade-off: Required additional safeguards to ensure care providers still felt protected and fairly treated.

Decision: Designed Mashcare with the Family as the primary persona to anchor the core job and payment lifecycle.

Why: Families initiate jobs, confirm completion, and release payments, making them central to system clarity.

Trade-off: Required additional safeguards to ensure care providers still felt protected and fairly treated.

State-Driven System vs Screen-Driven UI
State-Driven System vs Screen-Driven UI

Decision: Structured the product around explicit job states instead of isolated screens.

Why: System states reduced ambiguity, prevented misuse, and aligned design with engineering logic.

Trade-off: Increased upfront complexity during design but improved long-term scalability.

Decision: Structured the product around explicit job states instead of isolated screens.

Why: System states reduced ambiguity, prevented misuse, and aligned design with engineering logic.

Trade-off: Increased upfront complexity during design but improved long-term scalability.

Payment After Job Completion
Payment After Job Completion

Decision: Payments were released only after the family confirmed job completion.

Why: This protected families and aligned payment with actual service delivery.

Trade-off: Introduced potential payout delays for care providers, requiring clear communication.

Decision: Payments were released only after the family confirmed job completion.

Why: This protected families and aligned payment with actual service delivery.

Trade-off: Introduced potential payout delays for care providers, requiring clear communication.

Subscription-Gated Access
Subscription-Gated Access

Decision: Core platform features were gated behind a subscription for both user roles.

Why: This filtered low-intent users and supported platform sustainability.

Trade-off: Created a higher entry barrier, mitigated through clear upgrade flows.

Decision: Core platform features were gated behind a subscription for both user roles.

Why: This filtered low-intent users and supported platform sustainability.

Trade-off: Created a higher entry barrier, mitigated through clear upgrade flows.

Explicit Dispute Handling
Explicit Dispute Handling

Decision: Disputes were treated as a first-class system state rather than a hidden support flow.

Why: Care services involve high trust and emotional risk, making failure states unavoidable.

Trade-off: Added system complexity but significantly increased transparency and trust.

Decision: Disputes were treated as a first-class system state rather than a hidden support flow.

Why: Care services involve high trust and emotional risk, making failure states unavoidable.

Trade-off: Added system complexity but significantly increased transparency and trust.

Learnings
Learnings

Trust must be designed into systems

Trust must be designed into systems

Trust in care services cannot rely on visual reassurance alone. It must be enforced through clear system states, controlled actions, and payment accountability across the job lifecycle.

Explicit states reduce disputes

Explicit states reduce disputes

Defining clear job and payment states reduced ambiguity around completion and payouts, helping both families and care providers understand expectations at every stage.

Two-sided platforms require prioritization

Two-sided platforms require prioritization

Designing for both user types equally increased complexity. Prioritizing the family as the primary persona helped maintain system clarity while still safeguarding care providers.

Future Improvements
Future Improvements

Payment delay & non-payment handling

Payment delay & non-payment handling

Introduce time-based reminders and escalation paths for delayed confirmations or failed payments.

Automated reminders & escalation

Automated reminders & escalation

Reduce manual intervention by automating nudges before disputes are raised.

Internal operational tooling

Internal operational tooling

Support teams would require internal tools to manage disputes, exceptions, and trust reviews at scale.

Smarter matching with data

Smarter matching with data

With sufficient usage data, provider matching could be improved based on reliability, availability, and past performance.

Outcome & Impact

Outcome & Impact

Mashcare resulted in a clearly defined, end-to-end job lifecycle that replaced informal coordination with a structured, trust-driven system.

Mashcare resulted in a clearly defined, end-to-end job lifecycle that replaced informal coordination with a structured, trust-driven system.

Business Impact
Business Impact

  • Subscription-based monetization

  • Higher quality interactions

  • Reduced operational chaos

System Impact
System Impact

  • State-driven, scalable architecture

  • Clear role-based permissions

  • Easier engineering handoff

User Impact
User Impact

  • Clear job status visibility

  • Improved trust through reviews and disputes

  • Reduced ambiguity around payments

This project reflects my approach to product design, defining clear system behavior, making informed trade‑offs, and building trustworthy foundations that can scale in complex domains.

This project reflects my approach to product design, defining clear system behavior, making informed trade‑offs, and building trustworthy foundations that can scale in complex domains.

hello.uxbyray@gmail.com

hello.uxbyray@gmail.com

Some projects are password-protected. If you’d like access or a walkthrough, feel free to contact me via email.

Some projects are password-protected. If you’d like access or a walkthrough, feel free to contact me via email.

© 2026 Rameena Jalil

Back to Top ↑

Back to Top ↑

Create a free website with Framer, the website builder loved by startups, designers and agencies.