Révolution Mobile :
Le mobile a révolutionné nos vies, au point d'être devenu une extension de notre cerveau. Qu'est ce qui rend le mobile si révolutionnaire ?
Où en sommes-nous dans cette révolution mobile ?
Dans une seconde partie, quelques recommandations pour réussir vos produits mobiles.
Voir http://bit.ly/revomobile (lien vers la video de la conférence, etc...)
73. Pouvoir Version
Transmission de pensée 1.0
Omniscience 0.8
Télékinésie 0.3
Maîtrise du temps 0.3
Prévoir l’avenir 0.1
Etre invincible / guérir 0.3
Lancer des éclairs 0
Voler 0.5
Téléportation 0.2
74. Pouvoir Version Mobile powered
Transmission de pensée 1.0
Omniscience 0.8
Télékinésie 0.3
Maîtrise du temps 0.3
Prévoir l’avenir 0.1
Etre invincible / guérir 0.3
Lancer des éclairs 0
Voler 0.5
Téléportation 0.2
75. Pouvoir Version Mobile powered
Transmission de pensée 1.0
Omniscience 0.8
Télékinésie 0.3
Maîtrise du temps 0.3
Prévoir l’avenir 0.1
Etre invincible / guérir 0.3
Lancer des éclairs 0
Voler 0.5
Téléportation 0.2
Conscience / intelligence collective 2.0
+ 3D printing
126. InApp feedback
Un mécanisme vertueux pour le produit et
pour le marketing :
Favoriser les bonnes notes
Eviter les avis négatifs
Transformer les utilisateurs mécontents
en satisfaits + bonnes notes
Récupérer retours et suggestions, avec le
contact de l’utilisateur
126
130. 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, …
131. 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
136. Ne pas réinventer
la roue
• Apple, Google, MS… ont investi des
millions dans l’UI/UX des OS
• Utilisez au maximum les composants de
base / guidelines de l’OS
• Vos utilisateurs s’y retrouveront
140. Inclure les développeurs
dans la conception !
• Ils ont une connaissance approfondie des
plateformes
• Ils trouvent des raccourcis techniques
• Souvent sensibles au produit / utilisateurs
• En phase avec Lean et agilité
141. Agile
• SCRUM, Kanban, eXtreme Programming…
• Processus itératif
• Favoriser la communication orale
• Des pratiques et des outils pas trop
embêtants, que l’équipe choisit d’utiliser
143. Conception itérative
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
143
144. Conception itérative
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
Développements
Conception
2 weeks
144
145. Conception itérative
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
Développements
Conception
Réus conception / UX
incluant les dévelopeurs
145
146. Conception itérative
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
Développements
Conception
Réus conception / UX
incluant les dévelopeurs
146
147. Conception itérative
Sprint 1
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
Développements
Conception
Réus conception / UX
incluant les dévelopeurs
147
148. Conception itérative
Sprint 1 Sprint 2
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
Développements
Conception
Réus conception / UX
incluant les dévelopeurs
148
149. Conception itérative
Sprint 1 Sprint 2 Sprint 3
• La conception est en avance de phase sur les développements
• Mais les sprints débutent avant la fin de la conception
Développements
Conception
Réus conception / UX
incluant les dévelopeurs
149
150. Brise glace : principe
• En cas de développement
multi-plateforme (iOS, Android,
Webapp, …)
• On ne lance pas les devs en
parallèle
• On utilise une des plateformes
comme fer de lance
151. Brise glace : avantages
• Les apprentissages d’un projet servent aux
autres projets :
Choix produit
Choix techniques
Méthodos / amélioration continue
• Surtout utile pour les réglages de l’API
• Paralléliser, il faut le faire intelligemment
152. Mobile 1st
• Méthode de conception avant tout
• On conçoit pour mobile (+contraint), puis
on enrichit pour desktop et tablette
• Oblige à se concentrer sur l’essentiel
• Souvent lié au Responsive Design
158. Design for interruption
• Attention partielle
• Prévoir les interruptions
=> sauvegarder les états
• Prévoir le retour à l’application
159. 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)
160. Design for speed
• Caching de contenus
• Actions instantanées et offline
• Amélioration de la vitesse perçue
• Adaptation au réseau
• Réduction de latence, grouping et
compression
161. 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, …
162. 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 !
163. Adaptation au réseau
• 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
169. 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
170. Vitesse perçue
A minima, améliorer la
perception de l’utilisateur :
• Chargement d’un minimum
de données en amont
• Actions possibles
171. 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