Outil de démo
Demo Kit
Rejouer un parcours d'achat eSIM en conditions réelles, sur le téléphone d'un commercial.
- Thales
- Product Designer
- 8 mois, de la demande initiale au handoff
Un outil de démonstration où chaque fonction qui sert le vendeur menace la crédibilité de la démonstration.
- Le produit : le parcours d'achat et d'activation d'un profil eSIM rejoué de bout en bout, vérification d'identité et téléchargement réels inclus, rebrandable avant chaque rendez-vous.
- La recherche : 6 commerciaux interrogés puis re-sollicités pour tester, 10 tests guérilla, une inversion du tunnel d'achat.
- Mon rôle : Product Designer, seule designer, en binôme avec un développeur.
Nomad · opérateur fictif
Le parcours d'achat sur « Nomad », un opérateur inventé
Aucune marque, aucun client ni aucune interface réels. Les écrans réservés aux commerciaux sont restitués en schéma plus bas.
La vérification d'identité est coupée du montage, car cette brique appartient à Thales. Elle s'intercale entre le forfait et le paiement (voir « La décision clé »).
Deux utilisateurs, un seul écran
Les équipes commerciales vendent des solutions eSIM à des opérateurs télécoms. Pour montrer le produit, elles avaient des slides et des captures d'écran : le prospect devait imaginer le parcours.
L'application le rejoue en conditions réelles, sur le téléphone du commercial : destination, forfait, vérification d'identité, paiement, téléchargement d'un vrai profil eSIM. Elle se rebrande aux couleurs du prospect avant le rendez-vous.
Le parcours d'achat existait déjà. Le vrai sujet : deux utilisateurs regardent le même écran. Le commercial a besoin de contrôle pour sauter des étapes, repartir de zéro entre deux rendez-vous ou ajuster un prix au catalogue du prospect. Le prospect ne doit rien voir de tout cela : s'il aperçoit un bouton de réinitialisation, il regarde une maquette.
Mon rôle
Product Designer, seule designer, en binôme avec un développeur.
Recherche et synthèse, schéma d'architecture fonctionnelle validé avec le PM avant les premières maquettes, conception des écrans et du système de branding, prototype et tests, textes écrits avec le marketing, handoff et suivi jusqu'à la mise en œuvre.
Chaque fonction vient du terrain
Six commerciaux, une consigne : raconter leur dernier rendez-vous client minute par minute, plutôt que lister les fonctionnalités qu'ils voudraient. Trois contraintes sont apparues, absentes de toute spécification :
- Ils enchaînent les rendez-vous : il faut une remise à zéro complète en quelques secondes.
- Ils rencontrent des opérateurs concurrents : le branding doit changer avant chaque rendez-vous.
- Leur temps de parole varie : les étapes longues doivent pouvoir être sautées.
Chaque fonction de la couche vendeur répond à une contrainte observée. C'est ce qui a permis de trancher le périmètre avec le PM : ce qui ne se rattachait à aucun besoin observé est resté hors de la première version.
6
commerciaux interrogés en amont, puis re-sollicités pour tester le prototype : les mêmes personnes en entrée et en sortie de conception
La décision clé : vérifier l'identité avant de faire payer
Dans le parcours d'origine, l'utilisateur payait, puis vérifiait son identité. Les commerciaux et les tests ont soulevé la même objection, presque mot pour mot : payer sans savoir si la vérification aboutira est anxiogène. L'argent part alors que le service n'est pas garanti, et pour un achat en mobilité, souvent juste avant un départ, cette hésitation suffit à faire abandonner.
J'ai inversé les deux étapes.
Décision clé · inversion du tunnel d'achat
Cliquez une étape pour voir ce qu'elle coûte et ce qu'elle rapporte.
Deux parcours comparés. Parcours d'origine, dans l'ordre : destination, forfait, paiement, vérification d'identité, téléchargement du profil. Parcours livré, dans l'ordre : destination, forfait, vérification d'identité, paiement, téléchargement du profil. Les étapes de paiement et de vérification d'identité ont été inversées.
AvantParcours d'origine
AprèsParcours livré
Deux étapes inversées, rien d'autre : la même objection est revenue des six commerciaux et des tests guérilla. Payer sans savoir si la vérification aboutira est anxiogène.
Vérification d'identité
Étape la plus lourde du parcours. Placée avant le paiement, elle fait remonter les abandons dans le tunnel, sur un utilisateur qui n'a encore rien investi.
Le coût : l'étape la plus lourde passe avant le paiement, sur un utilisateur qui n'a encore rien investi, et les abandons remontent dans le tunnel. Le gain : personne ne paie un service qu'il ne pourra peut-être pas activer, et l'opérateur évite un remboursement et un client perdu.
Tester les deux ordres, vérification avant ou après le paiement, a aussi permis de mesurer lequel engageait le plus les utilisateurs.
Deux autres décisions
Un menu de pilotage rangé là où le prospect ne va pas.
Les fonctions de pilotage sont regroupées dans un écran unique, sous « Admin » dans les réglages. Rien ne l'annonce dans le parcours d'achat, et le libellé ne dit rien à un prospect qui regarde par-dessus l'épaule du commercial.
J'ai écarté l'option d'un geste secret. Un commercial qui ne retrouve pas sa remise à zéro devant un client perd plus que ce que la dissimulation lui fait gagner.
L'écran sépare ce qui se prépare avant le rendez-vous (opérateur, couleurs, logo), ce qui se règle pendant (passer l'onboarding ou la vérification d'identité) et la réinitialisation, isolée en bas. L'opérateur et le thème actifs restent affichés en permanence : le pire scénario serait de démarrer une démonstration aux couleurs du concurrent vu la veille.
1 · Réglages
2 · Menu commercial
Un thème neutre, conçu pour être remplacé.
Le thème sombre n'appartient à aucun opérateur : c'est la base. Le thème clair montre l'application habillée aux couleurs d'un client. Chaque composant devait supporter un changement de couleur et de logo sans casser la mise en page ni le contraste.
Trois variables seulement sont exposées : logo, couleur primaire, nom de l'opérateur. Sous 4,5:1, les libellés posés sur la couleur primaire basculent automatiquement en foncé : le commercial ne peut pas produire un écran non conforme.
3 · Branding
Résultats
Ce qui a été validé
8 / 10
personnes découvrant l'eSIM ont téléchargé et activé un profil sans aide, en test guérilla
des inconnus, pas les commerciaux
La reconnaissance
Best of Thales Design
sélectionné pour représenter ma branche
Le statut.En cours de développement, pas encore déployé auprès des équipes commerciales. Aucune donnée d'usage réel à ce jour.
Ce que j'en retiens
La recherche cartographie les utilisateurs, pas la plateforme. Mes six entretiens ont décrit le métier commercial avec précision, sans rien dire de ce que le système d'exploitation impose, ni de ce qui arrive à l'application après trois vrais téléchargements de profils.
Trois des fonctions les plus structurantes sont nées au handoff, soulevées par le développeur : l'autorisation de localisation, le changement de profil, la bibliothèque de branding. Ce projet a déplacé le moment où je fais entrer la technique dans la conception : dès le cadrage, et plus seulement à la livraison.