fabernovel loader

Oct 25, 2018 | 8 min de lecture

Tech

Concevoir pour le mobile

Marine Pichard

Head of Design


FABERNOVEL TECHNOLOGIES
Une application mobile est toujours à portée de main, compagnon de poche en mobilité. Concevoir pour le mobile, c’est accompagner les utilisateurs dans leur quotidien. Créer une application est bien plus complexe qu’il n’y paraît. Lorsqu’il s’agit de concevoir une application mobile, de nombreuses questions se posent sur des aspects fonctionnels, graphiques et ergonomiques, mais aussi à propos de la faisabilité technique, des délais de réalisation, la maintenabilité du code, la publication sur les stores et bien sûr la satisfaction des utilisateurs et retombées économiques.

Avant de démarrer un nouveau projet, nous nous assurons que réaliser une application a du sens dans la stratégie de notre client : est-ce le support le plus adapté ? Que faut-il y proposer ? Comment se positionne-t-elle par rapport aux autres canaux ?

Prenons l’exemple suivant : un gérant détient plusieurs salles de sport. Pour en faire la promotion, il dispose déjà d’un site internet vitrine qui expose les tarifs, adresses et horaires des salles, des informations sur le matériel et sur les cours collectifs existants.

Le gérant souhaite offrir un service supplémentaire à ses adhérents : un programme sportif personnalisé.

 

L’utilisateur au centre de la conception

Lors des phases de conception, il faut bien garder en tête que nous réalisons un produit pour un utilisateur bien précis – ici, les adhérents de la salle de sport. Nous ne devons pas lui imposer nos choix de concepteur, mais à l’inverse nous devons l’écouter et adapter notre application pour qu’elle réponde parfaitement à ses besoins ; sans quoi elle ne sera simplement pas utilisée.

Pour connaître nos utilisateurs, nous nous servons de l’un de ces trois procédés :

  • Questionner un expert du domaine, le client ; en se tournant vers le gérant de la salle dans cet exemple
  • Observer les utilisateurs dans leur environnement naturel ; en se rendant dans l’une des salles de sport et découvrir les habitudes et comportements des adhérents
  • Interviewer les utilisateurs ; en échangeant avec les adhérents sous forme d’un dialogue ou d’un questionnaire afin de récolter leurs avis et leurs attentes

En récoltant ces informations, nous pouvons lister des besoins à combler, identifier la proposition de valeur et définir une ou plusieurs problématiques à laquelle l’application mobile viendra répondre.

Voici un exemple de problématique :

Comment pourrions-nous aider nos adhérents à atteindre leurs objectifs ? (Prise de masse, perte de poids, etc…)

À cette question, nous proposons de multiples réponses que nous trions et priorisons en fonction de la faisabilité (cette fonctionnalité est-elle facile à implémenter techniquement ? avons-nous les ressources ?) et de la désirabilité (cette fonctionnalité est-elle vraiment nécessaire dans l’application ? en quoi cela aide-t-il l’utilisateur ? pourrait-il s’en passer ?).

Priorisation des fonctionnalités par faisabilité / désirabilité

Après cette étape, nous sommes en mesure d’ordonner chaque fonctionnalité dans des catégories. C’est là que se dessinent les grandes sections de l’application. La fonctionnalité “voir les exercices à réaliser dans la semaine” pourrait ainsi se retrouver dans une catégorie “mon programme” par exemple.

Nous commençons dès lors à rédiger les spécifications fonctionnelles.

Dès cette étape atteinte, de nombreux clients peuvent tenter de précipiter les processus pour voir à quoi va ressembler leur application. Cet enthousiasme se comprend, mais il reste encore quelques pas à suivre avant de dessiner les écrans. A présent, il faut passer à la rédaction des principaux parcours utilisateurs. Cette rédaction nous aide à visualiser les différentes étapes de leurs parcours pour atteindre leurs objectifs. Pour nous aider à les rédiger, on complète la phrase suivante : “ Je suis ___ et je souhaite ___”.

Voici un exemple d’objectif :

Je suis adhérent(e) et je souhaite créer mon parcours d’entraînement personnalisé.

Et voici un exemple de parcours utilisateurs qui répond à l’objectif :

Parcours utilisateurs

L’arborescence vient accompagner ces parcours utilisateurs. Elle structure et hiérarchise les grandes sections de l’application ; c’est une sorte d’organigramme de la navigation qui illustre les liens entre les différentes sections.

Nous sommes maintenant bien préparés pour commencer à traduire toute cette réflexion UX en interfaces. Nous commençons à dessiner les wireframes “quick and dirty” sur papier pour valider rapidement les choix de navigation et vérifier que rien n’est oublié. Heureusement, il est rapide et facile de prototyper sur mobile. En effet, des applications comme Pop ou Marvel permettent directement, depuis un smartphone, de prendre en photo les écrans dessinés, en déterminant des zones cliquables et de les lier avec les différents écrans de destination. Nous pouvons ainsi naviguer dans notre application sans avoir écrit une ligne de code.

Prototypage rapide avec Pop

Il est temps de donner vie à tous ces écrans, grâce au logiciel de création d’interface (Sketch ou Figma). Il faut être particulièrement vigilant à se référer à la charte graphique du client, en utilisant au maximum les composants natifs que proposent les différentes plateformes (iOS pour Apple, Android pour Google).

Nous pouvons maintenant nous rendre dans une salle de sport et faire des tests utilisateurs avec les sportifs ; nous itérons en prenant en compte leurs retours afin de leur proposer un produit adapté qui répond parfaitement à leurs besoins.

Les spécificités du mobile

Des contraintes et des possibilités uniques

Réaliser une application mobile, c’est prendre en compte des contraintes particulières qui peuvent aussi se révéler être des opportunités. L’écran est petit, mais transportable. La connectivité varie, mais elle est disponible presque partout. Et que dire des interactions multitouch… Le mobile est toujours utilisé dans un environnement qui doit être pris en compte : peu ou pas de réseau, en mobilité, les mains prises, dans son canapé, accompagné par quelqu’un, seul, quand on a le temps, quand on a qu’une minute… Oublier cela, c’est risquer de concevoir un produit inutilisable car ignorant des contraintes des utilisateurs.

Dès lors, il est important de connaître toutes les possibilités qu’offrent les smartphones, à commencer par une quantité de capteurs à utiliser sans modération. Par exemple, l’accéléromètre, le gyromètre et le magnétomètre fournissent des données précises  pour la course à pied. Il est aussi possible de créer un moniteur de fréquence cardiaque avec le flash et l’appareil photo. Ou de connecter l’application à de nombreux capteurs externes (smartwatch, capteurs spécifiques Bluetooth,…). Il ne faut pas non plus omettre l’appareil photo, un classique certes, mais qui par exemple permet de visualiser en réalité augmentée les positions correctes à adopter sur une machine de musculation.

Les Guidelines

Concevoir pour le mobile, c’est également prendre en compte les guidelines (GUI) – sortes de bonnes pratiques – que proposent les différents OS. Pour une application iOS par exemple, nos designers et développeurs utilisent des composants d’UIKit, un framework qui définit des éléments d’interface communs. Ce framework permet aux applications de présenter une apparence homogène même si elles sont développées par des équipes différentes. Elles s’adaptent à chaque device (aussi bien sur un iPhone 5S, que sur un iPhone X).  Le framework offre également un haut niveau de personnalisation (couleurs, typographies, iconographies, identité visuelle du client…), et heureusement ! Sans quoi toutes les applications ressembleraient aux applications systèmes (paramétrage du téléphone).

S’écarter des guidelines, c’est s’écarter de ce que connaissent les utilisateurs, de leurs réflexes et habitudes d’utilisation. Il faut faire la juste balance entre un environnement connu, donc simple à appréhender, les codes du client et une certaine originalité.

Navigation et animations

Il ne faut jamais perdre de vue que le mobile impose un écran bien petit en comparaison d’un ordinateur. Par exemple, qui n’a jamais maudit une application car elle n’était pas pensée pour être lisible lors d’un sprint pour attraper un bus ? La grande différence entre le web et le mobile réside aussi ici : la navigation et les animations. Certains disent, à juste titre, que le web a bien changé et qu’il n’est plus comme cela. Si le web ressemble en effet de plus en plus aux applications, c’est parce qu’il est de plus en plus consulté sur mobile dont les mécaniques ont fait leurs preuves.

A titre d’illustration, il est possible d’observer que les composants des applications mobiles arrivent de la droite, dans le sens de lecture, s’étendent à partir d’un bouton, viennent par le bas de l’écran et repartent. Les popup sont aussi une parfaite démonstration en ce sens. Tout cela signifie quelque chose. C’est cette navigation visuelle qui indique que l’on avance dans le processus, ou que l’application a besoin de faire patienter l’utilisateur pendant un instant pour qu’il renseigne une information avant de poursuivre.

Il faut, sur mobile, user sans abuser de ces mécaniques, car elles indiquent précisément les choses, sans surcharger l’interface : on laisse donc la place aux informations vraiment importantes. De la même façon, laisser des espaces vides, c’est donner plus de place, plus de lisibilité à ce qui est important.

Source : uxinmotion.net

 

Accessibilité

Il existe une multitude d’outils pour nous aider à concevoir une application accessible au plus grand nombre ; ainsi, sur iOS, le framework d’UIKit propose des solutions pour des utilisateurs ayant une déficience visuelle, une perte auditive ou d’autres besoins. Les solutions vont proposer d’agrandir les textes (avec Police Dynamique), ou de lire une description audio des différents éléments de l’écran ou des actions que l’utilisateur peut effectuer (avec VoiceOver)…

Mais l’accessibilité ne concerne pas que les déficiences. Elle veille aussi à réaliser des interfaces facilement lisibles. Lors de la réalisation de nos maquettes, nous utilisons des outils comme celui que propose WebAIM pour vérifier les contrastes entre deux couleurs.

Ces réflexes doivent être développés, car il suffit de peu d’efforts pour rendre accessible une application et donc plus facilement utilisable par tous.

Si le sujet vous intéresse, vous pouvez (re)lire : L’accessibilité des applications iOS.

 

Le choix de la technologie

Faut-il faire du natif, de l’hybride ou du web ? C’est une question à laquelle personne ne semble pouvoir donner de réponse définitive… Il s’agit toujours de revenir à ses objectifs et à ses utilisateurs.

Le web permet d’être disponible sur desktop et sur mobile, mais il n’est pas facilement optimisé pour mobile. Le natif offre une réactivité plus grande que l’hybride, mais il impose deux développements spécifiques. Par ailleurs, le natif simplifie l’utilisation des composants de l’OS mais oblige toujours à passer par l’étape du téléchargement. Il est donc impératif de se demander : le service doit-il être disponible de manière ponctuelle ou de façon récurrente ? A quelle fréquence ? Quels sont les impératifs de réactivité, de fonctionnement hors-ligne, d’utilisation des capteurs ? Quelles plateformes vise-t-on ? Les utilisateurs sont-ils sur mobile, desktop ou les 2 ? Font-ils la même chose sur les deux supports ?

Pour une application de streaming vidéo, utilisable hors-ligne, le natif s’impose. Pour une application événementielle, l’hybride assurera un développement unique. Tout est une affaire de besoins. 

Vous avez un projet d’application ? Discutons-en !

Ces sujets vous intéressent et vous ne souhaitez rien rater de notre dossier spécial sur la démarche produit ?

Inscrivez-vous
Cet article appartient à une enquête
logo business unit

FABERNOVEL TECHNOLOGIES

150 talents pour répondre aux défis technologiques de la transformation digitale.

à lire