Fostering trust and enhancing user retention
Case study | 7 min read
3 months
Contract
1 Design lead, 2 software engineers, CEO, PM
PoolUp was an early-stage startup aiming to create a community-based ride-sharing platform for college students. But despite strong user interest, we faced a critical issue: users were dropping off right before booking rides. As a result, PoolUp struggled to convert students into paying customers—and the community we envisioned never got off the ground.
I led the redesign of the rider and driver profiles to rebuild trust in our carpooling app. Users were abandoning bookings due to a lack of information about who they’d be riding with. I designed and tested a new profile and preference system that led to a 30% increase in completed bookings, all within the constraints of a scrappy early-stage team.
I took initiative to redesign the user profile system, turning it into a trust-building tool. This involved:
💪 Adding interest tags, bios, and preferences (e.g. music taste, chatty vs. quiet rides)
📱 Improving visibility of driver info during ride selection
🔎 Advocating for progressive onboarding nudges to increase profile completion
🤝 Conducting student interviews to deeply understand the social dynamics of shared rides
My Insight
The trust issues ran deep
I identified that this wasn’t just a usability issue—it was a trust issue. Students were hesitant to commit to long car rides with strangers, especially when the app itself felt outdated and impersonal. Profiles were an afterthought in the original flow, offering little context about who users were riding with.
Potential Impact
Improved platform trust and brand reputation
By making student profiles more human and informative, PoolUp became a product users felt safe using—and recommending.
Enhanced user tust and engagement
Giving students more control over who they ride with created a more comfortable, engaging experience—crucial for a community-based app.
Achievements
Drove strategic research buy-In
I persuaded stakeholders that skipping user research would be more costly in the long run. This helped shift the team from reactive bug-fixing to a more strategic, user-informed roadmap.
Designed for trust under constraints
With only 2 developers and a tight backend structure, I delivered a solution that improved usability and user confidence—without requiring major architectural changes.
Wanna dig deeper? Keep scrolling~
Status Quo
Facebook hosts the majority of rideshare community for college students
Before PoolUp existed, most students used informal Facebook rideshare groups to coordinate long-distance trips.
Real posts from student rideshare groups on Facebook — messy, inconsistent, and potential of issues
While these posts technically worked, they came with a lot of friction:
No easy way to vet drivers or passengers
Lots of ghosting or last-minute cancellations
Hard to know what kind of ride experience to expect
No built-in verification, payment flow, or matching system
These pain points were what inspired PoolUp’s core value prop: a safer, easier, more structured way to find rides with fellow students.
This also directly influenced how I thought about profiles as a trust-building tool. If students were already semi-comfortable finding strangers on Facebook, a thoughtfully designed app could offer more structure and more safety—without removing the social connection.
Digging Deeper
Users weren’t booking rides—even when matches existed.
We saw promising ride supply and demand, but few matches were converting. At PoolUp, we set out to help students book long-distance rides together through a rideshare platform tailored to college life. But early usage showed a problem: users were dropping off right before completing their bookings. I worked with the PM to dig into metrics and community posts. The top user concern? “I don’t know who I’m riding with."
A comic illustration I made to show how a student weighs their decision to book… and ultimately backs out due to uncertainty.
Uncovering unexpected feelings about trust & connection
The product’s outdated UI and patchy visual consistency gave off the wrong signals. Through informal interviews with college students, I started to uncover the bigger issue: lack of emotional and social trust.
Getting in a car with a stranger(s) for a 2-5 hour ride requires a lot of trust.
So I went to the source. I spoke with ~8 college students who regularly traveled 2–5 hours to visit home from school. They told me:
Comfort and safety mattered, especially around the driver’s behavior (road rage, loud calls, driving slowly despite urgency).
Awkwardness with strangers was real. Students enjoyed rides with friends—but when sharing with peers from Facebook groups or unknown students, mismatched expectations made things tense.
The current booking flow didn’t provide much confidence about who you’d be riding with. I advocated that we pause bug fixes and zoom out—to solve the root UX issue around trust.
Initially, I assumed the biggest blocker would be awkward silence. But students talked more about driver etiquette—not about being unsafe, but being uncomfortable.
“He talked loudly while I was trying to sleep.”
“She didn’t ask if the AC was okay.”
“He kept checking his phone in traffic.”
This reframed how I thought about trust: it wasn’t just about verifying identity—it was about feeling emotionally safe and respected. That realization shaped everything that followed.
Implications from these interview insights helped shaped design direction
Lessons From Other Apps
How do digital products build connection between strangers?
To better understand how digital products build connection between strangers, I looked beyond rideshare apps and studied profile experiences from platforms like Tinder and Bumble.
These apps aren’t about safety in the same way ridesharing is—but they are about helping people form trust and comfort quickly, often with very little context. That made them highly relevant for a platform like PoolUp, where users might be choosing someone to spend hours in a car with.
Screens of Bumble and Tinder: bio, interests, hobbies, etc, help build a fuller picture of strangers.
What I learned: common ground = enhanced trust
Photos and bios are trust anchors. Even a short bio helps make someone feel real.
Shared interests = fast rapport. Whether it’s music, memes, or majors, a little common ground goes a long way.
The UX should feel human, not transactional. It should feel like you’re meeting a person, not just booking a ride.
This shaped how I approached profiles—not just as a static screen, but as a space to signal personality, invite connection, and reduce awkwardness. It also validated that small, lightweight details (like Spotify playlists or hobby tags) could have a big emotional impact.
The Solution
Creating user profiles that show personality and build trust
To reduce booking drop-off, I redesigned the profile experience to make co-riders feel more familiar, transparent, and human, which helped users understand expectations form all parties and reduce any doubt and anxiety going on the ride to feel more confident in selecting a driver or passenger.
I added:
Rider and driver preferences: e.g. music volume, talkative vs. quiet, specific rules, etc
Interest tags, curated from pop culture and trending Twitter topics (later narrowed with PM to 25 topics)
Bios, and clearer display of the student verification badge
A more prominent edit profile flow, surfaced at the end of booking or accessible anytime
A better profile experience to make passengers feel more familiar, transparent, and human
Users can only see basic info that's lacking any content that helps build personality for the driver
Users can now see the driver's bio, interests, preferences that helps build a more complete picture about this student both as a person and a driver
Easy access to passenger reviews all in one page
"notes" instead of "reviews" to make it sound less transactional but more appreciative - helps foster a sense of community
Added a Spotify section so passengers can expect what type of music they can listen to during the ride
Using better layout and colors for driver-related information
Visual design feels sterile and not friendly
Blue circle around profile feel like an action can be take when there isn't
Brand color (blue) call out doesn't place emphasis on the most important information, placement and bright color disrupts the flow of the screen
Hiding reviews in a separate screen is unnecessary and can be hard to find
Black card places emphasis on crucial driver details
White on black is easier on the eyes
Top card in black and rest of the info in white background helps with progression of reading without disruption
Better use of brand color for student driver verification
Key Decisions
How can the users edit and input their interests and preferences?
In early explorations, I wanted to let users freely input their own tags or interests—things like “Taylor Swift fan,” “road trip pro,” or “vegan.” I believed this would make profiles feel more personal and human.
But in conversations with the PM and lead engineer, we flagged two major concerns:
Moderation risk: Open-ended input could lead to trolling or inappropriate content.
Implementation scope: Dynamic inputs would require new backend logic and content filtering—too heavy for our timeline.
Discussions between me, PM, and devs to strike a balance between design, feasibility, and business goals.
I explored 3 approaches:
Fixed list of tags from a curated list (chosen method)
Typing to input for maximum user customization
Type-ahead suggestions from a curated list
⭐️ Fixed list of tags
❌ Less expressive
✅ Simple to build, consistent display
✅ Simple content moderation
🗑️ Typing to input
✅ Max customization
🔶 Challenging content moderation
❌ Complex back end efforts
🗑️ Type-ahead suggestions
✅ Personal feel, light guardrails
🔶 Simple content moderation
❌ Still required more complex backend validation
We aligned on the fixed list of tags: a set of 25 curated tags based on user research (popular topics sourced from ChatGPT). It struck the right balance between personalization, safety, and shipping fast—and users still found it helpful in testing. There were still plans to expand this feature so that the options are broader and more customized in the future.
Deciding what users would find most helpful in driver/passenger preferences section
To shape the in-ride preference options in the new profile, I wanted to avoid guessing what users cared about. I built on insights from a previous user research study, which surfaced a long list of potential preferences—everything from music taste to car temperature.
To narrow this down, I ran a card sorting activity with university students (our core users):
Participants ranked each preference from most important to least—or discarded them if they didn’t matter.
They then grouped similar preferences and gave each group a name.
One participant sorts ride preferences by importance and categories. “Talkative or quiet” consistently ranked near the top across sessions.
This helped me spot patterns, like:
Some students cared a lot about conversation style and music, while car temperature and snacking rules were often deprioritized.
Users tended to mentally bucket preferences into themes like “vibe,” “comfort,” and “etiquette.”
One unexpected finding: none of the students I interviewed cared about showing COVID vaccination status, even though cases were still active on campus (2022–2023). I had initially considered a vaccine badge, but deprioritized it based on this insight—especially since verifying status would’ve required significant backend effort.
These insights helped me select a focused, relevant set of preference tags for the profile redesign.
Trade-offs & Considerations
Let profiles be optional but encouraged
The PM wanted to force users to complete their profiles before booking. I pushed back.
My thinking:
Forcing a big task at a high-intent moment (like checkout) could cause more churn
Forcing users to share personal details about themselves can discourage them
Instead, I wanted to progressively encourage users to fill out their profiles as they used the app
In the end, we compromised: users were gently prompted at the end of the booking flow to complete their profiles, and could choose to edit anytime. I would have liked to weave it earlier into onboarding, but the broader flow redesign was out of scope.
What didn't make the cut 🗑️
I explored several deeper trust-building features, but many were scoped out due to time or backend limitations:
🧭 GPS Location Sharing for emergency support
🔄 Pre-Ride Questionnaires to help match people with shared values
🗣️ Conversation Starters during rides to make it feel less awkward
Early ideations of location sharing feature
Results
Design changes led to an overall improved user attitude in browsing rides
Shortly after launch, the PM told me that ride booking drop-offs had decreased by approximately 30%, according to their internal analytics tool. While I didn’t have direct access to validate this data myself, it was encouraging to hear that the redesign contributed to measurable impact.
Informal A/B testing supported our hypothesis 🧪
Before handoff, I conducted an informal test where I showed students the old vs. redesigned profile screens within the context of booking the ride. Every participant said they’d feel more comfortable booking rides with the new profiles—especially if student verification was clearly visible. This gave us qualitative confidence in the direction.
My metrics wish list 📈
Because I left PoolUp before the full rollout of this redesign, I didn’t have access to long-term metrics. But if I had stayed on the team with the right tools in place, here’s how I would have tracked the impact of this work across trust, engagement, and retention:
In Retrospect
What I Learned: Trust, Trade-offs, and Thinking in Systems 🌱
This wasn’t just a chance to ship a feature—it was a turning point in how I think and work as a designer.
Looking back, I can clearly see how this project helped me grow across four pillars: Product Thinking, Systems Thinking, Emotional Design, and Leadership.
Here’s how my mindset and approach evolved through the process:
Now in 2025, what would I have done differently?
Looking back with more experience and knowledge under my belt, here are a few things I’d approach differently if I were to redesign PoolUp’s profile system today:
Validate earlier and more rigorously
I’d set up structured usability tests and align with the PM on success metrics sooner—especially for trust-critical flows.Plan for safe customization from the start
I now know how to design input systems with built-in safeguards like flagging, filters, or constraints to allow flexibility without risking abuse.Prototype the full journey
Instead of isolating profile screens, I’d include the full ride-booking flow to better test how trust signals affect decisions in context. I had the system thinking to consider the whole flow, but presenting them visually to the team would have been more impactful.Collaborate more deeply with eng/PM
I’d co-create earlier with engineers and PMs to align on tradeoffs and edge cases—making decisions more collaborative and efficient.Add post-launch feedback loops
I’d push for lightweight tools (like in-app surveys or prompts) to gather real user input and guide future iterations. I would also encourage the team (if resources allow) to invest in sourcing users to properly beta test the product.
If I stayed longer, what would my next step be?
I would definitely test my designs more thoroughly, especially after implementation, to understand what else could be improved on. I only worked on one small feature to enhance trust but I believe there are still a lot of opportunities in the entire user flow of rides booking that can be improved to enhance revenue over time. Features like an in-ride screen to track current status, safety feature (GPS location sharing), or even interactive features to help students get to know each other, can be huge assets in helping PoolUp build a community of ride-sharers outside of Facebook groups.
Continue on to the next project about a fire prevention product for home cooks!