28 Mai 2025 - Mobile Design - Template Projet Portfolio
Nouvelle formation sur le Mobile Design sur Uxcel.com
#
Gestion de projet
En plus de ma formation, j’ai créé un tableau Kanban répertoriant les différents points à prendre en compte lors de la gestion de projet pour les futures applications de mon portfolio. L’objectif est d’avoir un plan à suivre dès le début afin de pouvoir livrer une application en 80 heures (4 semaines de 20 heures).
Voici la liste des actions que j’ai identifiées avec l’aide de Gemini. Elle n’est sans doute pas parfaite ou peut-être trop complète, mais le but est d’avoir une structure de travail et de minimiser la charge mentale. Elle évoluera probablement dans le futur ; j’ai prévu un point d’évaluation en fin de projet afin de corriger les défauts.
##
Planning
Semaine | Action | Heures |
---|---|---|
1 | Définir le besoin principal de l’application | 2 |
1 | Rédiger les User Stories clés (MVP) | 3 |
1 | Identifier le MVP (Minimum Viable Product) | 3 |
1 | Esquisser les wireframes basiques (écrans principaux) | 4 |
1 | Dessiner le flux utilisateur simple | 2 |
1 | Confirmer la technologie de développement | 1 |
1 | Lister les technologies/librairies nécessaires | 2 |
1 | Établir le plan détaillé des tâches pour la semaine 2 | 3 |
2 | Initialiser le projet mobile (dépôt Git, structure de base) | 3 |
2 | Implémenter les fonctionnalités du MVP (développement clé) | 10 |
2 | Mettre en place la logique de gestion des données (locale/basique) | 4 |
2 | Effectuer les premiers tests manuels sur l’appareil | 2 |
2 | Corriger les bugs critiques découverts | 1 |
3 | Appliquer une charte graphique simple (couleurs, polices, icônes) | 5 |
3 | Ajouter des animations subtiles pour l’UX | 3 |
3 | Implémenter la gestion des erreurs utilisateur (messages clairs) | 3 |
3 | Gérer les cas limites (pas de connexion, données invalides) | 3 |
3 | Effectuer une optimisation des performances basique | 2 |
3 | Intégrer des services tiers légers | 2 |
3 | Nettoyer le code (supprimer commentaires inutiles, fichiers temporaires) | 1 |
3 | Rédiger la documentation technique interne | 1 |
4 | Mener des tests utilisateur “simulés” | 4 |
4 | Effectuer une revue de code finale | 3 |
4 | Corriger les derniers bugs critiques | 2 |
4 | Finaliser et sélectionner les screenshots de haute qualité | 3 |
4 | Enregistrer et monter une vidéo de démonstration courte et efficace | 3 |
4 | Rédiger la description de l’application pour le portfolio | 2 |
4 | Organiser le dépôt Git (README clair) | 1 |
4 | Créer la page de projet sur le portfolio | 1 |
4 | Réaliser une rétrospective personnelle (leçons apprises) | 1 |
#
Apprentissages du jour
##
Notes en vrac
###
Orientation portrait/paysage
Forcer un utilisateur à changer d’orientation pour accéder à des fonctionnalités de base est une mauvaise décision de design.
###
Règle d’or
Adopter une approche mobile first lors du design.
###
Responsive vs Adaptatif
Responsive :
- Adapte la taille des composants de la page à la taille du viewport (fluid sizing)
- Particulièrement efficace pour des sites orientés contenu
- SEO friendly
- Adapté pour des expériences mobiles
- Moins coûteux à l’implémentation
- Plus lourd au chargement des composants (des techniques de lazy loading peuvent aider au niveau des performances)
Adaptatif :
- S’adapte également à la taille de l’écran mais sur la base de designs statiques créés en amont. La bonne taille se charge alors selon l’écran
- Adapté pour des interfaces orientées dashboard ou fortement chargées en données
- Plus coûteux car il faut dessiner plusieurs fois les interfaces selon les tailles identifiées
- Plus rapide à charger à l’écran car il ne charge que les composants de l’interface
##
Native Mobile Design
###
Guidelines
- HIG pour Apple
- Material Design Guidelines pour Android
###
Gestion des états
Privilégier des informations aux différents états (exemple : un message mentionnant à l’utilisateur que nous sommes hors ligne au lieu d’un spinner).
###
Navigation
- Tabs en bas de l’écran pour iOS
- Hamburger menu | search bar | floating buttons pour Android
###
Menu d’actions
On utilise souvent un appui long avec un fond opaque.
###
Boutons de retour
- Chevron vers l’arrière en haut à gauche pour iOS
- Les modales se ferment avec des gestes sur iOS
###
Icônes
Le plus important est de réduire la fatigue visuelle qui peut faire décrocher l’utilisateur dans son workflow. Choisir des icônes connues et souvent utilisées. Si elles sont bien utilisées, elles suppriment les barrières linguistiques (exemple : une maison pour la page d’accueil).
###
Notifications push
Elles doivent être envoyées au bon moment. Si elles sont envoyées la nuit, elles auront tendance à être supprimées au réveil. Pire, avec la fatigue liée aux notifications, l’utilisateur désactivera probablement ces notifications.
À tenir en compte lors de l’envoi de notifications :
- Doivent promouvoir quelque chose (nouveau contenu, promotion, etc.)
- Éviter le langage marketing
- Utiliser la localisation de l’utilisateur
- Ne pas spammer l’utilisateur
- Comme mentionné plus haut, un message à 11h du matin sera sans doute plus efficace que le même message à 3h du matin
###
Notifications dans l’application
Notifier l’utilisateur de manière pertinente :
- Modal dans le cas où l’utilisateur doit absolument intervenir dans son workflow
- Faire attention à bien placer les boutons d’action afin que l’utilisateur puisse les utiliser d’une seule main
- Snackbar pour les informations non critiques
###
Splash Screen
Privilégier des images et très peu de texte.
###
Accordéon
L’accordéon est très pratique pour condenser les informations et masquer ce qui n’est pas nécessaire sur mobile, mais il faut faire attention au comportement pour l’utilisateur.
Exemple : Si un utilisateur ouvre un accordéon, il faut veiller à ce qu’il ne croie pas que c’est une nouvelle page, sinon il serait tenté de cliquer sur le bouton pour revenir en arrière. La solution serait de mapper le retour en arrière à la fermeture de l’accordéon.
###
Cards
Servent à montrer des informations de manière non hiérarchisée avec un focus sur les plus pertinentes en haut de l’écran.
Bonnes pratiques :
- Informations principales du produit afin de maximiser la conversion
- Des images nettes et de qualité
- Les détails secondaires seront plutôt des éléments de bénéfices ou de fonctionnalités
###
Carrousel
Attention à bien effectuer la distinction du carrousel des autres composants du design :
- Afficher une partie du carrousel non visible
- Ajouter des icônes si besoin
###
SnackBar
Restent en moyenne entre 4 et 10 secondes.
##
Comment réduire l’abandon de son application
Implémenter les techniques suivantes avec parcimonie :
- Utiliser l’onboarding
- Messages dans l’application mentionnant de nouvelles fonctionnalités
- Notifications push