Heetch · Jaime Villegas Maira

01 / 04

Case Study — extension micro-mobilité, +15 % de revenu, trajets < 3 km.
02 / 04

Ideation — benchmark, Success Keys, priorisation MoSCoW.
03 / 04

Prototyping — flow mid-fidelity puis hi-fi v1.
04 / 04

Test — flow et affordance, apprentissages chiffrés (4/5).

Mon rôle

Product Designer

Mission The Design Crew, en équipe — projet structuré en trois phases : Ideation, Prototyping, Test.

Cas client : Heetch (plateforme française type Uber) veut lancer un service de micro-mobilité (vélos, trottinettes) pour capter les trajets courts. Triple contrainte : +15 % de revenu, retention sur les trajets < 3 km, sans cannibaliser l'activité chauffeurs existante.

Ideation — benchmark des apps de micro-mobilité (onboardings, unlock, icons & affordance), formulation des Success Keys, priorisation MoSCoW.
Prototyping — user flow mid-fidelity comme base, puis hi-fi v1 sur les écrans clés (recherche carte, onboarding, parking, outboarding, évaluation).
Test — panel utilisateurs, objectifs compréhension du flow et vérification d'affordance des nouveaux boutons.

Ce que je n'ai pas fait : le code, la négociation des contrats opérateurs vélos / trottinettes, la stratégie tarifaire.

Trois décisions

Les arbitrages qui ont structuré le projet

01
S'appuyer sur le « collective unconscious » des apps existantes

Premier réflexe sur un nouveau service : inventer les patterns Heetch. Risque : forcer les utilisateurs à apprendre un système alors qu'ils connaissent déjà Lime, Tier, Bolt.

J'ai cadré un benchmark structuré sur trois axes — onboardings, unlock systems, icons & affordance. Apprentissage clé : il existe un inconscient collectif sur la micro-mobilité, partagé mondialement. Décision : s'appuyer dessus plutôt que ré-inventer. Adoption rapide, courbe d'apprentissage minimale, énergie design réservée à ce qui différencie Heetch (positionnement, ton, valeurs).
02
Priorisation MoSCoW + Success Keys explicites

Tentation classique sur un nouveau service : empiler les features pour différencier. Risque : surcharger un produit que les utilisateurs doivent déjà apprendre.

J'ai cadré une priorisation MoSCoW stricte — Must Have : search map, unlock, parking, onboardings / outboarding. Should Have : valeurs écologiques, wording jeune, évaluation. Could Have : route sharing, group ride. Won't Have : NFC unlocking. Plus deux Success Keys explicites : simplifier les onboardings, reporter certaines fonctionnalités en itérations 2 / 3 pour privilégier l'adaptation rapide au service.
03
Le test utilisateur valide les Success Keys initiaux

L'équipe s'est laissé tenter par couvrir aussi les Could Have (Route Sharing, Group Ride) — solution « robuste » qui dépasse le MoSCoW. Test utilisateur sur panel :

4 / 5 — « Too much onboarding » (citation Madjide D. : « To me it's advertising »). 4 / 5 — « Didn't understand some features » sur Route Sharing et Group Ride (citation Eloïse G. : « I don't know what this button does »). Apprentissage : respecter le temps de maturation de l'utilisateur avec le service avant d'innover plus loin — exactement ce que disaient les Success Keys initiaux. Décision corrective : revenir au MoSCoW serré, reporter les Could Have.

Impact

Ce que ça a livré

Cadrage stratégique de l'extension micro-mobilité chez Heetch — KPI ciblés (+15 % de revenu, rétention trajets < 3 km), contrainte respectée (pas de cannibalisation chauffeurs).
Benchmark documenté sur trois axes : onboardings, unlock, icons & affordance — base partagée d'une grammaire connue par les utilisateurs.
Priorisation MoSCoW validée, deux Success Keys explicites (simplifier onboardings, reporter features non-MVP).
Prototypes mid-fi puis hi-fi v1 sur le flow complet : search map, unlock, parking, outboarding, évaluation.
Test utilisateur réalisé : deux apprentissages chiffrés (4 / 5), décision corrective de revenir au MoSCoW serré avant production.