En bref
De l'idée d'un produit au développement de celui-ci, quel est le rôle de l'UX et de l'UI Design ? C'est ce que nous allons voir dans cet article à travers un exemple de design d'application mobile.
Cet article fait partie d’un autre ⚠️
Si c’est votre première visite ici, déjà bienvenu 👋 . Sachez que cet article fait partie de celui-ci plus global : Débuter dans l'UX/UI Design, un guide compréhensif. Bien que ce ne soit pas essentiel, je recommande néanmoins de commencer par là avant si vous débutez dans l’UX/UI Design.
Table des matières
Le contexte
Prenons par exemple une nouvelle startup qui aurait une idée d’application de fitness disruptive qui, combinée à une AI, utiliserait la caméra de votre smartphone pour analyser vos mouvements et ainsi vous donner des conseils d’amélioration en fonction de la qualité de ces derniers. Précisons, et c’est important, que c’est le premier produit de la startup et qu’ils n’ont pas de données sur leurs potentiels utilisateurs. Notez qu’en réalité, l’exemple qui va suivre peut marcher avec une majorité de startup pour qui leur premier produit serait une application mobile.
(Pour infos, il y a une application qui s’appelle SwingVision qui fait cela pour le tennis et récemment, Peloton a annoncé un produit qui fait la même chose que mon exemple).
Sans rentrer dans tous les détails subtils de la gestion d’un projet, car il faudrait un (voire plusieurs) livres entiers pour cela, voyons les grandes lignes du déroulement du projet.
Gardez en tête que tous les projets du monde ne suivent pas à la lettre ce schéma, je vous donne un cas générique, mais chaque projet sera adapté en fonction de la demande, des ressources, du temps, etc.
Note : dans les paragraphes suivants, je parlerai d’UX Designer et d’UI Designer pour distinguer deux personnes, mais comme dit dans les articles précédents, c’est la majorité du temps un UX/UI Designer.
1 - Vision et démarrage
Tout projet commence par une idée, une vision. C’est à partir de ce point de départ que l’on rentre dans le processus. Sans vision, pas de peintures de Michel Ange, pas de premier voyage sur la lune et pas de Google.
L’UX ou UX/UI Designer sera en début de chaîne, et en fonction de ses compétences, peut être emmené à la conception du brief (ou cahier des charges) avec le product owner (ou PO, c’est le porteur de la vision produit en méthode Agile), c’est souvent le cas quand on parle d’un product designer (voir product designer).
Ce brief ne prend pas forcément la forme d’un cahier de 300 pages, c’est possible pour de gros projets, mais en général, ce sera un (ou plusieurs) documents partagés, décrivant entre autres : la vision, le problème à résoudre et la solution envisagée (plus ou moins précise à ce stade). C’est un document important qui doit fédérer les équipes autour d’une vision claire.
Après la création du brief, Il y a une réunion de lancement du projet avec tous les acteurs de ce dernier pour s’assurer que tout le monde soit bien aligné sur la vision. Pour les designers, il est entre autres, important d’avoir le plus tôt possible, le retour des développeurs sur les limitations techniques afin d’éviter de faire des designs qui ne seraient pas faisables.
2 - UX Design
Dans notre exemple, je me concentre sur le design de l’application mobile, mais pour rappel, l’UX Designer a pour intérêt l’expérience des utilisateurs avec la startup dans son ensemble (enfin ça dépend si on fait une différence avec le CX Design).
À partir du brief, l’UX Designer va analyser la demande et si besoin faire des allers-retours avec le PO afin de valider sa compréhension. La bonne compréhension du problème que le projet cherche à résoudre est cruciale pour l’UX Designer, meilleur elle sera, meilleure sera la solution.
L’objectif premier de l’UX Designer est de cerner les besoins des utilisateurs finaux et d’harmoniser ces derniers avec le produit et la vision. Concernant le produit en lui-même, il est décrit dans le brief, mais il est bien sûr en évolution tout au long de la phase UX et UI (et globalement, durant toute la vie de l’entreprise).
Il va alors appliquer différentes techniques du domaine de l’UX et comme dit précédemment, il serait impossible de dire lesquelles sont utilisées par tout le monde, cela dépend du projet, du temps, budget alloué et des compétences du designer.
Cela dit, dans l’idéal pour notre exemple, les étapes seraient les suivantes :
2.1 Interview utilisateurs
Si pour notre startup, ce n’était pas leur premier produit, elle aurait très probablement déjà des données sur ses utilisateurs qu’elle pourrait exploiter. Comme ce n’est pas le cas, la première étape sera de s’entretenir (en présentiel ou en ligne) avec une sélection de clients potentiels afin de mieux connaître leurs comportements et leurs attentes.
2.2 Définition de persona
Ensuite, l’UX Designer va procéder à l’analyse des données de la phase de recherche précédente. Il va synthétiser deux/trois (ou plus si besoin) profils d’utilisateurs types et en faire une fiche (persona) pour chacun. Elles sont utiles pour l’ensemble des équipes, cela permet d’avoir en tête qui sont les utilisateurs de notre travail. Pour l’UX bien sûr, mais aussi par exemple pour l’équipe marketing, pour établir des campagnes adaptées pour eux.
2.3 Scenario map
Maintenant que l’on a défini nos utilisateurs et qu’on en a créé des personnages, il est temps de “jouer” avec eux et voir comment ils peuvent évoluer dans le produit.
Avec les acteurs du projet, l’UX Designer va définir les actions des utilisateurs d’après leurs buts listés dans les personas. Ces actions sont appelées des “User story”, par exemple dans notre cas, l’une pourrait être : “En tant qu’utilisateur, je souhaite obtenir un entraînement personnalisé afin de progresser de manière optimale pour moi”. Le scenario map liste les étapes dans le futur produit pour accomplir toutes les actions des utilisateurs, et pour chaque étape, les équipes vont lister des idées des designs, des questions et des commentaires à prendre en compte.
2.4 User flows
Une fois qu’on a défini toutes les actions des utilisateurs avec leurs scénarios, il est tant de les articuler avec de la logique entre elles autour d’un user flow. Dans cette partie, l’apport des développeurs est essentiel. Le user flow est utile aux designers comme aux développeurs pour avoir une vue globale de la structure et de la logique de l’application.
Notez que l’on peut avant cette étape faire des story map qui sont proches des scenario map mais rentrent plus en détail dans les actions des utilisateurs, une sorte de “pre user flow” en somme.
2.5 Wireframes
À cette étape, l’UX Designer va préciser la structure des écrans définis dans le user flow. Le wireframe va, sans UI Design, montrer la vision de l’UX Designer sur la distribution des éléments (images, titres, boutons, etc.) qu’il juge le plus adéquat pour le projet.
Note : il pourrait aussi d’abord faire un zoning (ou “blockframe”) pour obtenir validation avant de passer du temps sur le wireframe.
Le wireframe se fait sans les textes ou le minimum, en général ce sont d’autres personnes (copywriter, marketing, PO, etc.) qui les écrivent, mais l’UX Designer peut y participer.
2.6 Tests utilisateurs/internes
Si le temps le permet, il est conseillé de faire des tests utilisateurs (en fonction du wireframe, s’il est trop abstrait ce peut être contre productif).
Pour cela, l’UX Designer aura fait un prototype utilisable avec les wiframes (par exemple les boutons seront cliquables) et pourra ainsi recueillir les remarques d’utilisateurs à mesure qu’ils naviguent dans le produit.
Et surtout, le wireframe doit être validé par tous les acteurs du projet, c’est important avant de passer à la phase d’UI Design. Si plus tard, durant la phase UI ou même du développement, on découvre des failles importantes dans l’UX, cela coûtera plus cher à la startup de les corriger que maintenant.
3 - UI Design
Une fois l’UX validée, l’UI peut commencer. Notez que l’UI Designer, dans un souci d’optimisation du temps, peut tout à fait commencer à travailler en amont de l’UX Designer. Sur la première étape (3.1) et dans une moindre mesure sur la deuxième (3.2) (sur des parties du wireframe déjà validées).
3.1 Recherches et moodboard
La créativité se nourrit de travaux existants, ainsi, l’UI Designer cherchera des designs pour inspiration qu’il pourra combiner sur une planche (moodboard). Il est recommandé de produire au moins deux planches aux styles différents et de les présenter aux décideurs du projet pour avoir leurs avis.
3.2 Croquis
Avant de partir sur un logiciel, je recommande vivement de faire d’abord des croquis de l’UI à la main, ces derniers se basent sur les wireframes de l’UX Designer et décrivent plus détails leurs contenus. Je ne suis pas le seul à l’avoir remarqué, mais dans cette phase on est plus créatif avec un crayon (ou un stylet digital) qu’une souris.
3.3 Construction de la styleguide
C’est un guide visuel et textuel des éléments qui composent l’UI, c’est-à-dire les : couleurs, polices d’écritures, tailles des espacements, icônes, illustrations, formes des boutons, formulaires, animations, etc. Elle est partagée avec les développeurs, par exemple avec ZeroHeight.
En réalité, cette partie se fait durant tout le long des étapes suivantes, on y fait des allers-retours sans cesse. Il serait contre-productif de tenter de faire toute la styleguide d’un côté sans la tester sur des écrans de l’application.
En général, la styleguide rentre en compte d’un ensemble plus grand : le design system. Ce dernier consiste à apporter et maintenir la cohérence globale du fond et de la forme des designs produits par l’entreprise. C’est une source de savoir centrale, composée, par exemple, de la vision de l’entreprise, d’indications sur les choix marketing (ton, vocabulaires, etc.), design (styleguide) et code (convention de notation, technologies, etc.). Il est partagé avec tous les acteurs des produits de l’entreprise. Deux bons exemples sont ceux de Decathlon et d’IBM.
3.4 Maquette et prototypage
“Si une image vaut 1000 mots, un prototype vaut 1000 réunions.” - IDEO
La maquette, c’est la mise au propre des croquis, ce sont les wireframes avec le design final. Le prototype, c’est le fait de rendre ces écrans interactifs, ce dernier est la pierre angulaire de notre processus, il est le point culminant des étapes UX et UI précédentes et sera la base de travail pour les tests utilisateurs et les développeurs.
En résumé : l’UI Designer va habiller les wireframes de couleurs, typographie, icônes, boutons, images, etc. Et les rendre interactifs. Il y a quelques années, faire un prototype cliquable n’était pas une mince affaire, mais depuis l’avènement des outils comme Sketch, Figma ou Adobe XD, c’est aujourd’hui bien plus simple, et sans faire de code.
3.5 Tests utilisateurs/internes
Avant que les développeurs ne commencent leurs tâches, l’UI Designer va faire tester le prototype à des utilisateurs potentiels afin de voir s’il y a des blocages ou difficultés. On le teste aussi avec les acteurs du projet (dont les développeurs bien sûr) pour que tout le monde soit en accord. Là encore, les outils cités précédemment facilitent la collaboration en offrant la possibilité de partager un lien du prototype à tous et de le commenter.
S’il y a bien une règle d’or à la base des tests utilisateurs, c’est celle-ci : Il vaut mieux fixer les problèmes là où c’est le moins chère. C’est-à-dire sur le prototype plutôt que sur le produit développé (il est plus simple et surtout moins coûteux de bouger des boutons de place sur un prototype que sur le produit développé).
C’est une phase critique et même s’il n’y a pas suffisamment de temps alloué, alors des tests en interne peuvent suffire. Mais cette phase est là pour éviter au maximum les changements de dernières minutes sur l’application quand on en est à la phase de développement.
3.6 Préparations pour les développeurs
Les logiciels cités précédemment permettent aussi de faire ce qu’on appelle le “handoff” pour les développeurs, c’est-à-dire leur faciliter le travail. On va exporter les assets comme les illustrations et les icônes aux bonnes tailles, documenter la styleguide en indiquant ce qu’il faut respecter comme règles (espacements, contrastes, animations, etc.) ou encore documenter le prototype de toutes remarques qui leur éviteraient d’avoir des doutes sur notre vision.
4 - Développement
Les développeurs font leur travail. Mais les designers ne sont jamais loin, car ils ont sûrement des remarques pour eux et il est probable qu’ils travaillent en méthode Agile (nous verrons les méthodes de gestion de projets plus loin). De ce fait, pour optimiser le temps, le chef de projet (ou project manager), aura pu planifier les tâches de l’UI Designer de telle sorte que les développeurs commencent à travailler quand une ou plusieurs fonctionnalités sont prototypées, testées et validées. Et pendant qu’ils développent, l’UI Designer continue sur le prototypage de la fonctionnalité suivante.
Puis une fois terminé, c’est la sortie sur le marché de la version 1 (“mise en prod” dans le jargon). Mais tout ne s’arrête pas là, les produits sont en constante évolution et très vite, on revient au début du processus en fonction des retours utilisateurs pour améliorer le produit. Par exemple, les équipes d’Adobe XD ont ouvert un compte sur uservoice.com. Ainsi, les utilisateurs peuvent soumettre leurs idées de nouvelles fonctionnalités et voter pour celles qu’ils préfèrent (adobexd.uservoice.com).
(Bon après ça fait cinq ans qu’ils ont la demande pour un thème sombre, car oui, c’est un grand paradoxe, un logiciel d’UX/UI Design qui n’a qu’un thème clair…)
Pour continuer sur votre lancée
Comme mentionné au début de cet article, il fait partie d’un ensemble plus grand, pour continuer c'est par là.
Doko Zero
UI Designer avec des compétences en UX et développement web