La situation

L'application organise le trajet : recherche, réservation, paiement. Elle s'arrête à la porte du point de rendez-vous. Lors d'un festival ou d'un match, ce dernier mètre devient le moment le plus incertain du voyage.

Périmètre d'intervention

Recherche de trajet en contexte événementiel, coordination du groupe et retrouvailles sur place. Le paiement et la relation après trajet restent hors périmètre.

Hypothèses de départ

• Un trajet lié à un événement n'est pas un trajet comme un autreIl concerne plusieurs personnes qui ne se connaissent pas
• Sans repère visuel partagé, le groupe se fragmente à l'arrivéeL'incertitude naît de la foule, pas du trajet
• Coordonner avant le départ réduit le stress sur placeLa confiance se construit en amont, pas au moment des retrouvailles

Axes de problème

• IdentificationRien ne distingue un trajet d'événement d'un trajet ordinaire.
• CoordinationLe groupe n'a aucun espace commun avant le départ.
• RepérageSur place, chacun cherche seul dans la foule.

Le pari

Le trajet n'est pas le problème. Ce sont les cinquante derniers mètres.

Benchmark

• Concurrences directesLa coordination s'arrête à la réservation du trajet.
• Inspirations élargiesLe repérage passe par la position partagée et un signal visuel.

Opportunités identifiées

• DistinguerRendre un trajet d'événement identifiable.
• RassemblerDonner au groupe un espace avant le départ.
• Se repérerSe retrouver sur place, dans la foule.

Pistes explorées

• Point de rendez-vous imposé par l'applicationRigide : un lieu choisi d'avance ne survit pas à une foule qui se déplaceÉcartée
• Appel téléphonique déclenché depuis le trajetBruyant et intrusif : inutilisable dans le contexte même du problèmeÉcartée
• Tag d'événement sur le trajetSe greffe sur la recherche existante, sans nouveau parcours à apprendreRetenue
• Position partagée et signal visuel sur placeRépond au repérage sans supposer que le groupe se connaisseRetenue

Parti pris

Ne pas fixer un point de rendez-vous, mais rendre chacun repérable par les autres.

Principes de conception

• Se grefferChaque fonction s'ajoute à un parcours existant, jamais à côté.
• Rien d'imposéL'application propose des repères, elle ne décide pas du lieu.
• Système existantAucun composant inventé : le système BlaBlaCar est étendu, pas remplacé.

Parcours utilisateurs

Décisions

• 

  3/5 ont lu « Rafraîchir »

  L'icône et son animation évoquaient un rechargement. Icône revue, animation supprimée.

  5/5 n'ont pas ouvert la messagerie

  Le point d'entrée n'apparaît pas au moment où le besoin existe. Non corrigé : à repositionner dans la prochaine itération.

Protocole

• 5 utilisateursUsagers du covoiturage en contexte événementiel.
• 3 parcoursUn par fonctionnalité, sans indication préalable.
• 45 minLes hésitations comptent autant que les erreurs.

Ce que j'en retiens

• Déclarer plutôt qu'affirmerSans terrain, écrire les paris noir sur blanc était la seule façon de pouvoir les remettre en cause.
• Une icône n'est jamais neutreTrois testeurs sur cinq ont lu « Rafraîchir » là où il s'agissait d'un radar. Le sens ne se décrète pas.
• Concevoir sous contrainteTravailler dans le système BlaBlaCar oblige à argumenter chaque écart plutôt qu'à inventer.

Faire autrement

Écrire un scénario de test qui ne pouvait pas prouver l'hypothèse.

Aucun des cinq testeurs n'a ouvert la messagerie, non parce qu'elle est inutile, mais parce que rien dans le parcours ne créait le besoin de communiquer. Ce n'est pas l'hypothèse qui a échoué, c'est le test.

Prochaine itération