Cet article a été écrit il y a plus d'un an : son contenu peut être dépassé.
Après une brève introduction sur l’importance d’une bonne interface utilisateur, on va s’attaquer un peu à la méthodologie pour concevoir ladite interface utilisateur. Rien de très barbant, juste quelques notions élémentaires, histoire de savoir de quoi on parle.
Note : gardez à l’esprit que je suis développeur et pas Ux Designer ni ergonome. Les éléments qui suivent sont volontairement simplifiés et incomplets, je n’ai pas la prétention de remplacer des personnes dont c’est le métier. L’article présente juste des concepts généraux à destination des développeurs pour mieux comprendre les processus, il conviendra au lecteur d’aller ensuite chercher l’information nécessaire ailleurs si le sujet l’intéresse.
Étape 1 : analyse du besoin, du contexte et des utilisateurs
La première étape dans la conception d’une interface utilisateur est tout simplement une phase d’analyse. Analyse du besoin, du contexte et des utilisateurs : l’objectif est de mieux comprendre les tenants et les aboutissants du futur logiciel.
Pourquoi ?
Prenons le cas d’une application mobile par exemple. Est-ce une application à usage interne ou grand public ? Cible-t-elle des jeunes de moins de 20 ans, des quarantenaires, des retraités ? Va-t-elle être utilisée en usage sédentaire (par exemple, une application de pilotage de la TV) ou en usage mobile (par exemple un lecteur de news, utilisé dans le métro) ?
Toutes ces questions doivent amener à faire des choix par la suite. Par exemple, si notre application est susceptible d’être utilisée pendant que l’utilisateur conduit (application GPS), il faudra privilégier une interface vocale pour donner les ordres plutôt que de l’affichage.
De même, si l’application est à destination d’enfants, il faudra choisir un vocabulaire simple et compréhensible pour eux, la plupart du temps sur la base du tutoiement. Il est en revanche déconseillé d’utiliser le tutoiement pour une application à destination d’adultes.
Toute cette étape doit permettre de se poser les bonnes questions pour faire les meilleurs choix par la suite. Cette phase permet également d’affiner la stratégie marketing du logiciel et les moyens de fidéliser les utilisateurs. En fonction des cibles, les campagnes marketings seront différentes, de même que les canaux de distribution. Bref, une étape essentielle.
Comment ?
Il existe différentes méthodes pour formaliser ces éléments. Une première méthode est le storyboard. Il s’agit d’une mini BD qui présente le produit dans un contexte d’utilisation. Pas question ici de proposer des éléments d’interface utilisateur mais juste d’illustrer des usages. Par exemple, dans le cas d’une application GPS, on verra l’utilisateur au volant de sa voiture dicter des commandes.
Un exemple de storyboard pour l'enregistrement sur un site - @Rob Enslin - CC By 2.0
Il est également possible d’utiliser des personas. Il s’agit de descriptifs représentant des utilisateurs fictifs qui accompagneront le concepteur tout au long du projet. Cela permet d’avoir une référence sur les utilisateurs et de faciliter les présentations futures (il est plus facile de présenter avec un contexte que sans).
Un exemple de persona - @Ant Mace - CC BY-NC-ND 2.0
Ce ne sont pas les seules méthodes. Le concepteur peut aussi utiliser des Ux Cards pour parvenir à ses fins, faire des audits d’applications existantes, étudier la concurrence, etc. Tout est bon à prendre du moment que ça permet d’affiner la compréhension du besoin et les attentes des utilisateurs.
Bien entendu, ces méthodes de formalisation sont à étayer impérativement avec des entretiens utilisateurs. Seuls des échanges avec les utilisateurs permettent d’affiner et de valider les besoins, les attentes et les fonctionnalités qui en découlent. C’est le dénominateur commun à tout : un storyboard ne sera valide que s’il a été testé auprès des utilisateurs cibles. Un personae ne sera pertinent que s’il couvre les utilisateurs rencontrés.
Une phase de conception sans entretien utilisateur risque de passer complètement à côté de l’essentiel et d’accoucher de besoin non pertinents.
En savoir plus :
- Création de storyboards (en) : https://uxplanet.org/storyboarding-in-ux-design-b9d2e18e5fab
- Retour sur la méthode des Ux Cards (fr) : http://www.usabilis.com/utilisation-ux-cards-conception-digitale/
- Création et utilisation de personas (en) : https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them
Étape 2 : structuration et maquettage de l’interface
L’étape d’analyse aura normalement permis d’élaguer les fonctionnalités et un certain nombre de scénarios-clés aura été identifié. Ce sont ces scénarios qui vont ensuite être maquettés et serviront de base pour le reste.
La première phase est celle de la structuration du contenu. On ne parle pas encore ici de composants graphiques spécifiques mais plutôt de zoning. L’idée est de représenter la future interface en gros blocs regroupant des fonctionnalités similaires : le header, la fiche descriptive du produit, la zone de commentaires, le footer, etc. On obtient ainsi un ensemble de pages desquelles finit par se dégager une structure commune.
Dans le même temps, les relations entre les écrans est pensée et débouche sur la production d’un sitemap (ou équivalent). Ce document décrit toute l’arborescence de l’interface : nombre d’écrans, enchaînements entre eux, etc. Il permet de mieux visualiser les différentes étapes d’un utilisateur pour réaliser une action donnée. .
Un exemple de sitemap - @Kent Bye - CC By 2.0
Une fois les grandes lignes tracées, la seconde phase est la création de wireframes. Un wireframe ou maquette en fil de fer est la représentation de l’interface dénuée de toute notion graphique.
Exemple de wireframe pour un profil utilisateur - @Joe Crawford - CC By 2.0
Comme on peut le voir sur l’exemple, les différents composants sont présents mais le contenu reste vide. L’objectif de cette phase est vraiment de penser l’interface en terme d’expérience utilisateur sans perturbation du côté graphique. On parle d’usabilité (capacité à utiliser l’interface), la beauté viendra après.
Cette maquette fil de fer peut parfois faire l’objet de développement sous forme de maquette. On obtient ainsi une version réactive qui permet de mieux se rendre compte des enchaînements d’écrans : il est plus facile pour l’utilisateur testeur de visualiser l’action quand il la ressent que si on la lui explique.
Parce que oui, il ne faut pas oublier de faire tester son interface régulièrement par les utilisateurs finaux. Dans 90% des cas, les premières ébauches débouchent sur des incompréhensions et nécessitent des ajustements assez lourds : autant s’en rendre compte avant de faire la livraison finale !
En savoir plus :
- Conception de wireframe (en) : https://uxmastery.com/wireframing-for-beginners/
- Conception de sitempa (en) : https://www.protofuse.com/blog/details/how-to-design-structure-website-with-sitemapping/
Étape 3 : design
Les wireframes passent ensuite entre les mains de l’équipe graphique. C’est en effet elle qui aura la charge de mettre de la couleur aux écrans, de les adapter aux contraintes systèmes, aux modes du moment, etc. C’est également l’équipe graphique qui va réaliser les logos et autres icônes pour l’application, là où ces zones sont restées vides sur les maquettes.
De ce travail découle souvent une charte graphique qui servira de référence aux développeurs front-end. Des Ui Guide Styles peuvent également être produits. Plus simples et plus pratiques, ils représentent les différents composants utilisés dans l’application, designés et prêts à l’emploi.
Par exemple, voici le guide de style de MapBox : https://www.mapbox.com/base/styling/buttons/
En règle générale, les designers touchent rarement au positionnement des composants, sauf grosse erreur vis-à-vis des contraintes systèmes. En revanche, ils ont tout de même des contraintes importantes à respecter en terme d’ergonomie et d’accessibilité qui ne sont pas prises en compte dans les étapes précédentes.
Par exemple, le choix des couleurs est important : il faut un contraste marqué entre la couleur de texte et la couleur de fond pour être sûr que des personnes déficientes visuellement puissent lire convenablement.
Des tests utilisateurs sont également menés dans cette phase pour voir comment les utilisateurs réagissent à l’ensemble.
En savoir plus :
- Exemple de style guide – Yelp : https://www.yelp.com/styleguide
- Exemple de style guide – Mail Chimp : https://ux.mailchimp.com/patterns
- Exemples de designs d’applications en tout genre, logos, icones, etc. : https://dribbble.com/
Étape 4 : développement
La phase de développement est assez classique et est du domaine de la technique : aux développeurs de produire ce que les précédents ont spécifié (design, ux, etc.) en fonction des différentes technologies à disposition. D’où l’importance de connaître, à minima, les pré-requis pour la création d’une interface correcte.
Néanmoins, le développeur n’est pas passif pour autant. Tout d’abord parce que tous les écrans ne sont souvent pas maquettés/designés. Par exemple, dans le cadre d’écrans présentant des données similaires, un seul est souvent représenté ; charge au développeur de décliner ensuite.
Il se peut aussi que des contraintes techniques obligent à des modifications, même si les développeurs ont été inclus dans le processus de création dès le départ. À ce moment là, deux possibilités se présentent : soit la modification est mineure et les développeurs font l’adaptation eux-mêmes, soit l’écran repart en phase d’ergonomie si plus d’éléments sont impactés.
De futurs articles détailleront plus en détails les points auxquels doivent prêter attention les développeurs.
Étape 5 : suivi de l’interface
Une fois l’interface développée, il reste l’étape du test et de la validation. Je passe volontairement sur la partie technique (classique, avec des tests unitaires, de charge, etc.) pour me concentrer sur la validation de l’interface en elle-même.
Comme dans les étapes précédentes, il faut valider par des tests utilisateurs, cette fois avec une application fonctionnelle. Si des points de gêne persistent, ils peuvent mener à une phase de refonte côté ergonomique. Si l’interface est jugée suffisante, celle-ci est mise en production.
Néanmoins, le travail autour de l’UX n’est pas terminé. En effet, malgré des tests utilisateurs, il reste difficile d’évaluer le comportement des utilisateurs sur le long terme. Par exemple, un élément graphique qui peut être jugé sympathique en première instance peut vite passer dans la catégorie des éléments indésirables quelques temps après.
Il faut donc assurer un suivi pour corriger l’interface si besoin. Cela peut par exemple se traduire par une boîte à suggestions ou par du suivi statistique (analyse des éléments sur lesquels les utilisateurs cliquent le plus, pourcentage d’abandon lors de la création d’un panier sur un site marchand, etc.).
Si des points négatifs trop importants sont remontés, il faut réenclencher une nouvelle phase de réflexion ergonomique. Avec à la clé des modifications de code potentielles. Lesquelles pourront être testées par des phases d’A/B testing, par exemple.dqq
Principe de l'A/B testing - @Maxime Lorant - CC By-SA 4.0
En savoir plus :
- Guide sur l’A/B testing (en) : https://www.smashingmagazine.com/2010/06/the-ultimate-guide-to-a-b-testing/
- Organiser des tests utilisateurs DIY (fr) : http://blocnotes.iergo.fr/concevoir/experimentation/mode-demploi-test-utilisateurs-diy/
- Mythes et réalités sur les tests utilisateurs : http://blocnotes.iergo.fr/articles/tests-utilisateurs-mythes-et-realites/
Conclusion
La création d’une interface utilisateur est un processus long et complexe. Il demande beaucoup de temps, de rigueur et de connaissances pour aboutir à un résultat optimal.
Néanmoins, quelle que soit la façon de faire, il faut toujours valider avec les utilisateurs. Tout le temps. C’est la condition essentielle des interfaces réussies.