Case study / 04

Hoop Carpool

Hoop had a product defined on paper and a first version of the app. As the only designer, I made it tangible while it was still being decided.

Summary

Hoop Carpool was created with the mission of improving urban air quality and enhancing everyday life in the city. This innovative platform enables users to share their daily commutes, allowing others to join their rides. By increasing vehicle occupancy, Hoop Carpool plays a key role in reducing traffic congestion and improving overall traffic flow. My task here was to design an app to achieve this purpose.

Role: Main UX Designer
Timeline: 8 months
Company: Hoop Carpool
Platform: Android & iOS

My Role

As the sole UX Designer at Hoop Carpool, I designed the product while it was still being defined. There was a first version of the app to build on, and the work ran end to end: research and strategy, the design itself, and the iteration on both.

I ran the user surveys, filled a UX Blueprint with the team, and moderated the usability testing. What came out of those redefined the user flows, the wireframes and the UI components.

The First Step

The product was already defined by the Product Owner, my duty was to make it tangible. Still, I wanted to understand as much as I could, and first, I wanted everyone in the team (9 people) to be aligned. We needed some more clarity, and to identify the aspirations, goals and approaches we would orbit around.

That's why I gathered the whole team so together we could fill a UX Blueprint.

Why?

We needed to align multidisciplinary teams.
Although the idea was defined, we were still in the product discovery phase.
The service not only included technological, but also human interaction.

UX Blueprint: challenges, aspirations, focus areas, guiding principles, activities and measurements filled in with the whole team — The UX Blueprint, filled in together with all 9 people on the team.

User Personas

With the survey responses steadily coming in, I moved forward with the User Personas, built on the behavioural patterns, needs and pain points the data kept repeating. While the surveys continued to gather input, I was defining the application's structural blueprint and establishing the visual direction, so both evolved cohesively.

User Flow

With the two target users identified, the open question was the order of the steps between opening the app and sharing a ride: which screens, which decisions, and where a route was allowed to branch.

This is also what made an MVP definable. With the path drawn we could tell what the product had to do to work at all from what could wait for a later release, and that line had to exist before a single wireframe was worth drawing.

I took the Happy Path first. The developers were sitting right next to me, so the constraints surfaced as we went rather than at handover.

User flow for creating and editing a weekly routine — Routine edition / creation flow

User flow for deleting a trip, with the cancellation confirmation branch — Delete trips flow

User flow for matching with drivers or passengers and sending a trip request — Trip requests flow

User Testing

For the new User Flow, we didn't have anything built, and the current version of the app didn't cover the new steps. We had to check if the whole idea made sense real quick. So I prepared some really, really low fidelity wireframes.

Twelve paper wireframes laid out on a table, sketching the onboarding, routine setup and trip matching flow — Real, really low fidelity wireframes. I no longer have the notes from those sessions, but what came out of them is what the flow below was built on.

Hoop Evolution

With the low-fidelity flow validated, it was time to bring Hoop from paper to product. The home screen went from a bare V0, built around a simple "driver or passenger" choice, to a V1 where routines, upcoming trips and a full navigation bar came together into one coherent home.

Hoop V0 home screen: a referral banner offering three euros per invited friend and a free trip for every five shared, an illustration of two people in a car, and the choice between Soy conductor and Soy pasajero over Publicar, Buscar and Mis trayectos buttons

Hand drawn wireframe of the new home on paper: a greeting, a where are you going field with A casa and Al trabajo shortcuts, and Próximos trayectos listing Monday's two trips with a row of driver avatars under each

And the app flow grew with it

The Happy Path came first: three diagrams, one route through the product. This is the board it grew into, ten labelled areas running from onboarding and routine creation, through sending a request and a driver accepting it, out to favourite addresses, the profile, the wallet and the promotions.

Every screen in the app, and the two paths that split at the routine: the passenger sends a request, the driver accepts it. The board is the MVP line drawn, not a picture of one flow.

Some additional screens

Sign in sheet: continue with Google, Facebook, Apple ID or a phone number

Extra Work

Sometimes I lend a hand to make some marketing-oriented designs.

Designs for a vertical totem

Second totem design, 'Cómo funciona': create your account, post your daily trips, start travelling with company — The second face, explaining the service

Store card: 'Let's carpool!' over a phone showing the week's upcoming trips — Pictures for the Store

Store card: 'Comfortable, Affordable and Sustainable', with a phone showing a trip and its price — Pictures for the Store

Out Of The Nest

As my first role as a designer, and my first experience in a tech company, I initially felt intimidated by the unknown. This project became a true baptism by fire, but through user testing and continuous iteration, it evolved into a product I'm genuinely proud of. I was also lucky to be surrounded by an incredibly supportive and inspiring team.

Learnings

Developers are an audience for design work too: a clear, well-documented Figma file saves more time than any handover meeting.
Nothing is ever perfectly tied up. Review and iteration are the work itself, not a phase at the end of it.
User needs and business goals have to be argued into alignment. They rarely arrive there on their own.
Ask the question, however basic it sounds. Asking early costs a minute; assuming costs a rebuild.

The Challenge

My first role as a designer, at a startup where the founders were still deciding the product while I was designing it.
The only designer on it, and nobody above me to check the work against. Every call was mine to make and mine to answer for.
A team small enough that there was no process between a decision and the build, and no quiet way to be wrong.