BlaBlaCarTraining project · 2026Finding each other is already part of the journey
Rethinking the BlaBlaCar experience at major events, where drivers and passengers have to meet up in a crowd.
- The problem
- At a festival or a match, these last few metres become the most uncertain moment of the journey.
- What we designed
- Event tag, ride group and radar.
- What the tests showed
- Three testers out of five read “Refresh” where it was a radar.
- My part
- I worked on the planning and the ride search.
- Deliverable
- benchmark, wireframes, mockups, tested prototype
- Role
- discovery, UI design, user testing
- Context
- training project, The Design Crew
- Team
- 3 product designers, shared work on every feature
- Methods
- 5 user tests
Framing
The ride is not the problem. The last fifty metres are.
Meeting up as a group, in a crowd
With no access to the field, the project starts from hypotheses stated explicitly, then checked against user tests.
Starting hypotheses
- A ride to an event is not like any other rideIt involves several people who do not know each other
- Without a shared visual cue, the group splits up on arrivalThe uncertainty comes from the crowd, not from the ride
- Coordinating before departure reduces stress on siteTrust is built beforehand, not at the moment of meeting up
How can we help drivers and passengers better manage their ride at these major events?
Discovery
Do not set a meeting point: make everyone easy for the others to spot.
Finding each other without effort
Observing how other products bring a group together in a place it does not know.
- A meeting point set by the appRigid: a place chosen in advance does not survive a crowd on the moveDropped
- A phone call started from the rideNoisy and intrusive: unusable in the very situation the problem comes fromDropped
- An event tag on the rideBuilds on the existing search, with no new flow to learnKept
- Shared location and a visual signal on siteHelps people spot each other without assuming the group members know one anotherKept
Design
The app offers cues; it does not choose the place.
Event tag, ride group and radar
The event tag is added to the existing search, the group is created at booking and the radar is used on site. Everything stays within the BlaBlaCar design system.
Design principles
- Build on what existsEach feature is added to an existing flow, never alongside it.
- No new componentThe tag, the group and the map rely on elements the app already has.
User flows
Plan
Search resultsThe tag flags the ride
Filter by eventThe list narrows down
Ride detailsThe event information
A tag on the ride rather than a page dedicated to events.
Organise
Ride groupCreated at booking
MessagesBefore departure
A group created automatically rather than an invitation to send.
Sync up
Photo of the vehicleShared by the driver
Real-time mapEveryone's location
RadarSpotting each other in the crowd
A two-way signal rather than one-way location sharing.
User testing
3/5 read “Refresh” where it was a radar.
Five sessions on an interactive prototype. Each feature is tested against a hypothesis written in advance: it is the only way to close the loop when you start without field research.
Hypotheses tested
| Hypothesis | Result | Follow-up |
|---|---|---|
| Event/standard classificationPartly | 3/5 saw and used the classification | To clarify: the affordance of the tags. |
| Relevance of the RadarPartly | 2/5 identified the radar, 3/5 read “Refresh” in it | Icon redesigned, animation removed. |
| Messaging built into the mapNot assessed | The test scenario did not naturally lead to the messaging | Not fixed: to be repositioned in the next iteration. |
Decisions
3/5 read “Refresh”
The icon and its animation suggested a reload. Icon redesigned, animation removed.
5/5 did not open the messaging
The entry point does not appear at the moment the need arises. Not fixed: to be repositioned in the next iteration.
Retrospective
A concept without field research, but not without method.
Three hypotheses set out, three features designed, five tests and one hypothesis that the protocol could not prove.
What I learned
- State rather than assertWithout field research, writing our bets down in black and white was the only way to be able to question them.
- Designing under constraintWorking within the BlaBlaCar system means justifying every departure from it instead of inventing.
Doing it differently
Writing a test scenario that could not prove the hypothesis.
None of the five testers opened the messaging, not because it is useless, but because nothing in the flow created a need to communicate. It was not the hypothesis that failed, it was the test.
- Rebuild the scenario around something going wrong on the rideA delay, a change of location: without an incident, there is no need
- Reposition the entry point to the messagingIt does not appear at the moment the need arises
- Check that the new radar icon can be read without help