Ash_
About Inquire Contact
← back
UX researchproduct designiOSpitch deckconcept

Pickup is where secondhand deals fall apart

A UX case study on route-matched pickup for bulky secondhand deals in Metro Vancouver. Team project with Sean.

UX research & product design CUXD 214 · Emily Carr University of Art + Design 2026
01: problem

People across Metro Vancouver buy and sell bulky things on Facebook Marketplace constantly. When the item is a couch, a desk, or a fridge, moving it from their place to yours is the part nobody has a plan for.

How might we make handing off a bulky-item pickup feel as safe and affordable as asking a friend?
No truck A couch does not fit in a Civic. People rent from Home Depot, book Modo, or wait on a friend.
No time Coordinating pickup eats evenings and weekends. Then the other person stops replying.
Too much work Stairs, lifting, straps, a rental booking. Plenty of people just skip the deal.
02: research

Four methods: survey, interviews, community research, and competitive scan. Six survey responses, four qualified after screening for people who had bought or sold secondhand in the past year.

methodwhat it was
SurveyTypeform, distributed through r/vancouver, campus channels, and local buy-and-sell groups. Questions anchored to the last real transaction.
InterviewsThree walk-me-through conversations about the last bulky buy or sale, the worst experience, and the moment they backed out of a deal.
CommunityAn r/vancouver thread asking how to move Marketplace furniture without a car. Five unrelated workarounds for one job.
CompetitiveLugg, Dolly, and Roadie (none in Canada). TaskRabbit. Local van-booking apps. Sharetown and Kaiyo as business-model references.
4 of 4 ranked pickup and delivery the worst part of buying or selling secondhand
4 of 4 chose a delivery and pickup service as the most appealing feature
4 of 4 said they would not hire help to move something heavy
1 of 4 has ever paid for pickup help, and paid under twenty dollars

Strong stated demand. Almost no revealed demand. That disagreement is the finding the whole project turns on.

"I don't know a reputable company that offers affordable help."
"I would ask people I know first."
"Cost."

Three different objections: trust, a free default that already works, and price. A paid service has to beat all three at once.

03: the pivot

The project started as Payments Pending, built around escrow. Research moved us upstream, to pickup, trust, and who is already on the road.

0 of 4 chose escrow. All four picked pickup and delivery. On a question where selecting it cost them nothing, not one person did.
Logistics first For bulky items, pickup was the top friction by a distance. Escrow became interesting later, not the thing anybody was stuck on.
Money gets simpler Three of four use e-transfer day to day. Over $150, three of four switch to cash. People get more analog as the stakes rise.
Ride the trip Someone is already headed that way. Matching a haul to a trip that is happening anyway keeps the fee low enough to matter.

So Payments Pending became First Pickup, and the money moved out of the product. Item payment stays between buyer and seller on whatever channel they already use. We charge for the haul and nothing else.

04: personas

Three roles. One handoff. One persona per user flow. Every trait traces to a survey respondent, an interview, or the community research.

Persona: Lai, 27, buyer in East Vancouver
Lai · buying
Persona: Mei, 31, seller in Mount Pleasant
Mei · selling
Persona: Jason, 34, transporter in Surrey
Jason · transporter
05: design process

Everything upstream of the wireframes lived on one FigJam board: the service swimlane, the SWOT, the r/vancouver thread, and the first pass at personas.

FigJam working board with flows, SWOT, community research, and persona evolution
working board: flows, SWOT, community research, and the first persona pass
stagewhat happened
FlowsMapped Lai, Mei, and Jason in FigJam before any screens existed, first as a swimlane of activity, then as three role flows.
Low fidelityPaper and rough frames testing one question: can the request be three steps? Two generations of wires.
Mid fidelityLayout, hierarchy, and the request sequence. The flat-rate size picker replaced a quote form here.
Design systemFive core colours, an iOS-native type ramp, hairline cards, 44pt minimum targets, documented as a brand guide.
PrototypeSean built the full high fidelity flow: three roles, empty states, error states, confirmation dialogs, and Dynamic Island states.
06: design solution

Onboarding

onboarding flow
Onboarding: what First Pickup is
what it is
Onboarding: how it works
how it works

Requesting a haul

Request flow: what are you moving?
what
Request flow: pickup and dropoff locations
where
Matched transporters list
matches
Confirm booking with transporter
confirm

Size is a three-way choice with the price on the button: $15 small, $35 medium, $65 large. The Confirm screen states plainly that the fee covers the haul only and the item is paid for in person.

Driving a route

transporter flow
Transporter job offer
job offer
Job complete confirmation
done

Jason sets a home zone and his regular corridors first, then receives jobs that fit them. The offer states earnings before he accepts: $28 of the $35. Route matching is what keeps the fee low enough to compete with a friend who works for free.

Trust without escrow

Photo check-in at pickup
photo check-in
Live Activity tracking on lock screen
live activity

Photo check-in at both ends of the job, ratings, and in-app chat. It came out of the safety finding directly: people already bring a friend and inspect before paying, so the design gives them evidence rather than reassurance.

$15 / $35 / $65 flat haul by size. Small is a box or a scooter load, medium a chair or a bike, large a couch or a dresser.
$28 of a $35 medium haul goes to the transporter, roughly 80%, earned on a trip they were making anyway.
$7 platform share, covering processing, support, and the match. Item money never enters the app.
interactive prototype

Click through the full flow: request a haul, get matched, confirm, and track the delivery.

request flow

Five screens, one haul. From size to match to booked.

Step 1: What are you moving? Step 2: Pickup and dropoff Step 3: Matched transporters Step 4: Confirm booking Step 5: Booked
07: wireframes

Three generations of the same request. Each generation changed one structural idea. None of them were restyles, and each change traces back to something the research told us.

Wireframe: customer new request
new request
Wireframe: map request
map request
Wireframe: matches
matches
Wireframe: transporter requests
transporter requests
Wireframe: transporter job
transporter job
Wireframe: service area
service area
08: testing

Structured walkthroughs with the team and with peers, aimed at finding broken paths, missing screens, and confusing first-run moments. Then five structured sessions with people outside the team.

what brokewhat changed
OnboardingRole choice was fuzzy. We split customer and transporter onboarding and made the home mode follow that choice.
Empty statesA first-run Getting home looked unfinished. We added empty homes for no haul yet, no active haul, and no nearby match.
Error statesFailed payment and the cancel and skip confirmations were missing. Walkthroughs stalled there. We added all four.
Missing pagesHelp, history, and rating had no home. They do now.
09: outcomes

Nothing has shipped, so there is no market outcome to report and this document does not invent one. We have a business case sized to test the open question. Funding the operation comes after that.

$9M Metro Vancouver serviceable market for bulky hauls, built bottom-up from roughly $130M of peer-to-peer resale
$270K first-year gross transaction value target across two or three corridors
$250K build estimate, three to six months, for a two-sided app with payments and an admin tool
10: lessons

We named the wrong problem, and the name recorded it

Payments Pending was an answer, not a question. Escrow appeared in our first how-might-we before we had spoken to a single person, and four people later not one of them wanted it.

Stated demand and paid demand are different quantities

Everyone in our survey said pickup was the worst part. Everyone said they would like a service that fixed it. Nobody would pay for it, and one person had ever paid anything at all.

We researched one side of a two-sided market

Every survey question addressed customers. Jason exists because the business model needs him to, and his persona card says so in red. In a marketplace, supply is not a supporting character.

Order the methods properly

We wrote a survey before running interviews, which meant the questions were built on guesses about what mattered. Interviews first would have told us escrow was dead before we spent a question on it.

my contribution
What I owned Customer research: the survey instrument, the community and competitive analysis, and the market sizing. Low and mid fidelity design. The design system, the brand, and the investor deck.
Shared with Sean Sean and I worked out the service workflow and the three user flows together. Sean built the high fidelity prototype and ran two of the three user interviews.
pitch deck

View full case study PDF →

Pitch deck: title slide
Pitch deck: market
Pitch deck: problem
Pitch deck: insight
Pitch deck: product
Pitch deck: request flow
Pitch deck: transporter
Pitch deck: competition
Pitch deck: business model
Inquire