overview
timeline
3 months
role
Lead Designer
User Research
tools
Figma,
FigJam
team
2 Engineers
1 Product
1 Designer
problem
Discovery was fragmented across social media and personal recommendations, and booking often meant messaging back and forth without clear availability or a dependable way to assess quality for both sides. Students also had busy schedules and low purchasing power to act.
“I would rather drive 3 hours home than to try to get a haircut here”
“I paid $40 more for a haircut in Austin compared to home at a barber”
“I’ve been ghosted 6 times trying to get my nails done”
research
We conducted 8 user interviews, 3 competitive analyses, 2 journey maps, and 1 field study to get a better understanding of what current issues there were that were not visible at the surface.
Goals:
Journey mapping
Competitive analysis
Interviews
Research revealed both students’ schedules were packed and finding a time that worked was difficult; pricing was something that needed transparency; both sides need to trust each other to not cancel and to do a good job at the service; and they wished for a centralized place for all steps from discovery to booking
research
From research we got a better understanding of the problem space, user needs and failures within the system
Trust booking services from peers they don’t know
Better discovery for services
Convenience for booking services
Providers want better outreach and tracking of service
prototyping
From the insights found from research I developed several mid-fi frames and conducted user testing to fully understand what users needed and valued.
Before:
After:
Before:
After:
Before:
After:
design decisions
During ideation and prototyping there were a few design decisions I had to fight for or take a deeper dive into based on research insights
Optimizing for customer's convenience could come at the expense of the provider's privacy. I redesigned the listing location section so it had a radius instead of an address and once confirmed with the provider it will have the exact location.
Trust was the most prevalent insight in research. Trust wasn’t a single feature, but a design challenge that lived across many aspects of the app to get students to trust other students they don't know with services.
User concern
“Is this actually another student?”
Trust mechanism
University email verification
Design rationale
Establishes university affiliation
User concern
“Can this person do the job?”
Trust mechanism
Provider portfolios
Design rationale
Makes experience and work visible
User concern
“Have others had good experiences?”
Trust mechanism
Reviews
Design rationale
Provides social proof
User concern
“Can I clarify details before committing?”
Trust mechanism
In-app messaging
Design rationale
Reduces uncertainty through communication
User concern
“Does anyone I know recognize this person?”
Trust mechanism
Friend connections
Design rationale
Existing social relationships build familiarity
During development the product manager, and engineers originally wanted the user flow for signing up to be a provider to be when you already were logged in and you would have to complete another flow.
However, I challenged this advocating for the there to be no separate onboarding for providers. I talked to providers and similar apps like Depop and Facebook Marketplace where users are both customers & sellers. With this information I worked with my product managers & engineers to create a flow that allowed anybody to have a selling profile to initially become a seller where all you had to do was create a listing.
solutions
Home to search
Booking a listing
Messaging
Stats
Log in with .edu
reflection
Learnings:
Next Steps:
This is just a snapshot of the full story and my design thinking
Reach out to nicocampanell@gmail.com for the full story
