01

Premier Contact : L’Écran d’Accueil

C’est la première chose qu’un nouvel utilisateur voit après avoir installé l’application depuis le Google Play Store. L’intention est claire : amener l’utilisateur à saisir son adresse e-mail et commencer l’inscription. L’exécution, cependant, va immédiatement à l’encontre de cet objectif.

L’écran est encombré. Les logos de sponsors, les marques et le bruit visuel rivalisent pour capter l’attention de l’utilisateur au moment précis où cette attention est la plus précieuse. C’est une violation directe de la Hiérarchie Agressive, le principe selon lequel chaque écran doit avoir un point focal dominant unique qui guide le regard sans ambiguïté.

Les logos de sponsors ont leur place sur un site web, sur des supports marketing, dans un programme de match. Ils n’ont pas leur place sur un écran d’inscription. Leur présence ici signale à l’utilisateur, de manière inconsciente mais puissante, que cet écran n’a pas été conçu en pensant à lui.

02

Le Formulaire d’Inscription

Après avoir appuyé sur le bouton d’inscription, l’utilisateur arrive au formulaire d’inscription. C’est ici que la première défaillance technique critique se révèle.

L’adresse e-mail saisie sur l’écran précédent n’est pas reportée sur cette page. L’utilisateur doit la saisir à nouveau intégralement. Ce n’est pas un désagrément mineur. C’est une promesse non tenue.

C’est d’autant plus important que la confiance dans un produit numérique se construit par de petits signaux cohérents de compétence. Lorsqu’un système ne peut pas se souvenir de ce que vous avez saisi cinq secondes auparavant, une question inconfortable se pose : « S’il ne peut pas gérer cela, peut-il gérer mes coordonnées bancaires ? »

03

Le Piège de la Casse

L’utilisateur a désormais saisi son adresse e-mail deux fois. Une erreur s’affiche : les adresses « ne correspondent pas ». La seule différence entre les deux saisies est un M majuscule dans le premier champ et un m minuscule dans le second.

Les adresses e-mail sont, selon le standard technique mondial (RFC 5321), insensibles à la casse. Utilisateur@exemple.com et utilisateur@exemple.com sont la même adresse. Il n’y a aucune zone grise.

C’est une défaillance de Micro Détails aux conséquences majeures. Une règle de validation techniquement erronée ne crée pas seulement de la friction. Elle signale à l’utilisateur que le produit n’a pas été construit avec soin.

04

Rejet d’une Adresse E-mail Valide

Après avoir résolu le problème de casse, l’utilisateur rencontre une seconde erreur de validation : l’adresse e-mail est décrite comme « non valide ». L’adresse en question contient un signe plus, une fonctionnalité de Gmail et de nombreux autres fournisseurs qui permet de créer des alias (ex. nom+appname@gmail.com).

L’adressage avec signe plus est une fonctionnalité légitime et largement utilisée du standard e-mail. Le rejeter n’est pas une décision de conception prudente. C’est un bug qui exclut activement un segment d’utilisateurs.

05

Signaux Contradictoires

Les erreurs de validation persistent à l’écran, mais le bouton S’inscrire reste actif et cliquable. L’utilisateur se voit simultanément indiquer que sa saisie est invalide et autorisé à continuer comme si elle ne l’était pas.

Cette contradiction est profondément déstabilisante du point de vue de l’expérience utilisateur. Elle communique que le système ne connaît pas ses propres règles.

06

Abandon Forcé de l’Application

L’utilisateur a traversé cinq écrans de friction et arrive enfin au bout du formulaire d’inscription. Le système lui demande maintenant de quitter complètement l’application, de basculer vers son client e-mail, de trouver le message de vérification et de cliquer sur un lien.

07

L’Application S’ouvre dans un Navigateur Web

L’utilisateur clique sur le lien de vérification dans son e-mail. Au lieu que l’application Impact Stadium s’ouvre, c’est Microsoft Edge qui ouvre une page web.

C’est le moment où le problème architectural fondamental devient indéniable. L’application Impact Stadium n’est pas une application native. C’est un site web encapsulé dans une coquille d’application.

• L’utilisateur ne peut pas être redirigé vers l’app après la vérification
• Les identifiants enregistrés sur cet écran sont sauvegardés dans le navigateur, pas dans l’app
• Les fonctionnalités natives (Apple Pay, Google Pay, authentification biométrique, notifications push) sont inaccessibles
• L’expérience ne ressemblera jamais à une vraie application, parce que ce n’en est pas une

8–9

Navigation dans le Navigateur

L’utilisateur navigue désormais dans ce qu’il croit être son application, mais qui est en réalité une page web dans Microsoft Edge.

10

Mot de Passe Enregistré dans le Navigateur, Pas dans l’Application

Microsoft Edge propose à l’utilisateur de sauvegarder son mot de passe. Il accepte. Le mot de passe a été enregistré dans le gestionnaire de mots de passe du navigateur, pas dans l’application Impact Stadium. La prochaine fois que l’utilisateur ouvrira l’application, il devra se reconnecter intégralement.

11–16

Le Second Onboarding : Six Écrans de Texte Obligatoire

Les utilisateurs ne lisent pas. Ils scannent. Ils cherchent un signal unique et clair leur indiquant qu’ils sont au bon endroit. Au dernier écran du carrousel, l’utilisateur n’a pas lu les informations. Il cherche le bouton qui lui permettra de continuer. Chaque mot sur cet écran a été écrit pour personne.

17

Dans l’Application : Le Tableau de Bord

L’utilisateur est enfin dans l’application. Au lieu d’un tableau de bord clair, il découvre un tableau de bord dense, non structuré et visuellement écrasant. Il n’y a pas de hiérarchie claire. Remarquez également la barre d’adresse de navigateur visible en haut de l’écran.

18

Fermer et Rouvrir l’Application

L’utilisateur ferme l’application et retourne à son écran d’accueil. Il appuie sur l’icône Impact Stadium pour revenir. Il se retrouve face à l’écran d’inscription. Il n’est pas connecté. La session n’a pas persisté.