14. Philosophie Lean
• Processus de découverte
• Ce que veulent les clients n’est pas
forcément ce qu’on a imaginé
• Il faut pouvoir lâcher prise
• Une définition intéressante ici
• Une vidéo <3mns ici
17. Release early
• Se confronter au plus tôt :
Aux utilisateurs
Aux problèmes
Aux risques
• Rationaliser, prouver, confronter attention aux intuitions !
22. Lean, Agile, Design Thinking…
Un point commun :
l’équipe pluri-disciplinaire
/ la collaboration d’experts de métiers différents
23. Lean, Agile, Design Thinking…
Un point commun :
l’équipe pluri-disciplinaire
/ la collaboration d’experts de métiers différents
=> Inclure les développeurs !
43. Design for interruption
• Attention partielle
• Prévoir les interruptions
=> sauvegarder les états
• Prévoir le retour à l’application
44. Design for interruption
• Attention partielle
• Prévoir les interruptions
=> sauvegarder les états
• Prévoir le retour à l’application
• Et n’interrompez pas trop non plus !
(notifs)
69. Réseaux mobiles
• A considérer : différencier le comportement
de l’appli en fonction du réseau
• Ex. pour une appli de réseau social :
Wifi : pré-caching des contacts et images de contacts
en tâche de fond, données en https car peu sécurisé
3G : fonctionnement standard, pas de https (trop lourd)
2G / Edge : fonctionnement dégradé, pas de
chargement des images
70. Caching de contenu
• Certains contenus sont accessibles en
offline (caching ou synchronisation)
• On peut utiliser ces contenus
immédiatement
• L’application démarre en offline puis elle
se connecte dans un 2nd temps
• Ex. : Deezer, Pocket, Viadeo, …
71. Actions instantanées
et offline
• L’action est ‘enregistrée’ immédiatement
• La requête est envoyée à la prochaine
connexion
• Exemples dans Pocket et Mail : envoi,
tags, marquage lu, …
• On peut agir même sans réseau !
77. Compression
•
•
•
A considérer : lors de la requête
pour une liste, charger les
données des éléments
Grâce à la compression, ça ne
coûte pas trop cher côté réseau
Mais impact côté serveur
78. Vitesse perçue
A minima, améliorer la
perception de l’utilisateur :
• Chargement d’un minimum
de données en amont
• Actions possibles
79. Vitesse perçue
A minima, améliorer la
perception de l’utilisateur :
• Chargement d’un minimum
de données en amont
• Actions possibles
• Chargement de données
secondaires
87. Customer development /
customer communication
• Vital sur mobile
• Commentaires app stores = la jungle
• Communication directe / support
• Learn
88. Trend: InApp feedback
• Eviter les commentaires négatifs sur les app
stores
• Récupérer retours et suggestions, le tout
avec le contact de l’utilisateur pour
investigations
• Des infos, des utilisateurs contents
=> Learn et early adopters
125. Vouloir (trop) innover sur
l’UI/UX
• Risqué, demande de l’expertise, coûteux !
• Se concentrer sur le cœur de métier pour
la différentiation
• Contre exemples / besoins de
différentiation : Flipboard, Fantastical,
Mailbox, Any.do, Path, …
126. Ne pas réinventer
la roue
• Apple, Google, MS… ont investi des
millions dans l’UI/UX des OS
• Utilisez les guidelines / composants de
base au maximum
• Vos utilisateurs s’y retrouveront
• Validation et potentielle mises en avant
140. Etapes
• Mobile Ready : Web services / APIs !
• Démarche produit
• Prototype fonctionnel
• Alpha / Beta
141. Démarche produit
• Regarder ce que font les autres
(compétiteurs, apps similaires, autres
domaines, …)
• Reviews sur les apps stores
• Interviews utilisateurs et autres outils Lean
• Conception : use cases, fonctionnalités,
UX/UI, …
142. Personas
• Personnages fictifs qui ont des vrais
problèmes
• Issus du monde réel (interviews, data, …)
• Prisme pour penser à d’autres utilisateurs
qu’à soi-même
• Outil de conception et de marketing (mesure,
segmentation, ciblage / message)
144. Répondre au 3 principaux
use cases
• Les problèmes que votre service résout /
points de friction résolus via mobile
• Rechercher ces cas en situation de mobilité /
pas forcément les mêmes que sur le web
• Ex. Mobile comme compagnon du service
(validation, alertes, …)
145. Répondre au 3 principaux
use cases
• Les problèmes que votre service résout /
points de friction résolus via mobile
• Rechercher ces cas en situation de mobilité /
pas forcément les mêmes que sur le web
• Ex. Mobile comme compagnon du service
(validation, alertes, …)
=> Fonctionnalités
148. Ordre de conception
• Cas d’usages prioritaires
• Cas d’usages secondaires
• Choix de navigation
(home, topbar, menu, …)
149. Ordre de conception
• Cas d’usages prioritaires
• Cas d’usages secondaires
• Choix de navigation
(home, topbar, menu, …)
150. Ordre de conception
• Cas d’usages prioritaires
• Cas d’usages secondaires
• Choix de navigation
(home, topbar, menu, …)
• Patterns des sous-écrans
• Ecrans des contenus
156. Design Studio
• Conception en team (pluri-disciplinaire)
• Extraire les bonnes idées
• Sketching
Design Studio : tellement UX … tellement
créatif … tellement agile !
157. Itérer sur l’UI
• Commencer avec une UI simple
• Evoluer au fur et à mesure
• Se garder de vouloir obtenir tout de suite
une UI « trendy » comme celles des apps
phares que vous utilisez
158. Animations et effets ‘Wow!’
• Plus tard
• Ca ne fait pas le produit
• Tjrs plus impactant que prévu niveau charge
(réglages, allers / retours, …)
• Vous avez mieux à faire de votre temps / argent