Il était une squad...
Depuis des temps immémoriaux, il existe une guerre plus ou moins ouverte, un objet de fantasme entre les designers et les développeurs.
Nous pourrions faire une analogie simple avec la situation des habitants du village de l’album Le grand fossé d’Astérix (à lire absolument) : obligés de vivre ensemble, s’appréciant mais sans se comprendre pour autant et bloqués par leur propre vision de l’autre...
Clairement, cette vision de l’autre est basée sur des clichés éculés et sur un manque évident de communication entre les 2 parties. Si en plus, vous saupoudrez ceci d’une petite guerre d’égo propre au digital... vous avez tous les ingrédients d’une collaboration pas complètement efficace, chronophage et parfois épuisante...
Illustration trop souvent vraie d’une collaboration entre développeurs et designers de nos jours...
En prenant de la hauteur, on se rend compte qu’en partant d’une telle situation, tout le monde est perdant et y laisse des plumes.
Les designers sont déçus de ne pas avoir en production des expériences fidèles à ce qu’ils avaient conçu.
Les développeurs, pour leur part, voient les designers comme des artistes ne se souciant guère des contraintes techniques dans leurs livrables.
À ce jeu là, le grand perdant est bien sur l’utilisateur final.
Il est temps de poser les armes et prendre du recul
Les clichés ne manquent pas dans le monde du numérique. Voici les plus connus entre designers et développeurs (⚠️ alerte “Clichés”).
Les designers vus par les développeurs
- Les designers sont des artistes et sont là avant tout pour faire de belles interfaces.
- Les designers ne prennent pas en compte l’avis des développeurs.
- Les designers pensent leur features en surfant sur dribble et viennent voir les développeurs en pensant que tout est facile (si airbnb le fait pourquoi pas nous ?).
- Les designers sont dangereux quand on ne suit pas au pixel près leur maquettes.
- Les designers pensent savoir développer car ils ont déjà monté un site sur wix ou webflow 🤣.
Les développeurs vus par les designers
- Les développeurs ne comprennent pas l’importance esthétique de notre travail et son impact sur l’accessibilité.
- Les développeurs ne comprennent pas la portée scientifique de notre travail et pensent que c’est seulement du dessin.
- Les développeurs disent non à tout (petite variante ‘”ça ne passera jamais” ou “c’est au moins 6 mois de dev 😝”).
- Les développeurs se déchargent quand on leur demande leur avis (tu maquettes, je code et basta) par contre, ils ne se gênent pas pour apporter des changements sans nous en informer.
- Les développeurs ne veulent jamais participer aux ateliers/workshops d’idéation (”Je sais pas dessiner et, de toutes façons, je suis là pour dev point barre”).
Des années de mauvaises pratiques dans l’écosystème Produit auront forgé ces clichés et idées reçues.
Imaginons que vous avez crée la plus belle expérience utilisateur du monde, cela ne servira malheureusement à rien si :
- Elle ne fonctionne pas correctement
- Elle est trop longue à concevoir
- Elle fait planter ou ralentir le système
- Bonus : elle ne répond pas à un réel besoin... on le rappellera jamais assez : discovery !
Pour aller plus loin : Inscris-toi à notre formation Discovery Discipline
Toutes ces raisons récurrentes devrait être suffisantes pour vous motiver à travailler conjointement et étroitement avec vos développeurs.
Chacun a une façon de travailler spécifique et un domaine d’expertise propre, c’est indéniable, mais les designers et les développeurs ont besoin les uns des autres pour construire et imaginer des produits.
C’est indispensable pour que ces produits deviennent de véritable expérience inspirante à la parfaite intersection entre les besoins business, métier et technique.
On peut passer au concret s'il vous plaît !
On y vient, on y vient 😉
Chez Thiga, tous nos Product Designers en immersion ont comme vous ce genre de situations à gérer.
Nous avons donc décidé avec eux, et après une belle phase de discovery en interne, de vous livrer nos 12 conseils actionnables pour commencer à mettre en place une collaboration efficace entre les équipes design et de développement.
Ces 12 conseils sont tous en lien avec une idée simple que vous ne devez toujours garder à l’esprit :
💡 Mettre en place des échanges, processus et outils pour améliorer la collaboration et faire converger les intérêts de chacun.e à chaque étape clé de la vie du produit (Recherche, Conception et Hand-off)
1 - Impliquer les développeurs pendant les phases de discovery
Ça parait somme toute assez logique mais on travaille mieux ensemble quand on comprend pourquoi on traite un sujet... Trop souvent, les équipes techniques ne sont peu ou pas au courant des phases de discovery, de conception, des résultats des tests utilisateurs réalisés, ni du pourquoi de certains choix design.
Impliquer les développeurs pendant la phase de discovery permet de donner une big picture des enjeux sur lesquels ils seront amenés à travailler.
Il est important d’impliquer l’équipe Tech lors des immersions, interviews et tests utilisateurs.
N’hésitez pas à partager votre research deck à toute votre équipe. Cela crée une dynamique d’ensemble où tout le monde se sent impliqué et a envie d’avancer dans la même direction.
Chez Leetchi, Un research Deck est effectué conjointement avec l’équipe Tech et les Product Managers.
Ainsi, des le départ, tout le monde est dans la boucle et à connaissance des enjeux et de l’opportunité à saisir.
Très souvent, les développeurs sont encore moins présents dans la phase d’idéation alors qu’ils sont complètement en capacité de proposer des idées qui sont pertinentes.
Cela permet pourtant d’avoir des représentants de la Tech qui peuvent cadrer, en amont, l’impact technique de certaines idées (matrice impact/effort à faire ensemble notamment en fin de phase d’idéation).
Impact Effort Matrix
2 - Privilégier les ateliers clés à forte plus-value
Dans un monde idéal, nous aimerions tous pouvoir impliquer les développeurs dans plusieurs ateliers de co-conception, mais dans les faits, il est assez rare que l’équipe avec laquelle vous travaillez soit disponible pour participer à ces workshops.
Pour palier à cette problématique, c’est à vous d’identifier les ateliers clés où la présence d’une partie de l’équipe tech est recommandée voir indispensable ( notamment les ateliers de priorisation, de faisabilité technique etc...)
C’est tout de même important d’avoir un développeur aussi sur les phases de création.
En matérialisant nos concepts, les développeurs ont souvent une idée du marché et de certains fonctionnalités qui peuvent aider l’équipe et les utilisateurs.
Le plus simple et le plus important est d’avoir le Lead Tech présent aux ateliers clés, ainsi il pourra parler aux développeurs dans un second temps et expliquer la situation.
Chez Leetchi, nous avons toujours le Lead Tech de l’équipe en lien avec le sujet qui est présent sur les ateliers d’idéation et de solution S’il ne peut pas , un membre de l’équipe Tech est toujours la pour le seconder
3 - Prendre en compte les contraintes techniques pendant toutes les phases de discovery
Partir en phase de Discovery, en ignorant le périmètre maximum possible techniquement nous expose à des aller-retours infinis avec les équipes Tech quand on passera en phase de Build.
Prendre en compte les contraintes techniques, vous permettra en tant que Product Designer de proposer des solutions techniquement viables quand vous testerez vos prototypes auprès de vos utilisateurs et ainsi de gagner en crédibilité auprès de votre équipe Tech.
Par exemple : une session de crazy eight avec vos développeurs frontend et backend est un bon et rapide moyen de vous assurer de la viabilité technique de vos idées, en effet cet atelier est intimement propice à la discussion une fois que tout le monde aura rapidement sketché ses idées.
C’est ainsi permettre de renforcer les liens de l’équipe et gagner du temps pour tout le monde afin de se concentrer sur l’essentiel : la créativité et une solution efficace aux painpoints de nos utilisateurs.
⚠️ Attention, l’idée n’est pas de fermer la création et l’idéation sous un étau technique et nous ne disons pas cela.
Par contre, avoir une vision d’un spectre techniquement réalisable peut justement aussi permettre de trouver des idées novatrices.
Nous ne parlons pas de recherche exploiratoire où tous les spectres sont ouverts mais plus de recherche orientée ( en lien avec une nouvelle feature ou la mise à jour de celle-ci)
4 - Évangéliser sur le Product Design et aussi sur l’intégration graphique
Trop souvent nous autres designers avons la fâcheuse tendance à nous concentrer sur nos process et à ne pas faire l’effort de communiquer autour de notre métier.
Il ne faut absolument pas minimiser l’impact que peut avoir une conversation et/ou une présentation autour d’un sujet qui finalement concerne toute l’équipe Produit.
Ne faites pas l’économie d’une sharing session autour du Design System, de nos processus, de tests utilisateurs, de l’utilisation de Figma ou de l’accessibilité !
Vous allez ainsi renforcer l’expertise métier de vos interlocuteurs Tech, voir même les intéresser à certains sujets dont ils n’avaient pas connaissance.
N’hésite pas non plus à inviter des représentants de ton équipe Tech à ta présentation sur le Product Design pour la mettre à niveau sur ce que tu fais en tant que Product Designer, avec si possible des exemples concrets.
Présente ce support également aux nouvelles recrues Tech pendant leur onboarding afin de les mettre dans le bain du Product Design dès leur arrivée !
Présenter ton métier, définir ton rôle et communiquer autour en permanence est important pour ta place au sein de l’équipe
💡 Tips : Organisation de masterclass auprès des équipes tech sur des sujets design (design system, atomic research, accessibilité, UI etc)
5 - Être présent dans les rituels agile et tech (Rétro, daily, refinement)
“Je suis un Product Designer et je choisis de travailler dans mon coin, je n’ai pas besoin de participer aux rétros agiles. De toutes façons, je ne comprends rien quand les devs parlent de code” Ce discours vous rappelle quelque chose, non ?
A l’inverse de ce que nous disions pour l’implication des développeurs dans la Discovery, il est tentant de ne pas participer aux rituels Tech pour gagner du temps.
Mais en faisant cela, vous vous mettez vous-même à l’écart de votre équipe, qui, la majorité du temps, sera bien plus nombreuse que vous.
En étant présent et en participant aux rituels agiles, vous assumez complètement la place qui est la vôtre au sein de la squad/feature team dont vous faites partie, vous communiquez sur les discovery en cours, les choix design, les avancées, les points de blocage et contribuez ainsi à la création d’un esprit d’équipe.
C’est aussi un bon moment pour donner à l’équipe Tech l’envie de vous rejoindre sur des sujets de Discovery ou de co-conception !
Dernier point : avant de vous inviter dans les réunions, il est important de comprendre ce que signifie l’agilité et les différentes approches. On peut vous conseiller la lecture du Manifeste Agile, le Scrum Guide et différents articles sur la méthodologie Kanban pour ne pas que vous ne soyez pas perdu·e dans le vocabulaire et les outils utilisés par l’équipe.
En tant que Product Designer, il y a des rituels plus importants que d’autres. Chez Thiga, nous vous conseillons de participer au Daily, à la rétrospective et au refinement, si cela est possible bien sûr et en fonction de votre temps si un choix doit être fait nous recommandons de participer au minimum au daily et à la retrospective.
Cela te permettra de vous tenir informé·e sur les différents sujets, d’éclaircir des points concernant des maquettes et de pouvoir donner votre avis à la fin d’un sprint sur ce qui a fonctionné ou non.
6 - Faire des Design Reviews en préparant le contexte (Stories, Vision cible, Gouvernance)
Il est toujours important de prendre le temps d’organiser de façon récurrente des design reviews auprès de votre équipe de développeurs ou de Product Designers. Cela leur permettra de mieux appréhender les choix Design, voir même de les challenger.
En mission chez bedrock, nous utilisons ce framework tout simple pour lancer des design reviews sur des sujets précis.
C’est aussi, bien souvent, une opportunité de parler de problèmes sur des composants à re-designer, d’informations dont tout le monde n’a pas conscience... bref de communiquer entre designers et développeurs.
Pour que ce moment d’échange soit riche en enseignement, il vous faudra bien sûr en amont présenter à toute l’équipe la vision cible, la gouvernance mise en place, le contexte etc.
7 - Faire du Pairing pour sensibiliser sur la conception en cours et les enjeux d’intégration
Travailler main dans la main avec un développeur de votre squad dès la démarche de conception présente plusieurs avantages :
1. Avec 2 cerveaux sur le même problème, on est forcément plus efficaces ! Les développeurs ont une approche plus pragmatique que la nôtre sur la façon d’appréhender les problématiques, se mettre à réfléchir ensemble vous permettra de trouver de nouvelles idées auxquelles vous n’auriez sûrement pas pensé tout seul (une sorte de workshop de co-création mais sur un format long et juste à 2 en fait 😅). C’est aussi une bonne façon de se challenger en continu !
2. En collaborant étroitement avec un développeur, vous vous rendrez plus facilement compte des contraintes techniques liée à la problématique et gagnerez ainsi un temps précieux lors de votre phases de conception. Parallèlement, c’est un bon moyen d’évangéliser sur le Product Design et de permettre à votre développeur de comprendre notre façon de travailler.
8 - Mettre en place un vocabulaire et des enjeux communs à travers le Design System
Mettre en place un Design System lorsque l’on développe un Produit est une excellente solution pour favoriser la collaboration entre Product Designers et Développeurs. C’est le point de contact et une source de confiance commune entre tous les acteurs du développement d’un produit.
A travers la mise en place d’un Design System, vous permettrez aux développeurs de ne pas avoir à réinventer la roue à chaque sprint/feature etc et ainsi de pérenniser les choix design de l’équipe.
Toujours dans un souci d’améliorer les échanges et avoir un langage commun, cela permet aussi de se réunir pour définir ensemble la nomenclature de tous vos composants, assets et notamment votre vision afin fluidifier ainsi votre collaboration future.
Mettez-vous cinq minutes à la place du développeur qui inspecte vos maquettes finales, si vos frames dans Figma ont été nommés à la va-vite (ou pas nommées du tout... ) il est quasi certain qu’il va passer un temps fou à s’arracher les cheveux sur l’inspection de chaque frame/rectangle/square.
Ainsi, il va perdre un temps précieux qu’il aurait pu certainement passé à respecter l’UI parfaite que vous lui avez livrée.
Layers bien nommés, développeurs contents... ✌️
Encore une fois, se mettre d’accord ensemble dès le début sur une nomenclature commune, une structure de composants clairs et documentés (padding, border radius, différents états ainsi que la nomenclature correspondante) vous permettra dès le départ d’envisager tous les uses-cases d’un composant à un niveau macro et de limiter grandement les frictions par la suite.
9 - Avoir une gouvernance Tech-Design et un cycle de vie Produit pour votre Design System
Comme on dit chez Thiga, un Design System est un produit dans le produit
Pour aller plus loin : vous êtes fortement incités à regarder ce talk Thiga X Doctolib sur la collaboration mise en place autours du Design System de Doctolib).
À ce titre, il vous faudra être particulièrement vigilant lors de sa création sur le mode de gouvernance que vous souhaitez mettre en place autour de ce produit. Pour être pleinement efficaces, votre “Core Team Design System” devra être constituée aussi bien de designers que de développeurs ainsi que de sponsors.
Il est fondamental d’intégrer la Tech des le départ au risque d’avoir une vision qui restera que centrée équipe Product Design
Au même titre qu’un produit classique, privilégiez une approche MVP et itérative plutôt que de vouloir attaquer tout de front. Vous aurez tout le loisir de faire évoluer votre Design System au fil de son cycle de vie.
Nous avons creusé les bonnes pratiques sur les design systems ici :
- Pourquoi créer un Design System ?
- Comment initier un Design System lorsqu’on dispose de peu de ressources ?
10 - Bien définir les Definitions of Done et Ready (DOR et DOD) dans les User Stories c’est la clef !
Alors on va procéder à un petit rappel des 2 (ça ne fait jamais de mal de réviser ses basiques 😁) :
- La Definition Of Ready (autrement appelé DOR), c’est la liste d’éléments attendus qu’une user story (US) doit rassembler pour être candidate au développement.
- La Definition Of Done (ou DOD) c’est la liste d’éléments attendus pour que le développeur puisse se dire “ok, c’est bon je peux passer à autre chose” (une autre US)
Il est hautement recommandé d’ajouter une composante design à ces 2 définitions afin d’éviter les incompréhensions et de vous assurez de la fidélité des designs mis en production.
Quelques exemples de mentions Design pour une Definition of Ready :
- Cas particuliers (listes vides, erreurs, chargement, etc.)
- Spécifications détaillées des éléments d’animation et/ou de micro-interaction (idéalement sous forme de prototypage ou user flow)
- Composants utilisés du Design System (Hour-picker, dropdown type, élément de formulaires, etc...)
Même chose pour les Definition of Done :
- Test des cas particuliers
- Conformité des interfaces et interactions
- Validité des composants Design System
11 - Communiquer ! Communiquer ! (channel dédié, au sein des équipes, partage efficace (Research, DS, Figma)
De manière générale, il vaut mieux faire un excès de communication que le contraire.
Si vous venez de terminer la restitution d’une phase de recherche, partagez-la à votre équipe de développement ! ( et même aux sponsors et corps métier...) Ainsi, cela leur permettra de mieux appréhender les décisions design suite à ce test et de s’immerger petit à petit dans votre processus produit.
La clé d’une collaboration efficace entre designers et développeurs est de communiquer le plus possible ensemble pour éviter, autant que possible, les interrogations, doutes ou malentendus. (et faire itérer pour rien et prendre du temps à tout le monde...)
Channels Slack dédiés, partage de documentation, documentation exhaustives dans Figma, outil commun de Design system... tout est bon à prendre pour fluidifier vos échanges !
12 - Se mettre d’accord dès le départ sur le MVP
“If you're not embarrassed by the first version of your product, you've launched too late”.
Cette citation n’est pas de nous, mais du fondateur de LinkedIn, Reid Hoffman. Et pour le coup, nous sommes carrément d’accord.
Pour le design, c’est comme pour le produit en général, mettez-vous d’accord avec vos développeurs sur ce qui est essentiel de shiper lors de la V1.0. Prenez le temps de vous accorder avec votre équipe technique sur ce qui est vraiment impactant pour l’utilisateur et/ou le business. Prenez le temps de poser les jalons de votre produit et n’oubliez bien souvent “simple is better”.
Il vous est bien sûr recommandé de travailler sur une vision moyen-long terme, qui sera challenger à chaque itération, mais qui vous permet de concevoir votre MVP en proposant des idées potentiellement viables dans le temps et une ligne conductrice.
Soyez juste bien clair quand vous le présentez à votre équipe Tech (MVP, vision cible)
Maintenant que vous avez tous les éléments à disposition, il n’y a plus qu’a vous lancer ! Bonne collab 👋
Cet article a été co-écrit par Damien Huguet, Louise Gazeau et Thomas Vidal.
