Le 30 mai, on arrive à la fin de la deuxième semaine de formation et j’en suis à la 3eme journée de la formation en Mobile Design. J’ai étudié et suivi le cours mais étant donné que mes lunettes ont cassé, j’ai du aller en priorité les faire réparer…

Les lunettes réparés, j’ai tout de même décidé de stopper à la mi-journée ce qui a fait que seule la partie théorique a été faite aujourd’hui. J’avais également décidé de prendre une demain journée de congé donc cette journée sera relativement courte. Je vais essayer de continuer le prototype que j’ai commencé hier avec les notions apprises aujourd’hui.

# Apprentissages du jour

## Login et Page d’enregistrement

### Informations demandées

• Limiter les questions aux informations les plus pertinentes lors de l’enregistrement
• Laisser les utilisateurs utiliser l’application avant de leur demander de se loguer ou s’enregistrer - cela augmente l’engagement car ils comprennent la valeur de l’application
• Si des informations supplémentaires sont nécessaires dans le futur, utiliser des informations par défaut intelligentes

### Labels et champs de texte

• Aligner toujours le label au-dessus du champ de texte d’entrée
• Garder le label visible et clair
• Ne pas utiliser les placeholders comme labels car ils disparaissent quand l’utilisateur clique dans le champ, augmentant la charge cognitive

### Solutions de connexion alternatives

• Privilégier plusieurs façons de se loguer (réseaux sociaux, etc.)
• Avantages : moins d’interactions pour l’utilisateur et pas besoin de mécanismes de vérification d’email
• Ajouter une checkbox “se rappeler de l’email” pour réduire les interactions futures
• Préférer les adresses emails ou numéros de téléphone plutôt que les usernames (plus faciles à retenir)

### Mot de passe oublié

• Mettre le maximum d’informations directement sur la page de reset
  • L’utilisateur est généralement en période de stress, donc plus il a d’informations à disposition, mieux il pourra réagir

### Validation inline

• Avoir une validation directe quand l’utilisateur introduit les champs
  • Utiliser des couleurs appropriées : vert pour les informations valides, rouge pour les erreurs
  • Messages d’erreur explicites et clairs pour éviter que l’utilisateur ait à réfléchir
• Éviter la fatigue supplémentaire en validant au fur et à mesure plutôt qu’à la soumission

### Navigation entre pages

• Aider l’utilisateur à naviguer entre les pages de login et d’enregistrement
  • Mettre des titres clairs indiquant sur quelle page il se trouve
  • Ajouter des liens directs pour passer d’une page à l’autre en cas d’erreur

## Onboarding

### Principe général

• Le meilleur onboarding est celui qui n’existe pas
• Plus l’onboarding est long, plus l’utilisateur a de chances d’être perdu dans le processus
• Toujours considérer si l’onboarding est vraiment nécessaire
  • Cas où l’onboarding est nécessaire
    • L’application est complexe
    • Les informations utilisateur sont nécessaires au bon fonctionnement (ex: application bancaire)
    • L’utilisateur doit utiliser l’application dans un contexte spécifique (ex: app de sport)
    • Lors de l’introduction d’une nouvelle fonctionnalité
    • Quand l’utilisation nécessite un flux de travail spécifique auquel les utilisateurs ne sont pas habitués
• Test utilisateur - Si on ne sait pas si l’onboarding est nécessaire, faire tester des utilisateurs - S’ils ont du mal à comprendre l’application, alors l’onboarding peut être pertinent

### Onboarding de nouvelles fonctionnalités

• Aide contextuelle : dialogue à côté d’un nouveau menu expliquant sa disponibilité
• Information directe sur la page de l’App Store

### Demande d’informations

• Bien expliquer à l’utilisateur pourquoi on a besoin des informations
• Technique : s’expliquer à soi-même pourquoi on veut ces informations - si on n’y arrive pas, elles ne sont peut-être pas nécessaires

### À éviter dans l’onboarding

• Ne pas proposer la personnalisation du thème - les études montrent que la plupart des utilisateurs restent avec les thèmes par défaut

### Instructions et fonctionnalités uniques

• Ajouter des instructions seulement quand les nouvelles fonctionnalités sont uniques ou peu familières
  • Exemples : Tinder, Google avec le swipe pour passer au résultat suivant

## Pages d’information sur les permissions

### Principe

• Mettre en place des pages explicatives avant la demande effective de permission
  • Les utilisateurs ont tendance à cliquer directement sur les popups pour les faire disparaître
  • Si on explique bien pourquoi on a besoin de la permission, l’utilisateur sera plus attentif à la notification suivante

### Efficacité

• Particulièrement efficaces lors de l’onboarding
• Efficaces quand elles sont contextuelles (ex: demander accès au répertoire au moment d’ajouter un fichier)
• Toujours expliquer clairement pourquoi on en a besoin (nécessaire également pour la validation App Store)

## Gestion des espaces vides

• Utiliser les espaces vides intelligement:
  • Opportunité supplémentaire d’onboarding utilisateur
  • Peuvent servir pour ajouter un call-to-action
  • Peuvent construire la personnalité de la marque

## États de succès

• Important d’utiliser les états de succès car ils apportent un sentiment positif
  • Les montrer le plus rapidement possible augmente la rétention
    • Exemples : confirmation avec un flag vert, informer que l’utilisateur a bientôt fini l’onboarding, encouragements (“votre site a été créé”)

## Front Load Value

• Technique qui consiste à montrer les bénéfices de l’application le plus rapidement possible
  • Exemple Duolingo : à la fin de l’onboarding, montrer du texte traduit pour démontrer les bénéfices
• Mettre le login plus tard dans le processus d’onboarding après que l’utilisateur ait utilisé l’application (engagement graduel)

## Call-to-Action final

• Toujours introduire un CTA à la fin de la procédure d’onboarding
  • Le CTA doit refléter le bénéfice que l’utilisateur va avoir
  • Exemples : “Commencer à acheter” pour une app e-commerce, “Commencer à apprendre” pour Duolingo

## Navigation dans l’application

### Principe général

• La navigation est une des choses les plus importantes dans une application. Elle permet de s’assurer qu’on dirige l’utilisateur avec le moins d’effort possible

### Navigation en haut d’écran

• Plus pertinente quand l’utilisateur a besoin d’un accès constant à l’action principale

### Navigation en bas d’écran

• Barre de navigation (Android) et barre de Tab (iOS) :
  • Permettent d’avoir accès facilement à 3-5 destinations principales
• Bottom bar (spécifique Android - Material Design) :
  • Permet d’accès à 4 actions maximum pertinentes dans le contexte
  • Inclut un bouton flottant

### Tabs

• Différence entre Android et iOS : sur iOS, les tabs sont des segment controls avec utilisation équivalente

### Menu hamburger

• Beaucoup utilisé pour les applications avec beaucoup de contenu
  • Permet de cacher une partie de la navigation
  • Désavantage : les fonctionnalités cachées peuvent être moins utilisées

### Cartes

• Éléments qui permettent d’afficher des informations non hiérarchisées
• Se composent généralement d’un fond, une image et quelques containers pour les informations

### Navigation par gestes

• Important de mettre des indices visuels
• Mettre en place des alternatives
• Garder les gestes consistants dans l’application

### Fonctionnalités spécifiques OS

• 3D Touch iOS qui permet d’afficher des informations différentes selon l’appui sur un bouton

## Considérations d’accessibilité

• Respecter les 10mm entre chaque touche pour les personnes ayant des problèmes moteurs
• Avoir suffisamment de contraste pour que les éléments se voient
• Garder à l’esprit les différents types de physionomie en mettant à disposition facilement les actions principales à l’écran

## Placement de la navigation selon le type d’application

## Applications axées sur le contenu

• Bénéficient d’une approche minimaliste (ex: menus hamburger)

## Applications orientées tâches

• Nécessitent une navigation beaucoup plus visible et ancrée dans l’application
• Accessibilité directe aux actions principales

## Notifications mobiles et dialogues

### Dialogues modaux

• Utiliser pour donner des informations importantes à l’utilisateur
  • Interrompent le workflow de l’utilisateur
  • Réserver pour les actions essentielles
  • Utiliser pertinemment (ex: seulement pour du contenu intéressant comme une promotion)
• Éviter d’être intrusif (pas 3-4 dialogues modaux à la suite)
• Fournir des possibilités de fermer le modal

### Dialogues non-modaux

• Préférer pour communiquer des informations non critiques ou non pertinentes au workflow actuel

### Attention aux fermetures rapides

• L’utilisateur va avoir tendance à fermer le dialogue le plus rapidement possible
• Si il y a des informations importantes, s’assurer que l’utilisateur ne les rate pas

### Labels des boutons

• Avoir des labels explicites et compréhensibles
• Ne pas utiliser “oui”, “non”, “annuler”, “soumettre”, “confirmer” si ce n’est pas pertinent dans le contexte
  • Technique : se demander quelle sera l’action directement après que l’utilisateur ait cliqué
  • Exemple : si une photo va être supprimée, les boutons seront “Supprimer” et “Annuler”

## Notifications push

### Lisibilité rapide

• Créer des notifications scannables rapidement d’un coup d’œil
  • Se limiter à 30-40 caractères
  • Éviter de répéter le nom de la marque (l’icône le montre déjà)
  • Avoir un langage clair et direct

### Personnalisation

• Important pour augmenter la rétention utilisateur
  • Exemple : au lieu de “Des nouveaux exercices sont disponibles”, dire “Cat, des nouveaux exercices sont disponibles. Viens voir dans l’application”

## Page de paramètres

### Principe général

• Souvent négligée mais importante à bien structurer
• Permettre à l’utilisateur de retrouver facilement les informations ou changer des paramètres quand il en a besoin

### Organisation

• Grouper les options logiquement
• Établir une hiérarchie visuelle (options visibles mais pas surchargées)
• Utiliser un langage simple pour nommer les options
• Ajouter une petite description sous le label si l’option est complexe

### Séparation des options

• Options basiques : directement visibles sur la page de paramètres
• Options avancées : cachées pour la plupart des utilisateurs, utilisées par un public expert

### Paramètres par défaut

• Réfléchir à des paramètres standard qui conviennent à la plupart des utilisateurs afin d’éviter que les utilisateurs aient besoin d’aller dans les paramètres

### Facilitation de la navigation

• Si l’utilisateur doit scroller une ou deux fois, ajouter une barre de recherche
• Mettre en place des mécanismes de suggestions pour éviter un coût d’interaction important

### Hiérarchisation

• Options les plus importantes et essentielles : au début de la liste
• Actions destructives : tout en bas (ex: supprimer le compte, nettoyer le cache)

# Réflexion personnelle sur la méthode de prise de notes

• Test d’une nouvelle façon d’écrire : utilisation du mode dictée sur laptop avec Obsidian
  • Avantage constaté : meilleure rétention car certaines choses dites oralement ne sont pas dans les notes écrites
  • Impression de mieux retenir et d’avoir plus discuté avec soi-même sur les notions

A bientôt. Alessandro.