Make the quest the canonical object
Reward, discipline, client, reputation, deadline, status, and required skills travel together from discovery into application and active work.
BRANDPRODUCT· Jul 2023
Lancer
A quest-based freelance marketplace built around skill, proof, and progression
- Timeline
- Jul 2023
- Role
- Product + Brand Designer (Contract)
- marketplace roles
- 2
- skill tracks
- 3
Process & contextStrategy, decisions, outcomes, chronology, and sources
Process & contextStrategy, decisions, outcomes, chronology, and sources
Context
Conventional freelance marketplaces separate discovery, application status, reputation, and proof of work across dense utility screens, making it difficult for people to understand where they stand.
Product decision
Use the quest as the canonical object. Reward, discipline, status, deadline, client reputation, and required skills stay visible on the card, while profiles carry badges, prior quests, portfolio evidence, balance, and activity.
Outcome
The MVP covered both sides of the marketplace: responsive discovery, application state, active-work execution, reputation, onboarding, and the complete client path from posting a quest through preview, publishing, funding, and sharing.
- 2
- marketplace roles
- 3
- skill tracks
- MVP
- end-to-end scope
Lancer and client paths share one system.
Engineering, design, and marketing shape discovery.
Onboarding, quests, profiles, activity, and proof of work.
ScopeProduct Strategy, UX/UI, Marketplace System, Identity, Launch Campaign
Key decisions
Design the card as a state machine
Open, hover, applied, denied, and accepted states use one architecture so people can scan both opportunity and progress without learning a second interface.
Continue after acceptance
Milestones, partial earnings, client context, conversation, attachments, and section submissions stay inside the accepted quest instead of falling back to email and chat tools.
Let one account hold both sides
Lancer and client roles share identity, balance, activity, badges, and portfolio evidence while preserving the different actions each side needs.
Product chronology
From Bounty MVP to a complete Quest marketplace
The added boards reveal the sequence behind the polished interface: map the whole service, define lifecycle states, design the work after acceptance, then evolve the model into a more expressive Quest system for both sides of the market.
Jun 6, 202301 · System map Connect the whole Bounty MVP
Map responsive discovery, filters, notifications, saved work, applications, active bounties, and mobile states before polishing individual screens.Jun 202302 · Lifecycle Treat a bounty as a state machine
Define open, hover, applied, denied, and accepted states, then connect acceptance to milestones, payout, chat, attachments, and submissions.Jul 202303 · Refinement Evolve Bounty into Quest
Consolidate discipline, reward, reputation, expiry, skills, and status into a more expressive marketplace object.Jul 202304 · Reputation Keep identity and proof close to discovery
Connect balances, activity, badges, portfolio work, prior quests, links, and resumes to the same account system.Jul 202305 · Client flow Close the supply-side loop
Let clients post a quest, attach media and links, inspect a public preview, publish into an honest unfunded state, then fund and share it.Launch06 · Campaign Turn the product object into the campaign
Scale the quest-card language directly into launch and street placements instead of inventing a disconnected visual idea.
01
The quest is the marketplace object
Every card answers the questions a freelancer needs before opening it: reward, discipline, client, reputation, status, deadline, and required skills. The visual variation communicates type without changing the underlying model.
02
Map the whole service before polishing it
The June system map connected responsive discovery, notification subscriptions, saved work, applications, active bounties, and mobile. A tighter journey board made the handoffs between those states easier to inspect.
03
Design the state model before polishing the board
The early system work defined how a quest moved from open to hover, applied, denied, and accepted, then connected those states to browsing, notifications, application attachments, active work, submissions, and client feedback.
04
A visual language built from the work itself
Discipline colors and symbols helped people scan the marketplace without fragmenting it into separate products. The quest identity carried from the mark into cards, filters, and campaign language.
05
Identity and state remain close to discovery
The account keeps balance and activity one step from the board. The full profile turns completed work and reputation into evidence for the next quest.
06
One account, three kinds of proof
Activity shows live application state, badges turn completed work into earned recognition, and the portfolio keeps evidence close to the next application. The Lancer/client switch stays available throughout.
07
Onboarding establishes the marketplace model
The first-run sequence sets the user's side of the market, selects a skill mix, and creates the proof-bearing profile before dropping them into discovery.
08
The client path closes the marketplace loop
Clients choose a discipline and reward, write the brief, attach links and imagery, inspect the public preview, then publish into an honest unfunded state with clear funding and sharing actions.
09