A mobile-first platform targeting 54-minute average commute delays and micro-delivery inefficiencies across high-density UK hubs.
Project Metadata
Role
Solo designer and researcher
Platform
iOS and Android (concept)
Timeline
8 Weeks
Scope
Survey, interviews, journey mapping, paper prototyping, valence testing
survey responses
user interviews
usability test sessions
With people back in offices, UK commuters are on long, multi-leg journeys again. Even before the pandemic, the average round trip was about 55 minutes (TUC, Labour Force Survey data). In my interviews, cost and reliability came up again and again. The Tube is fast but expensive, buses are cheap but slow, and taxis are out of budget for daily use.
Remote and hybrid workers have a related problem. Same-day couriers are hard to find, rarely give an exact delivery time, and can take an hour just to collect. Quick Drop tests one idea: a single rider network that carries people on short trips and delivers parcels under 5kg the same day.
The Core Urban Mobility Tension
Balancing speed against infrastructural limitations.
Tube & Overground
Expensive & Rigid
City Buses
Slow & Unreliable
Private Cars / Taxis
Prohibitive Surge Pricing
I surveyed 30+ people: 94% used public transport, 74% travelled 1–10 miles a day, and 67% had problems with how they get around now. I then interviewed 7 of them over Teams and Zoom. I grouped the notes into an affinity map, and four themes came out: cost, reliability, parcel speed and tracking.
User Archetypes
Jerome (The Student)
Spends 75–80 minutes each way on the Tube, Overground and buses to get to university. When a bus terminates early, he misses lectures, and
attendance affects his student visa.
Budget-conscious
Direct low-cost motorcycle transit
Rebecca (The Hybrid Professional)
An IT consultant who works from home with a toddler. She needs to get a small package across town within a couple of hours; in her scenario, it's
lunch for her husband at work. Couriers can't promise a time, and driving means leaving work.
Time-poor
Guaranteed sub-2hr parcel delivery
Complete Customer Journey Mapping (Jerome vs. Rebecca)
Persona
Phase
Current Actions
Pain Points & Friction
UX Opportunities
Jerome (Student)
Before Journey
Checks Google Maps & Citymapper
Has to double check across two apps to confirm live status
Real-time unified service update feed
Jerome (Student)
During Journey
Tube + Overground + Bus transit (80 mins)
Bus driver announces unexpected service termination at unknown stop
Direct motorcycle-taxi rerouting option
Jerome (Student)
After Journey
Misses lecture, emails department
Attendance shortage seriously threatens visa compliance status
Automated attendance justification logging
Rebecca (Pro)
Planning
Searches same-day courier services online
Services mix same-day and 3-day results without exact timing
Guaranteed sub-2hr pickup time calculation
Rebecca (Pro)
Checking
Filters results, manually calculates VAT
Tracking is vague, pickup takes over 1 hour to arrive
Live GPS driver tracking map overlay
Rebecca (Pro)
Conclusion
Drives in busy traffic with toddler
Has to mark ‘Out of Office’ and work late to compensate hours
Home pickup with OTP handoff confirmation
Point of View (POV) & 'How Might We' (HMW) Synthesis
POV Statement (Jerome)
Jerome needs a cheaper, faster direct ride to university because missed lectures put his attendance, and his visa, at risk.
HMW Question
How might we provide a direct point-to-point ride that bypasses road traffic and costs significantly less than private taxis?
POV Statement (Rebecca)
Rebecca needs a fast, tracked pickup and drop for small packages because she can't leave work to deliver them herself.
HMW Question
How might we offer transparent, sub-2-hour parcel delivery with live GPS verification and instant receipt confirmation?
Qualitative Synthesis & Affinity Clusters
Cluster 1: Transit Cost
"Private taxis cost an arm and a leg; tube prices are too high for daily student commutes."
Cluster 2: Reliability
"Endless road time and sudden bus terminations make public transit
completely unpredictable."
Cluster 3: Parcel Speed
"No courier offers same-day delivery that is both speedy and secure under
2 hours."
Cluster 4: Live Tracking
"Tracking packages is a major headache; status updates are vague and unhelpful."
Research told me what to build. Before a single high-fidelity screen, every idea went through paper, a real user and a defined flow.
STEP 01
Rapid Ideation
I turned each POV into How Might We questions, then ran Crazy 8s: eight sketches in eight minutes per question. Speed over polish, with judgement switched off.
STEP 02
Paper Before Pixels
I tested a clickable paper prototype (Marvel POP) with one participant. Two changes came straight out of it: a single sign-up option, and no “Search for ride” button.
STEP 03
Four Core Journeys
Before adding any visual detail, a wireflow mapped the four journeys the app had to support: sign-up and login, booking a ride, sending a parcel, and the user menu.
STEP 04
Identity & Style Guide
A moodboard set the direction, and a style guide locked in colours, type and components. The logo’s Q doubles as a scooter tyre, with three red lines for speed and blue for trust.
A "Ride / Courier" toggle on the home map switches between the two flows.
Both use the same rider network.
DESIGN RATIONALE
Both personas wanted the same thing: a fast, short trip across town that avoids traffic. One rider can carry a person or a parcel, so a shared network keeps more riders nearby for both. Whether there's enough demand for this to work is an assumption I didn't test
Key decision 2: Sign up
with just a phone number
One field and a one-time code. No social logins, no password.
DESIGN RATIONALE
In the first paper-prototype test, the participant found the mix of sign-up options confusing. Cutting to one phone number also confirms the number the app needs for parcel handoffs. The same session led me to drop the "Search for ride" button, so the app now opens on the map at the user's location
Key decision 3:
Live tracking and a code at handoff
The sender and recipient see the rider's live position. The rider can't complete a
delivery until the recipient gives a 4-digit code.
DESIGN RATIONALE
Interviewees called courier tracking vague, and Rebecca's scenario turns on knowing the parcel arrived. In testing, 2 of 3 participants singled out the code: one said it "gives me a secure feeling". But 2 of 3 also couldn't tell when the rider would arrive. Tracking without an arrival time didn't answer the real question.
Valence testing with 3 participants
I tested the high-fidelity prototype with 3 participants. Valence testing captures how people feel about each part of an interface, moment by moment, in two steps.
Step 1
Explore
Each person used the prototype freely, thinking aloud and saying “green” for something that worked and “red” for a problem.
Step 2
Retrospect
We replayed the recording, and I asked about every red and green moment to understand the reason behind it.
What testing found: 31 moments logged
Finding
Seen by
What I’d change
No rider arrival time on the map
2 of 3
Show “Rider arrives in 4 min” on the map and trip card
“Jacket size” field unclear
2 of 3
Explain it: the rider brings a jacket in your size
“SOS” label unclear
1 of 3
Rename to “Emergency call”
Static map, ride type not tappable, small fare icon
1 of 3
Zoomable map, fully tappable ride card, 48px fare target
No way to message the rider
1 of 3
Add in-app chat
OTP handoff, fare breakdown, item types, rider details
Praised by 1–2 of 3
Keep
The OTP handoff was the strongest positive: one participant said it “gives me a secure feeling”. Tracking alone wasn’t enough, though. Without an arrival time it didn’t answer the question people actually had. After testing, I also listed gaps for v2: booking a ride and a parcel at the same time, scheduling ahead, and more than one drop-off per booking.
When things go wrong
Situation
How the app handles it
Parcel over 5kg
Weight reminder before booking (already in the design)
Verification code doesn’t arrive
Resend after 30 seconds, or change the number
Recipient not there, or wrong code 3 times
Rider calls the sender in-app; the parcel goes back to the sender
Rider cancels or doesn’t arrive
Automatically matched with a new rider, new arrival time shown, no charge
Payment declined
Booking is kept; ask for another card before a rider is assigned
No riders nearby
Show the expected wait and offer to try again later
Location turned off
Type the pickup address instead
This table sets out how each case is handled. Designing the screens for them is the next step.
I checked every colour pair against WCAG AA contrast and set touch targets to at least 48×48px for one-handed use on the move.
Type scale: Display 48px, H2 32px, Body 16px.
Color Palette (WCAG AA/AAA)
Trust Blue
8.7:1 AAA
Action Blue
5.2:1 AA
Alert Red
3.8:1 · large text only
Typography Scale
Poppins
Display 48px | H2 32px |
Body 16px
Ergonomics
All interactive elements maintain a minimum boundary height of 48x48px for thumb-zone operation during outdoor travel.
48px Touch Target Button
What I’d do differently
Test with more of the right people. Three sessions find the big problems, not proof. Next: 5 weekly commuters or parcel senders, with timed tasks.
Design the rider side. I only designed the customer app. Accepting jobs, entering the code and navigation are half the service.
Check the rules early. UK licensing and insurance for motorcycle taxis decide whether the ride side could launch at all.
Product Roadmap (v2 Strategy)
Ride + Parcel Together: Booking a ride and sending a parcel in one go, a gap found in testing.
Multi-Stop Drops: Supporting multi-destination parcel drop-offs
on a single courier booking.
Advance Scheduling: Allowing users to pre-schedule rides and
dispatches up to 24 hours in advance.
