Make the quest the canonical object
Reward, deadline, reputation, status, and skills stay with the quest from discovery through active work.
Lancer
Freelance quests that connect skills, work, and reputation
01
The quest is the marketplace object
Each quest shows reward, discipline, client reputation, status, deadline, and required skills before opening.
02
Map the whole service before polishing it
The system map connects discovery, saved work, notifications, applications, and active quests across desktop and mobile.
03
Design the state model before polishing the board
Open, applied, denied, and accepted states connect browsing to submissions and client feedback.
04
A visual language built from the work itself
Discipline colors and symbols make quests scannable across cards, filters, and campaigns.
05
Identity and state remain close to discovery
Balance and activity stay close to the board; profiles connect reputation to completed work.
06
One account, three kinds of proof
Application status, badges, and portfolio evidence stay connected, with Lancer/client switching always available.
07
Onboarding establishes the marketplace model
Onboarding establishes role, skills, and a profile before discovery.
08
The client path closes the marketplace loop
Clients set a reward, write a brief, attach evidence, and preview the quest. Publishing makes its unfunded status and next funding action explicit.
09
The marketplace became a campaign
Project evidence & details
Project evidence & details
Problem
Freelancers needed to find relevant work, track applications, and demonstrate credibility without piecing together separate screens.
Approach
Put reward, deadline, status, and required skills on each quest. Use completed quests and portfolio evidence to make reputation inspectable.
Outcome
Designed the MVP across discovery, applications, active work, and profiles, plus the client flow from posting a quest through funding and sharing.
- Scope · marketplace roles
- 2Lancer and client paths share one system.
- Evidence · end-to-end design
- MVPOnboarding, 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
One card system makes open, applied, denied, and accepted states easy to compare.
Continue after acceptance
Milestones, earnings, conversation, attachments, and submissions stay within the accepted quest.
Let one account hold both sides
Both roles share profiles and activity while retaining the 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.