Dans mon expérience professionnelle, j'ai remarqué un paradoxe intéressant : j'ai généralement trouvé plus facile de collaborer avec des développeurs back-end qu'avec des développeurs front-end. Les développeurs front-end sont très impliqués dans le flux de travail d'un projet, et ils ont souvent leur propre vision de l'UX, de l'accessibilité, etc. Ils possèdent une expertise que de nombreux UX designers n'ont pas, mais ils ont tendance à être très attachés à leurs propres idées concernant les interactions, le JavaScript et ce qui est ou n'est pas bénéfique pour l'utilisateur. En ce qui concerne les développeurs back-end, j'ai trouvé leur approche de travail très intéressante. Malheureusement, ils sont souvent considérés comme une priorité moindre dans un projet, et leurs contributions arrivent généralement en fin de processus. Cependant, j'ai adopté une approche pour remédier à cela dans chaque nouveau projet : Établir un cahier des charges et des exigences très précis pour le front-end, accompagnés d'une documentation approfondie. Cela permet de fournir aux développeurs front-end un maximum d'informations dès le départ. Travailler en collaboration avec les développeurs back-end dès le début du projet. Les développeurs front-end ont souvent des idées bien définies sur l'UI et les interactions, tandis que les développeurs back-end sont avides de connaissances et ont un état d'esprit plus ouvert. En travaillant ensemble dès le début, les développeurs back-end peuvent apporter des connaissances, des idées et des propositions qui sont plus ouvertes à la discussion que celles des développeurs front-end. Quoiqu’il arrive il est essentiel d'inclure les développeurs front-end et back-end dès le début du projet, lors de la phase de réflexion et de stratégie. Trop souvent, cette phase stratégique néglige l'apport des développeurs back-end, alors qu'ils ont souvent des idées pertinentes à partager. Par exemple, lors de la définition des objectifs du projet, des objectifs commerciaux et des objectifs des utilisateurs, il est crucial de prendre en compte les implications du back-end. Pour éviter les problèmes, il est important d'impliquer les développeurs back-end dès le début et de rapidement préciser aux développeurs front-end que les décisions relatives au front-end seront définies par la recherche, la stratégie et les objectifs commerciaux. En ce qui concerne la gestion de projets, j'ai utilisé différentes approches pour m'aligner avec les développeurs. Par exemple, j'ai souvent utilisé un document Google Docs pour suivre les annotations, en organisant le contenu par chapitres et thématiques (stratégie, recherche, etc.). Cela fonctionne bien lorsque le budget est limité. Une autre approche que j'ai mise en place avec mon équipe il y a deux ans consistait à créer un document structuré de la même manière que le site web et ses pages. Cela nous a permis de développer une refonte complète du site en ayant un document qui correspondait à chaque section du site. Ce document, qui était accessible aux équipes IT, front-end et UX, nous a permis de contribuer les résultats de nos recherches. L'idée était que lorsqu'une personne consultait le moteur de recherche interne, elle savait qu'il existait un document dans la structure qui était un Google Doc regroupant toutes les informations pertinentes. Ce document contenait des informations provenant à la fois du front-end et du back-end. Pour moi, les documents liés à l'UX doivent être vivants et évolutifs. Le cahier des charges, qui est la référence principale, renvoie à des documents externes tels que les personas, les prototypes, et d'autres éléments importants à détailler. En résumé, pour optimiser la collaboration avec les développeurs front-end et back-end, il est essentiel d 'inclure ces deux parties dès le début du projet et de clarifier rapidement les responsabilités et les décisions.
MC Casal
· Head of Digital Transformation | CX-UX (UXMC NN/g)
· il y a 1 an
Pour moi, la plus grosse erreur que je vois, c'est de ne pas demander quelles sont les contraintes techniques au développeur avant de commencer à maquetter. C'est un indispensable parce que si le développeur utilise PrimeNG, il a forcément des librairies de composants derrière et donc si on fait un bouton arrondi et que dans sa librairie le bouton est rectangulaire, il va juste perdre du temps à customiser le bouton. C'est ce qui est hyper important d'après moi. C'est limite LA première question que je pose quand je rentre sur un projet : "Ok ! quelles sont les contraintes techniques ? Quel est le langage de programmation ?" Encore une fois, c'est hyper important. Déjà pour montrer qu'on respecte le développeur et qu'on veut parler le même langage que lui. Je n'y connais pas grand-chose en développement, j'en ai fait pendant ma formation mais je n’aime pas ça. Il y en a qui sont très doués pour ça. Mais le fait d'avoir fait un peu de développement, j'ai ce recul pour me dire "Attends ! Quelle est la contrainte du développeur ?". Récemment, j’ai mis en place des UI kits que je donne au développeur. Ça lui permet de commencer à coder ses composants le temps que je finisse de créer les maquettes. Une fois qu'il a tous ses composants développés, il a juste à prendre le code et le copier-coller, cela va beaucoup plus vite. Après, au niveau design si demain je quitte le projet pour une raison X ou Y le UI kit est toujours là ! Il peut vivre ! Il peut continuer à être développé, il peut être customisé, modifié... Donc ça va se répercuter sur les maquettes de manière très rapide. Finalement ça nous permet d'avoir une boîte de "legos" et de concevoir de plus en plus rapidement. On perd sans doute du temps au début. A ce moment-là, j'explique au client qu'on va prendre une demi-journée pour ça, mais que c'est quelque chose qu'on va alimenter au fur et à mesure. Ce temps passé, tu le gagnes à la fin. Tu as tes composants déjà prêts, forcément ça va beaucoup plus vite que de dessiner à la main.
Bastien, alias Basti Ui, est UX Designer, Youtuber & Streamer. Depuis tout petit, Bastien souhaite faire du graphisme. Malheureusement, après le lycée il n’est pas retenu dans l’école a laquelle il postule, il part donc en DUT Informatique. A la fin de son DUT, Bastien veut toujours faire du graphisme et rejoint l’école des Gobelins pour faire sa licence. Durant cette licence, il découvre le développement applicatif sur iPhone et surtout la conception d’interface. Au fil du temps, il travaille sur de petites applications, gagne en compétences design et découvre qu’il veut devenir UX/UI Designer Mobile. A la fin de ses études, il rejoint une entreprise bruxelloise dans laquelle il travaille comme développeur mobile et Designer d’interface, c’est là qu’il apprend tout du métier de Designer. Puis il rejoint Capgemini à Lille comme “graphiste” où il travaille sur les applications mobile de la FNAC ou Leroy Merlin. Au même moment, Windows 8 sort et Microsoft paie les grandes enseignes de la distribution pour porter leurs applications sur la plateforme. Bastien est le Designer derrière la conception graphique de ses applications qui lui permettent d’acquérir très rapidement de l’expérience et à comprendre ce qu’est vraiment l’UI Design. Véritable touche à touche, Bastien nous explique comment il s’est mis à faire de la DA et de l’animation pour les clients pour lesquels il travaille. Bastien est le premier invité du podcast à travailler en agence. C’est donc l’occasion de comprendre ce milieu, d’en comprendre les avantages et inconvénients, mais également d’en déconstruire les clichés. On aborde donc des sujets variés comme la relation entre un Designer et son client, la place de la user research au cours d’une mission ou encore l’impossibilité de savoir si le travail que l’on a fourni a permis ou non d’aider son client. Avec le temps, Bastien gravit les échelons et occupe un poste de manager. C’est l’occasion de revenir sur son parcours professionnel, comprendre ce qui lui plait dans son métier et qui ce qui lui déplait, mais surtout les raisons derrières ces envies. Cette conversation est un excellent moyen de se poser les bonnes questions savoir comment l’on souhaite évoluer en tant que Designer. D’ailleurs, Bastien nous explique pourquoi il n’aime pas le rôle de manager dans son métier et préfère s’apparenter un mentor afin d’aider les autres designers de son agence à monter en compétence et partager leurs savoirs. Dans son agence, ATECNA, Bastien est l’un de ceux qui connait le mieux l’outil Sketch, on lui demande donc de former les reste des designers à cet outil. Etant tous chez les clients, Bastien décide de faire sa formation sous la forme d’une vidéo… Qu’il finit par poster sur YouTube. Grâce à cette, puis ces vidéos, ATECNA commence à recevoir des demandes de formation de la part de ses clients. Cependant, cela ne rapporte pas assez d’argent à l’agence et Bastien décide de continuer son projet seul. Bastien revient sur les formations qu’il a créé et donné dans son agence : Comment construire un design system ? Comment mettre à plat ses fichiers ? Comment travailler entre designers et développeurs ? Passionné par son métier, Bastien ouvre sa chaine Twitch. Avec lui, on revient sur les raisons qui l’on poussé à partager ses connaissances et faire du contenu régulier autour du métier de designer. On revient aussi sur les raisons de son succès : contenus pratiques, simples et ancrés dans le réel. Dernièrement, Bastien est devenu freelance. L’occasion de comprendre sa décision, la différence entre le freelancing et l’agence et de comprendre ce qu’apporte cette façon de travailler lorsque l’on est designer. Lien de l'épisodeLes ressources de l'épisodesLes liensLa chaine YouTube Basti UiLa chaine Twitch Basti UiLe discord de Basti UiUnderscore Les autres épisodes de Design JourneysL’épisode #5 avec Romain Briaux, 3D Artists et Co-fondateur chez Hervé StudioL’épisode #20 avec Julien Hillion, Lead Product Designer chez QontoL’épisode #15 Avec Audrey Hacq, Product Design Director chez OpenClassrooms Pour contacter Bastien :YouTubeTwitchTwitter Vous avez aimé cet épisode ? Abonnez-vous à DESIGN SYSTEM sur votre application de podcast préférée N'oubliez pas de mettre ⭐️⭐️⭐️⭐️⭐️ avec un petit commentaire sur Apple Podcasts Partagez ce podcast à toutes les personnes qui travaillent dans le Design et le Produit
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la situation réglementaire et juridique de notre domaine.