A two-sided marketplace, matched by intent.
A client asked me to design the matchmaking and collaboration layer for a new platform connecting freelance graphic designers with small-business clients. I shaped it with the CUPS-PDM framework, from personas to high-fidelity prototype.
A new platform, two sides to serve.
A client was building a digital platform connecting freelance graphic designers with small businesses looking for design help.
The v0 platform handled search, communication, and payment. What it didn’t do well was the part where work actually starts: matchmaking based on project need, and project management once a match is made. My brief was to design the feature that would close that gap, and to do it in a way that scaled as both sides of the marketplace grew.
The CUPS-PDM framework.
When I work on a 0→1 feature, I use the CUPS-PDM framework: Clarify · User · Problem · Solution · Prioritise · Design · Measurement & Risks. It gives a 0→1 product a structure without forcing it into a process it doesn’t need.
Clarify
Connect the feature to the business mission. Two users: clients & freelancers.
User & Problem
Personas from real data. Pain list with priorities.
Solution & Prioritise
Map solutions to pains. Score effort vs impact. Pick two.
Design & Measure
Journeys → wireframes → hi-fi. Define metrics + risks up front.
Two personas, two different pains.
From the client’s research data I developed two personas. They share a platform but have almost nothing else in common.
Two features, chosen with the client.
I built a problem matrix, one row per pain point, prioritised by user impact. Then a solution matrix: potential features mapped to those pains, with a story-point estimate for each. The client and I agreed on the two highest-impact features for v1:
- Advanced Matchmaking. A brief-driven matching surface that scores candidates against project need. Visible to both sides, transparent in its reasoning.
- PM / Collab Workspace. Shared project space with milestones, file exchange, and a structured way to give and receive feedback.
Both features showed up at the same touchpoint in the user journey (the moment a client and a freelancer commit to working together), which made them easier to design as a unit.
Match by intent, not by tag.
Most marketplace matching uses tags. The user picks “branding,” the platform shows everyone with that tag. The result is noisy and undifferentiated. I designed the brief intake to capture intent instead (the industry, the project shape, the budget range, the timeline), and the match list to surface a fit score with a transparent explanation.
The fit score on every match is the visible promise of the system. A client can see why someone is at 96% and not 82%, and a freelancer can see what about the project surfaced them. The transparency cuts both ways and that’s where it earns trust.
From journey to hi-fi.
The deliverables to the client included:
- User personas for both sides, sourced from the client’s research data.
- User journey maps with the two new features highlighted at their touchpoints.
- Wireframes for the brief intake, the matchmaking view, and the PM workspace.
- High-fidelity prototypes for the critical screens, in light and dark themes.
- An integration and scalability plan, with measurement strategy and risk-mitigation notes.
Measured by match quality, not just match volume.
For a 0→1 platform, the right outcome metric is how often a match leads to a completed project, not how many matches happen. I outlined the metrics the client could track to evaluate impact:
- Match acceptance rate. Percentage of recommended matches that result in a hired freelancer.
- Project setup time. Time from match to a workspace with milestones agreed.
- Communication health. Frequency and quality of interaction; time-to-resolution on issues.
- Completion rate. Percentage of started projects that reach final delivery and payment.
Alongside these I documented the risks (new-feature adoption, scoring transparency, performance at scale) and the mitigations: comprehensive onboarding, an explicit explainer surface on the fit score, and performance budgets baked into the engineering brief.
Two-sided design means two sets of defaults.
The hardest part of two-sided product design is resisting the temptation to flatten the two users into a single average. Clients and freelancers want different things from the same platform; the platform earns its keep by giving each side a different default while sharing the underlying machinery.
The CUPS-PDM frame held up well for this kind of work. Forcing a clear pain → solution → prioritise step before any sketching kept the design honest about what it was actually solving. I’m using the same frame on the next freelance engagement.