Les 30 premières secondes : tester la première impression

Il a installé votre application dans un taxi, avec ce qui restait de son forfait. Elle s’ouvre sur trois écrans de présentation, puis réclame ses contacts, sa position et le droit de lui envoyer des notifications. Il ne sait toujours pas à quoi elle sert. Il appuie sur « Refuser », puis la désinstalle.

La première impression se joue très vite. En 2006, une équipe de l’université Carleton, au Canada, menée par Gitte Lindgaard, a montré que des internautes se font une opinion sur l’attrait visuel d’une page web en 50 millisecondes environ. Votre application n’a pas beaucoup plus de temps pour dire ce qu’elle est et donner envie d’aller plus loin.

La bonne nouvelle : la première impression se teste, avec des méthodes simples, connues et peu coûteuses. À la fin de cet article, vous saurez mener un test des 5 secondes et un test de premier usage, et passer votre parcours d’accueil à une liste de contrôle complète.

Que doit comprendre l’utilisateur dans les premières secondes ?

Devant le premier écran, un nouvel utilisateur se pose trois questions, souvent sans s’en rendre compte :

1. Qu’est-ce que c’est ? La promesse de l’application tient-elle en une phrase claire ?
2. Est-ce pour moi ? Les images, les mots, la langue et les prix lui parlent-ils ?
3. Que dois-je faire maintenant ? Une action principale se détache-t-elle des autres ?

Comparez deux accroches pour une application de livraison. « Votre partenaire logistique du dernier kilomètre » : on ne sait ni ce qui est livré, ni où, ni comment payer. « Vos courses livrées chez vous à Douala, payées par mobile money » : on sait quoi, où et comment.

La langue compte dès cette seconde. Au Cameroun, où le français et l’anglais sont les deux langues officielles, une application qui n’en propose qu’une écarte une partie du public. Proposez par défaut la langue du téléphone, un choix de langue bien visible, et ne mélangez jamais deux langues sur un même écran.

Apple rappelle aussi qu’un écran de démarrage (splash screen) doit rester bref, et qu’un gros téléchargement ne doit pas empêcher de commencer. Sur un forfait limité, cette règle pèse double.

L’inscription : chaque champ est une occasion d’abandon

Demandez seulement ce dont vous avez besoin maintenant ; le reste viendra quand l’utilisateur comprendra pourquoi vous le demandez. Mieux encore : quand le service le permet, laissez découvrir le catalogue ou les prix avant d’exiger un compte.

Voici ce qu’il faut tester, élément par élément :

• Numéro de téléphone : indicatif proposé selon le pays, clavier numérique, numéro accepté avec ou sans espaces.
• Code OTP : remplissage automatique quand le système le permet (sur le web, l’attribut autocomplete="one-time-code"), compte à rebours visible, bouton « Renvoyer le code », possibilité de corriger le numéro. Essayez un code faux, un code expiré, un SMS qui arrive après trois minutes.
• Aller-retour vers les SMS : l’utilisateur quitte l’application pour lire son code, puis revient. Le formulaire est-il intact, ou faut-il tout recommencer ?
• Mot de passe : règles affichées avant la saisie plutôt qu’après l’échec, bouton pour afficher le mot de passe, collage autorisé pour les gestionnaires de mots de passe.
• Connexion avec Google ou Apple : rapide, mais pas universelle. Gardez une autre voie pour ceux qui n’ont pas ce compte ou ne veulent pas l’utiliser.

Les permissions : au bon moment, avec une bonne raison

Réclamer les contacts, la position et les notifications dès l’ouverture est l’une des erreurs d’onboarding les plus visibles. Les deux grandes plateformes disent la même chose :

• Android recommande de demander une permission en contexte, quand l’utilisateur commence à se servir de la fonction qui en a besoin, d’expliquer pourquoi si nécessaire, et de laisser l’application utilisable en cas de refus, sans harceler l’utilisateur.
• Apple conseille de présenter la demande au moment où la personne utilise pour la première fois la fonction concernée, et de ne l’intégrer à l’onboarding que si l’application ne peut pas fonctionner sans.

Exemple : une application de livraison qui demande la position au démarrage paraît intrusive. La même demande, quand l’utilisateur appuie sur « Utiliser ma position actuelle » pour saisir son adresse, paraît évidente. Même logique pour les notifications : proposez-les juste après une commande (« Voulez-vous être prévenu quand le livreur arrive ? »), pas au premier lancement.

Tutoriels et premier écran vide

Les tutoriels en plusieurs cartes, qu’on fait défiler avant d’accéder à l’application, sont souvent passés sans être lus. Le Nielsen Norman Group constate qu’ils n’améliorent pas de façon fiable la réussite des tâches, et recommande plutôt des conseils contextuels, affichés au moment où ils servent. Apple va dans le même sens : apprendre en faisant, garder le tutoriel court et facultatif, et permettre de le retrouver plus tard.

Le premier écran « réel » est souvent vide : aucune commande, aucun contact, aucun historique. Un état vide (empty state) bien conçu fait trois choses :

1. Il dit que c’est normal : « Vous n’avez pas encore passé de commande », plutôt qu’un écran blanc qui ressemble à une panne.
2. Il explique à quoi servira cet espace.
3. Il propose l’étape suivante : un bouton « Voir les restaurants près de chez moi ».

Attention au faux vide : sur un réseau lent, afficher « Aucun résultat » pendant que les données chargent fait croire qu’il n’y a rien. Montrez d’abord un indicateur de chargement, et vérifiez ce comportement en suivant notre méthode pour tester une application sur réseau lent.

Le test des 5 secondes, pas à pas

Le test des 5 secondes a été popularisé par Christine Perfetti, qui l’a décrit dans un article de 2007. Le principe : montrer un écran pendant cinq secondes seulement, le cacher, puis demander ce qu’on en a retenu. Au-delà de ce délai, explique-t-elle, les participants se mettent à examiner l’écran comme des designers, ce que ne fait aucun utilisateur réel.

1. Choisissez un écran à objectif unique : l’écran de bienvenue qui précède l’inscription, la fiche de l’application sur le store, une page d’atterrissage. Perfetti déconseille la méthode pour les pages d’accueil aux usages multiples, comme un tableau de bord chargé.
2. Donnez un contexte : « Vous cherchez un moyen de vous faire livrer vos courses. Je vais vous montrer un écran pendant cinq secondes ; retenez-en le plus possible. »
3. Montrez l’écran cinq secondes sur un téléphone, puis cachez-le.
4. Faites noter au participant tout ce dont il se souvient.
5. Posez trois questions : « À quoi sert cette application ? », « Pour qui est-elle faite ? », « Qu’auriez-vous fait en premier ? »
6. Comparez les réponses à la promesse que vous vouliez faire passer.

Fixez-vous un seuil avant de commencer, par exemple : au moins quatre personnes sur cinq décrivent correctement le service avec leurs propres mots. En dessous, réécrivez l’accroche avant de tester quoi que ce soit d’autre.

Le test de premier usage, pas à pas

Le test de premier usage est un test utilisateur classique, centré sur la découverte : des personnes qui n’ont jamais vu votre application l’installent et cherchent à obtenir leur première réussite, en pensant à voix haute. La méthode générale est détaillée dans notre guide pour organiser un test utilisateur ; voici ce qui change.

• Partez du store, pas de l’application déjà ouverte : la fiche, la taille du téléchargement et l’installation font partie de l’expérience.
• Recréez de vraies conditions : le téléphone du participant ou un appareil d’entrée de gamme, ses données mobiles, une application jamais installée ou dont les données ont été effacées.
• Donnez un seul objectif : « Envoyez 1 000 FCFA à ce numéro de test » ou « Commandez un plat pour ce soir ».
• Observez trois choses : le temps jusqu’à la première réussite, l’endroit où chacun hésite ou abandonne, et le tout premier appui, qui montre si l’écran indique clairement le chemin.
• Terminez par une question ouverte : « Expliquez-moi en une phrase à quoi sert cette application. » Comparez avec la réponse donnée au test des 5 secondes.

La liste de contrôle de l’onboarding et les erreurs fréquentes

Les erreurs que l’on retrouve le plus souvent :

• Tester avec l’équipe. Elle connaît la promesse par cœur : elle ne peut plus la découvrir.
• Tester une installation déjà utilisée. Un compte connecté et des permissions déjà accordées masquent tout l’onboarding. Désinstallez l’application ou effacez ses données avant chaque séance.
• Ne tester que le chemin heureux. Code erroné, SMS en retard, permissions refusées, appel entrant pendant l’inscription : c’est là que l’utilisateur abandonne.
• Oublier la deuxième langue. Les textes traduits sont souvent plus longs, coupés, ou restés dans la langue d’origine.

Avant la mise en ligne, ajoutez ces points à votre checklist avant publication. Et pour un regard vraiment neuf, des testeurs GeekTest qui n’ont jamais vu votre application peuvent vivre ce premier usage sur leurs propres téléphones : il suffit de commander un test.

Pour aller plus loin

• 5-Second Tests : Measuring Your Site’s Content Pages (nouvel onglet) — Christine Perfetti (2007). L’article qui décrit le protocole du test des 5 secondes, ses usages et ses limites.
• Attention web designers : You have 50 milliseconds to make a good first impression ! (nouvel onglet) — Gitte Lindgaard et al., Behaviour & Information Technology (2006). L’étude sur la vitesse de formation des premières impressions.
• Onboarding Tutorials vs. Contextual Help (nouvel onglet) — Page Laubheimer, NN/g (2023). Pourquoi l’aide en contexte fonctionne mieux que les tutoriels d’accueil.
• Designing Empty States in Complex Applications : 3 Guidelines (nouvel onglet) — Kate Kaplan, NN/g (2021). Comment un écran vide peut informer, enseigner et guider.
• Request runtime permissions (nouvel onglet) — Android Developers. Les règles officielles pour demander une permission au bon moment et gérer les refus.
• Onboarding, Human Interface Guidelines (nouvel onglet) — Apple. Les recommandations d’Apple pour un accueil court, interactif et facultatif.