Charitize

Designing a three-sided marketplace for good

A six-week sprint to design a web-based MVP that automated connections between buyers, volunteers, and nonprofits — replacing a manually-operated Wix site with a scalable, trust-driven platform.

Client

Charitize

Project Timeline

June 2018

Industry

Nonprofit / Crowdfunding Tech

Scope of work

UX Research

Product Design

Interaction Design

The Problem With Good Intentions

Charitize had a compelling idea: let buyers pay for services offered by skilled volunteers, with the proceeds funding a charity of their choice. Everyone wins — buyers get the service, volunteers contribute to a cause, and nonprofits receive funding they wouldn't otherwise see.

Challenge

Challenge

Charitize's original Wix site ran on manual coordination — every buyer-volunteer match happened over email. With no automated system and three user types who only got value if the others showed up, the platform couldn't scale. We had six weeks to design an MVP that replaced human intervention with a trust-driven, self-sustaining marketplace.

Solution

Solution

We mapped task flows for all three user types before touching screens, grounding every design decision in what motivated each group to participate. I focused on the buyer's booking experience and the organization profile pages — designing both to do double duty: convert new users while giving returning ones a reason to stay.

My Contribution

My Contribution

This was a team project across a bootcamp cohort. My focus areas were the buyer's service booking flow and the profile pages for organizations and causes — both public and private views.

What I owned end-to-end: understanding buyer motivation, designing the booking experience, and working through the questions the org profile raised — what should be public vs. private, whether to include a dashboard, and how much volunteer information a buyer should see versus a community administrator.

The Problem With Good Intentions

Charitize had a compelling idea: let buyers pay for services offered by skilled volunteers, with the proceeds funding a charity of their choice. Everyone wins — buyers get the service, volunteers contribute to a cause, and nonprofits receive funding they wouldn't otherwise see.

Challenge

Charitize's original Wix site ran on manual coordination — every buyer-volunteer match happened over email. With no automated system and three user types who only got value if the others showed up, the platform couldn't scale. We had six weeks to design an MVP that replaced human intervention with a trust-driven, self-sustaining marketplace.

Solution

We mapped task flows for all three user types before touching screens, grounding every design decision in what motivated each group to participate. I focused on the buyer's booking experience and the organization profile pages — designing both to do double duty: convert new users while giving returning ones a reason to stay.

My Contribution

This was a team project across a bootcamp cohort. My focus areas were the buyer's service booking flow and the profile pages for organizations and causes — both public and private views.

What I owned end-to-end: understanding buyer motivation, designing the booking experience, and working through the questions the org profile raised — what should be public vs. private, whether to include a dashboard, and how much volunteer information a buyer should see versus a community administrator.

TL;DR

Three screens, three user needs: a buyer landing page designed to convert through cause-led storytelling, a volunteer search built around trust signals, and an organization dashboard that made impact measurable. Each screen had to work independently and as part of the same system.

Research

Charitize was a new concept with no direct competitors. That meant we couldn't benchmark against an existing category — we had to look sideways. We studied how successful marketplaces like Kickstarter built trust during onboarding and how they incentivized repeat engagement. The question wasn't "what does a nonprofit site look like" — it was "what makes a marketplace sticky enough to work at three sides simultaneously."

User Interviews

We also interviewed 14 users: 7 active donors and 7 volunteers, all engaged in community activity within the past six months. The goal was to understand what motivated participation and what friction points made people disengage.

Key decisions the research drove:

  • Onboarding needed to be simple — no more than four steps, or drop-off would kill the funnel at the start.

  • Trust signals for volunteers mattered more than we initially assumed. Buyers needed credibility markers before spending money on a stranger's service.

  • Impact visibility was a retention mechanism, not just a nice-to-have. Users wanted to see the difference their transaction made.

  • Choice overload was a real risk — the three-sided model meant many options. The design had to guide, not overwhelm.

Design: From Task Flows to a Testable Prototype

Before touching screens, we mapped task flows for each user type — starting with their end goal and working backward through every key decision point. For the buyer, that meant understanding what they were actually buying: not just a service, but the feeling of having contributed to something meaningful. That framing shaped every design decision downstream.

The booking flow (my primary focus)

The buyer's job was simple in theory — find a service, pay for it, know their money went somewhere real. In practice, it required careful orchestration: surfacing volunteer credibility at the right moment, making the charity connection feel personal rather than transactional, and confirming impact at the end without it feeling like a receipt.

I sketched multiple directions during a team design studio session, stress-tested them against the research findings, and moved the strongest concepts into lo-fi wireframes.

The organization profile pages

The org pages raised harder questions than the booking flow. A nonprofit profile serves two very different audiences: the public buyer deciding whether to support a cause, and the organization's internal administrator tracking activity. I designed both views separately — the public view focused on credibility and emotional resonance, the private view on operational metrics and community management.

The central tension: how much information about volunteers should be accessible to buyers, and how much should only the org admin see? I worked through this in close collaboration with teammates covering the volunteer flow, since our decisions were interdependent.

Testing: Validating Under Real Constraints

We translated lo-fi wireframes into a clickable hi-fi prototype under a tight timeline, running usability tests iteratively rather than waiting until the end. By the final testing round, we put the prototype in front of 15 users — five per user type.

The buyer testing surfaced the most actionable findings. Volunteer credibility needed to surface earlier in the browsing experience. The charity selection step felt disconnected from the service transaction. And the booking confirmation didn't do enough to close the emotional loop — users completed the flow but weren't sure their donation had landed.

These weren't small UX fixes. They reshaped how we thought about the buyer's core journey.

Buyer Landing Page

Buyer Landing Page

Community Onboarding Page
Community profile page

Outcome

The final usability round tested 5 buyers on a clickable prototype. The results validated the core design decisions

The one miss — 4/5 on volunteer booking — pointed to exactly what we'd flagged during earlier testing: volunteer credibility signals needed to surface earlier in the flow.

We handed the founders a fully annotated prototype across all three user types. Charitize didn't launch — funding didn't come through — but the design foundation was production-ready.

Closing Reflection

Working on a product with three stakeholders made one thing clear: design decisions rarely live in isolation. The buyer's trust in a volunteer is shaped by what the org decided to make public. The org's private dashboard is shaped by what metrics the volunteer generates. The work wasn't three separate flows — it was one system, expressed three times.