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 à la livraison développement
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. Sélectionné pour représenter ma branche au Best of Thales Design.
- 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 n'y figurent. Les écrans de configuration réservés aux commerciaux ne sont pas montrables : ils sont restitués sous forme de schéma, dans la section « Deux autres décisions ».
La vérification d'identité est coupée du montage. Cette brique appartient à Thales et ne peut pas être diffusée. Elle s'intercale entre le forfait et le paiement, à l'emplacement décidé en section « La décision clé ».
Le projet
Les équipes commerciales vendent des solutions eSIM à des opérateurs télécoms. Pour montrer à quoi ressemble le produit, elles disposaient de slides et de captures d'écran. Le prospect devait imaginer le parcours au lieu de le voir.
L'application le rejoue en conditions réelles, sur le téléphone personnel du commercial : choix de la destination, sélection du 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 sujet n'était pas le parcours d'achat, qui existait déjà. Il tenait dans une contradiction : deux utilisateurs regardent le même écran. Le commercial a besoin de contrôle, pour sauter des étapes quand le temps manque, repartir de zéro entre deux rendez-vous, changer un prix afin de coller au catalogue du prospect. Le prospect, lui, ne doit rien voir de tout cela. À l'instant où il aperçoit un bouton de réinitialisation, il ne regarde plus un produit, 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.
La recherche
Six commerciaux, une consigne : raconter leur dernier rendez-vous client minute par minute, plutôt que décrire les fonctionnalités qu'ils voudraient.
Ce que le terrain a rendu visible ne figurait dans aucune spécification. Ils enchaînent plusieurs rendez-vous dans la journée, donc il faut une remise à zéro complète en quelques secondes. Ils se déplacent chez des opérateurs concurrents, donc le branding doit changer avant chaque rendez-vous. Leur temps de parole varie d'un client à l'autre, donc les étapes longues doivent pouvoir être sautées.
Aucune fonction de la couche vendeur ne vient d'une intuition. Chacune répond à une contrainte observée, et c'est ce qui a permis de trancher le périmètre avec le PM : ce qui ne se rattachait à aucun besoin observé n'entrait pas dans 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é, puis faire payer.
Dans le parcours d'origine, l'utilisateur payait, puis vérifiait son identité. La même objection est revenue des commerciaux et des tests, formulée presque à l'identique : payer sans savoir si la vérification aboutira est anxiogène. Le risque perçu est asymétrique, puisque l'argent est parti alors que le service n'est pas garanti. Sur un produit acheté en mobilité, souvent juste avant un départ, l'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 de ce parti pris : l'étape la plus lourde du parcours passe avant le paiement, sur un utilisateur qui n'a encore rien investi. Les abandons remontent dans le tunnel. Le gain : personne ne paie pour un service qu'il ne pourra peut-être pas activer, et l'opérateur n'a pas à absorber derrière un remboursement et un client perdu.
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, accessible depuis les réglages de l'application, sous le libellé « Admin ». Le pattern est celui des outils internes : pas de porte dérobée, mais un emplacement que rien n'annonce dans le parcours d'achat, et un libellé qui ne dit rien à un prospect regardant l'écran par-dessus l'épaule du commercial.
Le choix inverse existait : dissimuler complètement l'accès derrière un geste secret. Je l'ai écarté. Un commercial qui ne retrouve pas sa remise à zéro devant un client perd plus que ce que la dissimulation lui fait gagner. La fiabilité d'accès l'emporte sur le camouflage, et le risque résiduel est un libellé technique dans une liste de réglages.
L'écran sépare ce qui se prépare avant le rendez-vous (opérateur, couleurs, logo) de ce qui se règle pendant (passer l'onboarding, passer la vérification d'identité) et de ce qui est destructif, la réinitialisation, isolée en bas. L'opérateur et le thème actifs restent affichés en permanence : le pire scénario de ce produit est un commercial qui démarre une démonstration aux couleurs du concurrent qu'il a 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 par défaut. Le thème clair est la démonstration de ce que devient l'application habillée aux couleurs d'un client. Chaque composant devait supporter un changement de couleur primaire et de logo sans qu'aucun écran ne casse, ni en mise en page ni en 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 ont téléchargé et activé un profil eSIM sans aide, en test guérilla auprès de personnes découvrant l'eSIM
des inconnus, pas les commerciaux
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
Le statut.En cours de développement. L'application n'est pas encore déployée 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, et n'ont rien dit de ce que le système d'exploitation impose ni de ce qui arrive à l'application une fois qu'elle a réellement téléchargé trois profils. Trois des fonctions les plus structurantes du produit (l'autorisation de localisation, le changement de profil, la bibliothèque de branding) sont nées du handoff, soulevées par le développeur.
Ce projet a déplacé pour moi le moment où la technique entre dans la conception. Elle n'arrive pas à la livraison : elle appartient au cadrage.