Comprendre avant de concevoir : la recherche utilisateur sans budget

Le réflexe courant quand on lance un produit : passer directement à Figma. C'est une erreur. L'UX commence avant le premier écran, dans la compréhension précise du problème que tu résous et pour qui tu le résous.

La recherche utilisateur ne nécessite pas un lab dédié ni un budget conséquent. Elle demande de la rigueur et de la curiosité. Quelques entretiens semi-directifs de 30 minutes avec des profils représentatifs de ta cible valent plus que n'importe quelle heatmap sur un produit pas encore validé. L'objectif n'est pas de collecter des opinions sur ton futur design. C'est de comprendre les comportements existants, les outils déjà utilisés, les frictions quotidiennes, les compromis que les gens font faute de mieux.

Concrètement : prépare une grille de 8 à 10 questions ouvertes. Évite les questions sur le produit que tu envisages. Pose des questions sur ce que la personne fait aujourd'hui. Comment elle organise son travail. Ce qui lui coûte le plus d'énergie. Quand elle abandonne un outil. Les patterns qui émergent de 5 à 6 entretiens sont déjà suffisamment solides pour orienter tes premières décisions d'architecture.

Documente tout. Un notion ou un simple tableur suffit. Regroupe les verbatims par thème. Les insights les plus utiles sont rarement ceux que tu anticipais.

Architecture de l'information : décider ce qui existe et où ça va

L'architecture de l'information, c'est la carte mentale que l'utilisateur construit de ton application. Si elle est floue ou incohérente, il ne reviendra pas. Chaque écran doit répondre à une question implicite : où suis-je, que puis-je faire ici, comment je reviens en arrière.

Pour une app mobile, la navigation principale ne doit jamais dépasser cinq éléments. Au-delà, le cerveau commence à arbitrer plutôt qu'à explorer. La règle des trois clics est approximative et souvent mal appliquée, mais l'intention derrière est juste : réduire la charge cognitive à chaque étape. L'utilisateur ne doit jamais avoir à réfléchir pour trouver une fonctionnalité qu'il utilise régulièrement.

Commence par un inventaire brutal de tout ce que ton app contient ou va contenir. Ensuite, applique une hiérarchie claire : ce qui est utilisé tous les jours doit être accessible en un tap. Ce qui est utilisé occasionnellement peut être enterré à un niveau supplémentaire. Ce qui est utilisé une fois (paramètres, profil, onboarding avancé) peut être relégué au fond sans impact sur la rétention.

Un exercice concret : prends chaque écran de ton app et demande-toi quelle action l'utilisateur doit réaliser ici. S'il y en a plus de deux ou trois, tu as probablement un problème de découpage. La densité fonctionnelle est l'ennemie de la clarté.

Pour aller plus loin sur la structure produit, je détaille certains de ces principes dans mon article sur les méthodes et outils de product management.

L'onboarding : la première impression que tu ne peux pas rater

L'onboarding est l'écran le plus important de ton application. Pas le tableau de bord, pas la fonctionnalité principale. Les premières 90 secondes décident si l'utilisateur comprend ce qu'il fait ici ou s'il ferme l'app sans retour.

Un bon onboarding ne présente pas le produit. Il amène l'utilisateur à vivre une première victoire. La distinction est fondamentale. Présenter c'est lister des fonctionnalités avec des illustrations. Faire vivre une victoire c'est guider l'utilisateur jusqu'à un moment où il a accompli quelque chose de concret dans l'app, même minimal.

Les erreurs d'onboarding les plus fréquentes : demander trop d'informations trop tôt (email, nom, préférences détaillées) avant que l'utilisateur ait compris pourquoi il devrait vous les donner. Montrer des écrans de présentation statiques qui n'engagent pas. Proposer immédiatement un choix d'abonnement avant que la valeur soit perçue.

Structure qui fonctionne : une question de personnalisation minimale (une ou deux), un écran qui montre immédiatement l'interface réelle, une action guidée qui produit un résultat visible. La demande de compte ou de paiement vient après, jamais avant ce premier résultat.

J'ai consacré un article entier à ce sujet avec des exemples concrets : les bonnes pratiques d'onboarding pour app mobile.

Feedback et micro-interactions : l'UX invisible qui fait tout

Le feedback visuel est ce qui donne à un produit sa sensation de qualité. Un bouton qui ne réagit pas quand on tape dessus, un chargement sans indicateur, une action réussie sans confirmation, ce sont des petits silences qui accumulent de l'inconfort.

Les micro-interactions remplissent trois rôles : confirmer qu'une action a été prise en compte, indiquer l'état du système, guider vers l'étape suivante. Elles n'ont pas besoin d'être spectaculaires. Souvent, les meilleures micro-interactions sont celles qu'on ne remarque pas consciemment mais dont l'absence se ferait sentir immédiatement.

Concrètement sur mobile : chaque tap sur un élément interactif doit produire un retour immédiat, haptic si possible, visuel a minima. Les transitions entre écrans doivent être cohérentes avec la direction de navigation (avancer vers la droite, reculer vers la gauche sur iOS). Les états vides (liste vide, premier lancement) doivent être traités avec soin : c'est souvent là que les utilisateurs décrochent parce qu'ils ne savent pas quoi faire.

Les animations doivent être rapides. Sur mobile, 200 à 300 millisecondes est la fenêtre idéale pour une transition. Au-delà, l'utilisateur perçoit une lenteur. En dessous, il peut manquer le feedback. Tester sur un vrai appareil, pas seulement en simulateur, reste indispensable.

Tester, itérer, mesurer : l'UX ne se valide pas dans Figma

Un design peut sembler parfait en maquette et dysfonctionner en usage réel. Les tests utilisateurs ne sont pas réservés aux grandes équipes produit. Même seul, même sans budget, tu peux obtenir des insights exploitables en observant cinq personnes utiliser ton app pour la première fois.

Le principe du test d'utilisabilité minimal : donne une tâche précise à réaliser, sans guidage ni explication. Observe sans intervenir. Note chaque hésitation, chaque retour en arrière, chaque moment où la personne cherche quelque chose des yeux. Ces moments-là sont tes vraies données. Pas les opinions, pas les suggestions de features : les frictions observables.

Pour mesurer, les métriques UX qui comptent vraiment en contexte mobile : le taux de complétion de l'onboarding, le temps avant la première action significative, le taux de rétention à J1 et J7, le nombre de sessions par utilisateur actif. Ces chiffres traduisent l'expérience en signal mesurable. Un taux de rétention à J7 faible est souvent un problème d'onboarding ou de valeur perçue trop lente. Un nombre de sessions élevé mais un taux de conversion faible pointe vers un problème de parcours vers le paiement.

Sur la rétention, j'ai détaillé les leviers spécifiques aux apps et SaaS dans ce guide complet sur la rétention mobile.

L'itération doit être courte et documentée. Changer deux choses en même temps sur un écran rend l'analyse impossible. Change une variable, mesure, tire les conclusions, passe à la suivante. C'est lent en apparence, c'est en réalité le chemin le plus rapide vers un produit qui fonctionne.

Ce que construire Sunna Planner m'a appris sur l'UX

Quand j'ai commencé à développer Sunna Planner, je n'avais pas de spec UX. J'avais un besoin personnel très précis : un outil qui comprend que la discipline musulmane, la prière, les invocations, la lecture du Coran, et l'ambition professionnelle ne sont pas deux vies séparées. Aucune app existante ne tenait les deux bouts.

La première version était fonctionnelle mais imparfaite sur l'UX. L'onboarding était trop statique. La features 'salons' (des groupes de discussion), qui semblaient logiques sur le papier, étaient difficiles à animer et ajoutaient de la complexité sans valeur perçue claire. Je les ai supprimés dans la v2 sans hésitation.

Ce que j'ai appris concrètement : les fonctionnalités les plus utilisées ne sont pas toujours celles qu'on met en avant. Le mode Focus avec le timer Pomodoro et les ambiances sonores, l'Amazonie, l'océan, le café, est une des features les plus appréciées alors qu'elle prend peu de place dans le marketing. L'architecture des catégories de tâches (Religion, Lifestyle, Apprendre, Work, Routines) a mis plusieurs itérations avant de sembler naturelle. La première version était trop granulaire, les utilisateurs ne savaient pas où classer leurs tâches.

L'autre leçon majeure : tester sur de vrais appareils change tout. Ce qui semble aéré sur Figma peut sembler surchargé sur un écran de Samsung A50 ou iPhone 16. La taille des zones de tap, la lisibilité des textes en conditions de lumière variable, les transitions Flutter en conditions réseau réelles, tout ça ne se voit qu'en usage. Les simulateurs sont utiles mais il ne remplace pas un iPhone dans la main d'un utilisateur qui n'a pas lu ta doc.

Pour ceux qui construisent un produit mobile, j'ai aussi écrit sur ce que construire une app m'a appris sur le design, avec d'autres retours d'expérience directs.

FAQ

Par où commencer quand on refond l'UX d'une app existante ?

Commence par les données avant de toucher au design. Analyse les écrans avec les taux d'abandon les plus élevés, identifie les points de friction via des sessions d'observation ou des enregistrements d'écran (Hotjar, UXCam), puis priorise les corrections par impact potentiel sur la rétention ou la conversion. Refondre sans données, c'est souvent remplacer un problème par un autre.

Quelle est la différence entre UI et UX en pratique ?

L'UI, c'est ce que l'utilisateur voit : couleurs, typographie, composants visuels. L'UX, c'est ce que l'utilisateur ressent et accomplit : fluidité du parcours, logique de navigation, sentiment de contrôle. Une app peut être visuellement soignée et avoir une UX catastrophique. L'inverse existe aussi. Les deux comptent, mais l'UX détermine si l'utilisateur revient, l'UI détermine s'il fait confiance au produit au premier regard.

Faut-il faire des tests utilisateurs avant de lancer ou après ?

Les deux, avec des objectifs différents. Avant le lancement, les tests identifient les blocages majeurs avant qu'ils coûtent des utilisateurs réels. Après le lancement, les données comportementales et les observations en conditions réelles révèlent des frictions impossibles à simuler en amont. Le test utilisateur pré-lancement sur prototype reste indispensable même minimal, cinq personnes suffisent à identifier 80 % des problèmes critiques.