Simon Gomez, Réconcilier le design et les développeurs dans un contexte d’agence

Transcription de l'épisode : "Simon Gomez, Réconcilier le design et les développeurs dans un contexte d’agence"

Terry : Salut Simon.

Simon : Bonjour.

Terry : Merci de me recevoir chez vous à Toulouse, chez Humans. Aujourd'hui, on va parler de design et de développement, donc l'interaction un peu entre ces deux disciplines, notamment dans le cadre de la conception et du développement de produits digitaux. Ça va être un peu la trame de fond de cet épisode. Mais avant de rentrer dans le vif du sujet, pour ceux qui ne te connaîtraient pas, je te propose de te présenter et de présenter Humans.

Simon : Merci Terry, merci de m'inviter à nouveau sur ce podcast. Simon Gommet, je suis fondateur et designer au sein de l'agence Humans. Humans est une agence de design et de conseil spécialisée dans le numérique et plus particulièrement sur ce que l'on qualifie d'application d'usage. c'est-à-dire des applications et des logiciels, des portails clients, des sites internet qui vont avoir pour vocation un usage, pour lesquels les gens vont venir soit réaliser des tâches, soit venir chercher de l'information dans un objectif de réaliser certaines tâches, certaines actions. On est vraiment spécialisé sur cette thématique-là. plutôt que, chose que font certains de nos confrères, de travail sur des sites de communication ou du site marketing. Nous, notre métier, c'est vraiment les applications mobiles, les logiciels métiers, les portails clients. Plus c'est complexe, plus on aime et mieux on arrive à accompagner nos clients sur ces thématiques-là.

Terry : Ok, très clair. Du coup, par rapport à ça et au sujet d'aujourd'hui qui va être donc comment tu maximises les interactions entre le design et le développement, ça vaut le coup de préciser, comme tu viens de le dire, que vous intervenez en tant que prestataire de service sur la partie du coup conception, design, et donc ça va être aussi sous cet angle-là que tu vas partager, j'imagine, pas mal de retours.

Simon : Effectivement pour préciser comment nous on travaille, on est une agence indépendante et on va accompagner des clients qui vont venir nous voir dans l'objectif de soit réaliser une conception d'une solution numérique de A à Z, soit venir juste travailler sur une partie spécifique de l'application. Et donc nous notre réponse elle se fait au forfait avec un listing d'activités qu'on définit en début de de mission, on identifie un planning et on identifie également un budget et à partir de là on contractualise avec un cadre qui est bien borné et qui est limité à en général une volumétrie soit de fonctionnalité soit d'écran. Et donc du coup une fois qu'on a finalisé notre mission, on transfère tout notre savoir en général à des équipes de développement qui peuvent être soit internes à l'entreprise parce qu'elle a ses développeurs en interne soit qui peuvent être en partenariat avec des agences de développement qui en général sont des structures, des petites structures on va dire, bon des petites structures dans le développement c'est souvent entre 10 et 50 personnes et on va, parce qu'on a répondu ensemble aux besoins de clients. Donc voilà, soit ça se fait en collaboration avec des développeurs qui sont intégrés à l'entreprise, soit avec des équipes de développement qui sont externes à l'entreprise et avec qui on a répondu d'une prestation globale en co-traitance.

Terry : Ok, du coup ce que je te propose c'est déjà sur... je vais te prendre un exemple du coup par rapport à ce que je comprends de comment vous fonctionnez et puis tu me dis par rapport à ça potentiellement déjà est-ce que je suis dedans et puis les problématiques que vous aurez pu rencontrer sur ces interactions. Donc on va dire je me positionne dans le cadre d'un ministère gouvernemental qui a une plateforme digitale pour permettre aux gens de déclarer et de pouvoir suivre leur prime rénov, sujet qui a fait l'actualité il y a quelques temps. Dans ce contexte, je viens vous voir, vous allez travailler sur la partie design ergonomie, parcours utilisateur, comprendre d'un point de vue fonctionnalité et comment je vais interagir avec la plateforme pour pouvoir répondre à mes besoins. Vous allez donc fournir différents livrables que tu pourras repréciser. Et ces livrables-là, ensuite je vais les donner à une autre boîte, puisque je suis un ministère gouvernemental donc je n'ai pas de développeur on va dire en interne, qui elle va développer. Et là, dans cet exemple, ma compréhension, je me dis que j'ai un gros risque de perdre d'informations entre les développeurs et l'agence qui m'a construit toute la conception de la plateforme. Est-ce que déjà c'est une problématique qui te parle ?

Simon : C'est vraiment une problématique qui nous parle, surtout quand on est dans le contexte que tu décris et que par exemple l'entreprise de développement qu'ils ont choisi, on ne la connaisse pas et on n'est pas répondu conjointement avec eux. Donc ça c'est déjà arrivé chez nous où le client réalise des sourcing de ces deux métiers de manière complètement indépendante. et nous on sait pas du tout qui c'est qui va prendre la suite de notre travail et même parfois ce prestataire là n'a pas été choisi avant que nous on finisse notre travail parce que notre client attend que le travail de design soit fait pour pouvoir rédiger son cahier des charges et sélectionner un candidat qui va faire la partie développement. Donc oui ça arrive, c'est une problématique qui est importante pour nous et c'est de là aussi où viennent tous ces sujets de réflexion, d'amélioration de la collaboration entre équipe design et équipe développement pour nous. Parce que comme tu l'as dit, entre ce qui se passe c'est qu'il peut y avoir une partie du savoir qui est plus maîtrisée parce que le design arrive à un instant T fait sa mission qui va durer entre 2 et 3 mois, et parfois il peut même y avoir un gap de 2-3 mois avant que le développeur arrive et prenne les éléments. Parfois ça commence de suite, mais l'équipe de développement va travailler sur la première fonctionnalité qui va leur prendre 1 ou 2 mois, et nous on en a travaillé sur une dizaine, sauf que pendant que le développeur travaille la première fonctionnalité on est là, encore on est toujours dans du suivi d'intégration et on est encore dans la boucle du client donc on peut répondre mais on va aussi petit à petit disparaître, le client va ne plus nous solliciter et puis parfois les développements s'éternisent sur des temporalités assez importantes. Effectivement, il y a toujours l'enjeu d'arriver à voir comment on arrive à documenter le design. C'est toujours mieux qu'un côté client. Il y a des gens qui ont le rôle de gestion de produits, peu importe comment on l'appelle. mais au moins quelqu'un qui a suivi le déroulé de la conception et qui est capable de la restituer, de la comprendre et d'expliciter certains faits d'interaction et également les règles métiers parce que pour le coup Autant si nous on définit les interactions entre les pages, tout ce qui est de l'ordre des règles métiers, c'est pas à nous en tout cas de le définir et c'est souvent le client côté projet qui va porter cette information à l'équipe de développement et donc si personne n'est là pour la traduire, ça peut vite être un peu catastrophique.

Terry : Et du coup, ça c'est un premier point très clair que tu dis d'avoir en interne dans l'entreprise quelqu'un qui va pouvoir garder un minimum de ce qui aura été fourni en termes d'informations par l'équipe design pour être capable d'expliciter tous ces livrables-là quand ils vont être passés à l'équipe de développement. Avant d'aller un petit peu plus loin sur ce sujet, est-ce que tu pourrais un peu caricaturer des livrables type et les activités type que cette phase de design dont on parle, à quoi elle correspond ? Parce qu'encore pour repréciser, c'est important je pense d'insister sur cet épisode.

Simon : À la.

Terry : Différence avec des boîtes qui sont des pure players, qui ont des équipes totalement internalisées, autant tech, produits, design, et qui du coup ont des modes de fonctionnement qui sont déjà largement documentés sur comment travailler sous ce format. Là ce qu'on aborde comme sujet c'est justement comment tu apportes ces compétences de la tech dans des boîtes qui sont pas des pure players mais qui ont besoin de s'outiller d'un point de vue digital, mais qui vont pas du coup recruter des gens pendant toute une carrière juste pour ça, pour s'outiller. Et donc c'est comment on amène le mieux de ce qu'on connaît de ce monde sur un format service. Et donc ma première question là par rapport à ça c'est, voilà vraiment, du coup d'un point de vue service, qu'est-ce que vous livrez lors d'une presta quand vous faites la conception d'une plateforme par exemple pour le sujet par exemple Primera.

Simon : Effectivement, je vais peut-être apporter une précision, t'en as un peu parlé pour que ça soit bien clair. Les typologies de clients avec qui nous on travaille, donc on travaille effectivement avec des startups qui sont bien rodées et dans ce cas-là on s'intègre dans leur process interne, mais après la majorité de nos clients ça va être de l'APME, ça va être de l'ETI, ça va être du grand groupe mais on va dire une entité d'un grand groupe qui va pouvoir se permettre de travailler avec un plus petit acteur. ou encore des services publics. Et donc du coup, tous ces gens vont quand même développer des solutions numériques et comme tu le dis, effectivement, ils sont très peu outillés, ils sont très peu... ils sont parfois assez mal informés sur la manière aujourd'hui de travailler. Ils sont encore sur des repères où le design se fait sur Photoshop et l'intégration va passer par des solutions type WordPress, Magento, ce genre de choses. Donc voilà, c'est bien de le préciser parce que pour certains de nos clients, on est loin de la Startup Nation où on parle DesignOps, DevOps, etc. Et donc pour répondre à la question sur les grandes typologies livrables, donc déjà nous, on va découper notre mission en quatre grandes étapes. Et en fonction de ce qu'on a vendu à nos clients, on va plus ou moins livrer à certaines choses. Donc la première étape, c'est la phase de découverte. Donc pour nous en tant que designer, avant de rentrer dans la conception, on a vraiment besoin de comprendre le métier de la personne, les typologies d'utilisateurs qui vont venir. naviguer sur les solutions qu'on va imaginer, son business model parce qu'on a besoin de comprendre si c'est une logique d'abonnement, si c'est une logique de payer à un instant T, si c'est pas une logique d'abonnement mais que par contre il y a une logique publicitaire derrière avec mettre de la pub ou alors si c'est un contenu 100% gratuit que l'objectif c'est juste capturer du lead. On a vraiment un peu, il y a des une infinité de possibilités sur comment monétiser son service. Donc on a vraiment besoin d'avoir ce triptyque là entre c'est quoi mon métier, c'est quoi mes utilisateurs, leur contexte, leurs attentes et les actions qu'ils vont vraiment réaliser. Parce que comme nous on est dans une logique en général d'usage, on ne va pas spécialement chercher à comprendre qui sont nos utilisateurs d'un point de vue marketing, ce qu'ils aiment, ce qu'ils n'aiment pas. Nous on va plus se concentrer sur même une logique job to be done, quoi qu'est-ce qu'ils viennent faire et c'est quoi les rôles entre guillemets qu'on va avoir et les fonctionnalités clés de chacun. Et après cette logique business, donc comment ça va marcher. Et après on va y ajouter la notion de technique, c'est dans quel cadre technique cette solution va être développée ? Est-ce qu'il y a des contraintes à avoir ? On pourra reparler un peu plus tard des contraintes parce que j'aurai plein de choses à raconter. Mais voilà, l'idée c'est vraiment de faire cette phase de découverte et comment on la documente, donc ça tout dépend de qu'est-ce qu'on a vendu au client. Donc si on a vendu une phase de recherche à Mons, c'est-à-dire que c'est nous qui allons collecter toute cette information-là, on va en général délivrer un rapport, un rapport qui va décrire la synthèse de la recherche qu'on a pu faire. Souvent c'est de l'observation de terrain, c'est des questionnaires qui sont diffusés en ligne, ça va être tout un tas d'informations, de l'étude d'analytics pour identifier les pages les plus vues, les fonctionnalités les plus utilisées. Donc voilà, en général on rédige un rapport, une quarantaine, cinquantaine de pages, ce rapport est toujours présenté oralement aux équipes clients et quand on ne fait pas ça, on va aller quand même faire cette phase de découverte sauf qu'on va partir des hypothèses que va nous donner le client. Donc au lieu que nous on aille chercher l'information, on a des grosses checklists de questions Et on pose des questions aux clients pour aller avoir des réponses à tous ces points-là qui nous permettent d'avoir cette vision un peu exhaustive du contexte dans lequel on est et de comprendre ce qu'on a besoin de comprendre pour faire notre métier. On n'a pas besoin de devenir des experts comptables, des experts du bilan carbone, des experts de la RPD, etc. de comprendre les logiques d'usage, la manière d'organiser et de structurer l'information, et un peu les fonctionnalités clés. Et à partir de là, ce qui est bien dans notre métier, en tant que prestataire de service, contrairement à quand on travaille dans une seule entreprise, c'est qu'on a un panel de secteurs d'activité et de typologie de clients qui est énorme. Et on peut vraiment faire plein de passerelles entre un bilan comptable classique avec un bilan comptable d'un bilan carbone. Ce sont deux types de clients pour lesquels on travaille. Au final il y a des similarités énormes entre la manière de structurer les choses, de penser, de fonctionnalité et tout ça va nous servir pour améliorer les produits. Mais je m'éloigne un peu de mon sujet. Donc la première phase c'est la phase de découverte. En général c'est bien souvent un rapport et un rapport qu'on peut donc du coup partager avec les équipes même si le mieux c'est que le développeur puisse être là dans les échanges parce que ça lui permettra de se nourrir en entendant lui-même ce que le client a à dire surtout quand on le fait dans une logique d'hypothèse parce que c'est une heure, deux heures d'échange, on va assez vite. Après on a une deuxième phase, c'est la phase de définition. Donc là c'est une phase où on va rentrer dans des éléments un peu plus stratégiques où on va définir avec le client la structuration de sa solution, le travail sur les parcours utilisateurs, le travail sur l'arborescence de la structure. Donc on va, entre guillemets, on prend tout le savoir qu'on a eu dans la première phase et on commence à le schématiser. pour essayer de vraiment mettre par écrit les parcours par lesquels vont devoir passer les utilisateurs pour réaliser les différentes actions que la solution doit proposer. Une fois qu'on a modélisé ça, on n'a toujours encore rien inventé, c'est juste pour qu'on se mette bien d'accord avec le client sur le périmètre que doit couvrir la solution. Ce qu'on essaye vraiment de faire à ce moment-là, c'est d'avoir la vision la plus exhaustive du produit. Même si on va au-delà du périmètre qu'on a contractualisé, nous on a besoin de l'avoir parce que plus on pense le produit sur du long terme, mieux on arrivera à travailler une architecture de l'information qui soit évolutive et qui évitera de remettre en question certains choix techniques qui ont été faits. Donc on a toujours l'idée, toujours on dit, on imagine le produit au maximum que vous êtes capable de l'imaginer aujourd'hui. On ne va pas partir du principe que ce sera exactement ça mais au moins on a cette vision là, on sait où va aller le client et après on arrive à identifier bon ok ce périmètre là c'est le MVP et donc nous après la suite sera focalisé sur ce périmètre là. Et donc là c'est aussi, donc là les typologies de livrables qu'on va avoir, c'est des livrables qu'on appelle des parcours utilisateurs, des user flows, des wire flows, des structures de navigation. Imaginons un dashboard classique avec un menu latéral sur le côté, on va essayer d'identifier les différentes entrées et on va on va illustrer toutes les fonctionnalités qu'il y aura derrière chacune des entrées. Donc déjà ça permet à un développeur d'avoir une vue un peu plus précise sur l'étendue de la structure de la solution, sur son périmètre fonctionnel, on n'est pas vraiment dans un niveau de détail très micro mais au moins il a une vision macro. Et après surtout ce qu'on fait, c'est qu'on va faire la partie Wireflow. Donc ça on le fait beaucoup dans les applications mobiles mais aussi dans les applications métiers. C'est qu'on crée des petits carrés qui représentent des pages et on va mettre sur une grosse carte toutes les pages et toutes les interactions qu'il va y avoir avec les pages. Comme ça, le développeur va vraiment avoir la vision beaucoup plus précise de l'étendue de la solution au moins d'un point de vue fonctionnel. Donc proposer déjà une architecture technique c'est suffisant et lui va pouvoir commencer à affiner ses choix technos, la manière dont il va architecturer toute sa plateforme technique. Et donc ça c'est la fin de la phase de découverte. de définition et après on a une phase de design où là on va vraiment rentrer dans de la conception plus pragmatique où on va travailler en général d'abord sous la forme de wireframe pour valider le contenu de toutes les pages, toutes les interactions, toutes les fonctionnalités. Et une fois qu'on a fait ça, en général il faut poser une direction artistique, donc on va travailler sur deux ou trois pages, soit on doit créer le style graphique, soit il y a une charte graphique qui existe et donc on doit En général, il faut toujours qu'on extrapole un peu parce qu'il y a besoin de redéfinir la manière dont la marque doit s'exprimer d'un point de vue numérique et notamment sur des outils numériques. Donc après, une fois qu'on a défini la direction artistique, on fait le design des écrans et le livrable final de cette partie-là, c'est les maquettes en général de tous les écrans, de tous les états qu'on a identifié la one année, c'est-à-dire les chemins nominaux et toutes les exceptions, les cas d'erreurs, les états vides, les ouvertures des différents composants, des dropdowns, des daypickers. On essaye de vraiment matérialiser l'ensemble des composants et des interactions. On va livrer également un UIKit qui va regrouper l'ensemble de ces composants et de leurs états. et ensuite on fait ça sur Figma et donc au bout d'un moment on invite le développeur sur Figma sur lequel il pourra retrouver l'ensemble des informations et après en fonction des typologies de développeurs on va dire qu'ils sont surtout de l'aisance qu'ils ont avec l'univers du graphisme certains sont très autonomes d'autres ont aussi besoin qu'on exporte tous les éléments et qu'on leur mette à disposition sur un drive les SVG, les images, etc. Ça c'est vraiment de l'échange pour bien comprendre qu'est-ce que le développeur veut parce qu'en fait on a tellement d'avis et de demandes différentes qu'aujourd'hui on s'adapte en fonction du niveau du développeur qu'on a en face. qui peuvent vraiment être très différents d'une entreprise à une autre, d'un développeur à un autre, parce que l'intégration est quand même le parent pauvre du développement, surtout dans les applications d'usage. On va dire, elle est très très bien maîtrisée dans des applications, dans des sites marketing, voilà, des sites où les aspects gratuits graphiques sont le plus important. En général, il y a des ressources qui savent bien gérer l'intégration. Quand on est sur des outils plus applicatifs, c'est beaucoup plus rare, donc il y a des vrais niveaux dans la partie intégration que doit maîtriser normalement un développeur front-point.

Terry : Merci déjà pour cette clarification donc on va venir après sur cette partie là comment du coup fluidifier ce passage d'informations. Je vais résumer à ma manière comme je l'ai compris on va dire le package, le full package donc il y a une première étape qui est en fait aller comprendre là où vous mettez les pieds en termes de contexte métier, de besoins utilisateurs qu'ils étaient déjà collectés ou en tout cas vous allez participer à cette collecte et vous fournissez un premier rapport donc qui explique un peu voilà le périmètre sur lequel, enfin voilà les problématiques sur lesquelles il va falloir qu'on apporte des solutions. Ensuite, vous avez une deuxième étape. Au départ, je n'avais pas cerné, je l'avais mélangé avec la troisième, mais votre deuxième étape, c'est plutôt exploratoire par rapport à l'idée des solutions que vous allez pouvoir proposer et également donner une vision assez éclatée de toutes ces différentes solutions. Et enfin, une troisième étape, qui là est beaucoup plus productiviste on va dire où vous allez commencer par des wireframes du coup moyenne fidélité ou basse fidélité pour aller vers de la haute fidélité sur Figma où à la fin vous pouvez sortir du coup à la fois les interactions entre les écrans et les écrans haute fidélité et potentiellement du coup des feuilles de style CSS ou autres si on est sur du web.

Simon : C'est ça.

Terry : Donc par rapport à ça aussi, je pense qu'il est important aussi de bien contextualiser par rapport à d'autres épisodes que j'ai pu faire sur le podcast, qui étaient plus liés vraiment au product management dans le sens où on parlait de construire des produits sans vraiment savoir quel est le problème, donc d'abord aller chercher des problèmes et du coup avoir des aspects parce que le métier du UX peut s'appliquer de plein de manières différentes. Je pense notamment à un épisode récent que j'ai fait autour du design sprit avec Marie où on parlait de l'importance de l'UX designer plutôt en tant que facilitateur pour aller trouver des bons problèmes à résoudre. Là, ce dont on parle avec toi Simon c'est vraiment Vous venez pas challenger, en tout cas pas en profondeur, le problème que le client veut résoudre. Ce que vous venez faire c'est apporter une expertise d'un point de vue conception d'outils digitaux pour qu'ils soient utilisables, qu'ils soient au top en termes du X et qu'ils répondent au mieux au problème auquel le client voulait répondre. Vous êtes pas là en tant que challenger ou en tout cas pas trop fort du problème auquel il veut répondre.

Simon : Exactement, nous on est vraiment dans une temporalité très opérationnelle. En général, on ne fait pas du design d'innovation ou du design de service où on va essayer de réimaginer ce que tu viens de décrire. Donc nous, quand un client vient nous voir, il doit produire un outil et il a une problématique. Par contre, on ne va pas challenger sa problématique mais on va challenger la manière dont il aborde sa problématique. et on va challenger la manière dont l'outil qui va répondre à cette problématique va être structuré et organisé. S'il a eu une idée qu'on juge peut-être pas bonne ou qu'on se dit qu'on ne comprend pas, on ne va pas y mettre d'avis sur son idée globale, on va juste essayer de l'accompagner à faire en sorte que cette idée-là soit la plus pertinente et la plus structurée pour que les autres utilisateurs arrivent à s'en servir.

Terry : Oui très clair et ça fait le lien aussi avec ce que tu disais sur le fait que vous travaillez sur des applications métiers donc parce que c'est des applications qui ont ces besoins d'usage là et aussi pareil pour bien que les auditeurs comprennent c'est qu'on n'est pas sur vous n'êtes pas juste enfin juste je sais pas si j'ai besoin de dire juste mais vous n'êtes pas visual designer uniquement sur en gros amener une couche de vernis sur des produits très vous êtes vraiment là pour une expertise dans laquelle il y a du visual design mais pas que, pour maximiser l'usage qui va être fait des produits digitaux.

Simon : Et c'est pour ça aussi qu'au final le visual design c'est à la toute fin de ce qu'on produit et qu'on a ces deux premières étapes qui sont plutôt liées à une réflexion et à une partie plus intellectuelle on va dire, des choses où on est intellectuel et stratégique, où on est là pour accompagner notre client à à organiser, à restructurer, à repenser, à questionner, à challenger même parfois on a challengé certains de nos clients sur pas spécialement leur business model mais plus la manière d'amener un abonnement qui t'a les accompagnés à dire que ça serait pas mal qu'il y ait 15 jours d'essai et qu'à partir d'un certain moment tu puisses venir dire l'essai est terminé maintenant vous devez payer plutôt que de débloquer dès le départ avec du paiement. On va vraiment Challenger à une échelle beaucoup plus opérationnelle et c'est pour ça aussi que nous les problématiques techniques sont beaucoup plus fortes chez nous et beaucoup plus importantes dans notre compréhension parce que ce qu'on fait, il faut que ce soit réalisable. On n'est pas là pour faire un truc qui soit de l'intention ou qui soit une idée qui sera creusée plus tard. Nous en général, cette partie là a déjà été faite avant et on est là pour, voilà, on est dans le concret, on fait un outil qui demain doit marcher.

Terry : Très clair, mais du coup maintenant on peut rentrer, enfin je pense que le cadre du coup on l'a bien posé, donc tu parlais à plusieurs moments, tu as parlé de faire intervenir les développeurs, notamment tu le disais même dans l'étape 2, donc on est dans la phase de design, mais si on reprend un peu le cas extrême, le moins idéal, où tu as intervenu, vraiment en amont et l'équipe de développement elle n'est pas là. Donc pour revenir à ce qu'on disait au début, donc toi ce que tu recommandes aux entreprises c'est d'avoir une personne quand même en interne qui va pouvoir suivre cette phase de conception avec vous et être capable de l'apporter aux développeurs. Si on devait un peu dérouler sur ce sujet, quelles sont un peu toi les choses que tu as vu qui marchaient, des petits tips pratiques justement pour d'autres personnes qui sont un peu dans.

Simon : Des situations similaires ? Ce qui marche c'est que la personne qui suive le projet ait du temps dédié à ça et que ce ne soit pas une sorte de petite tâche annexe qu'elle doit faire parce que le chef d'entreprise lui a dit, c'est toi qui vas suivre le projet, tu participeras aux réunions et tu feras le lien entre les différents prestataires et qu'au final cette personne, le seul moment où elle travaille sur le projet, c'est pendant la réunion qu'on fait. Et donc ça c'est vraiment le pire des cas parce que déjà nous ça nous permet pas d'avancer vu qu'à chaque réunion on arrive avec des choses vu qu'on travaille de manière très itérative donc en général on se voit toutes les semaines et quand la personne elle va uniquement réfléchir à la problématique pendant la réunion c'est souvent complexe et puis ça avance pas et puis c'est très dur pour elle de se projeter aussi sur du plus long terme. Parce que nous ce qu'on fait c'est qu'on va penser le projet dans une vision assez lointaine, à 5-10 ans et il faut aussi que ces personnes là aient cette capacité à anticiper ça et à voir jusqu'où va aller le produit et donc aussi il faut que ces personnes là soient quand même un minimum connaissent un minimum l'univers de la technique, du produit numérique, parce que parfois on a certains clients qui ont de très bonnes idées, ils se lancent sur des sujets parce qu'ils sont experts métiers dans leur domaine, mais pas du tout digitalisés, et ils savent qu'il y a une opportunité de ouf S'ils arrivent à numériser ça, ils ont raison. Par contre, ils ont zéro code du produit numérique. Et donc du coup, là, ça c'est souvent très compliqué parce qu'ils arrivent bien à comprendre qu'il va y avoir des usages. Les fonctionnalités, tout ça, en général, ça se passe assez bien. Au contraire, ça se passe quand même très bien parce qu'ils ont une très bonne connaissance de leur métier, donc ils savent vraiment comment le métier fonctionne. Il n'y a pas à réimaginer quelque chose. C'est juste des processus qui sont non numérisés qui doivent être numérisés. Il n'y a personne quand il faut imaginer le support, le service client, le marketing, la communication, le déploiement sur des stores, la maintenance, tout ça c'est des notions qui leur sont complètement méconnues et qui se prennent de plein fouet en général au moment où les premiers développements commencent. Parce que bien souvent ces gens-là en plus ils pensent que le développement en un mois et demi c'est fait et souvent, enfin souvent, et ça arrive que certaines entreprises leur disent oui oui, ça sera fait. Et puis bon, tu reviens 6 mois après, il n'y a toujours rien qui est sur le marché parce qu'entre temps, la réalité des choses fait que c'est impossible de faire à ça. Donc voilà, c'est sûr que côté client, ça demande à ce que la personne, elle ait du temps à y consacrer et qu'elle ait un minimum de sensibilité à ces univers-là qui, dans beaucoup d'entreprises avec lesquelles on a travaillé, sont assez assez nouveau. Il y a certaines industries qui ne sont pas du tout numérisées ou en tout cas avec une approche du numérique très à l'ancienne mais qui fonctionne très bien.

Terry : Ok, du coup si on va partir du principe que tu as cette personne en face de toi qui a à peu près ses caractéristiques du côté client, du coup vous, est-ce qu'il y a des éléments particuliers que vous allez lui donner pour qu'ensuite, au-delà de suivre le projet, et vraiment d'avoir du temps à y consacrer, de comprendre les codes du digital et qu'est-ce que ça veut dire que faire un produit numérique, tu as touché du doigt un sujet que j'aimerais aborder aussi, c'est la partie support parce que c'est quelque chose dont on parle, on pense souvent, oui c'est bon je comprends la tech, du coup je sais ce que ça veut dire que de faire un produit digital, mais il y a aussi une partie support client et marketing, marketing on entend parler, je trouve que le support client appelle à ceux qui écoutent et qui voudraient venir parler de support client sur le podcast, C'est un sujet, je trouve, qui n'est pas beaucoup traité et qui est crucial, en fait, dans le succès derrière de tout produit digital.

Simon : Fais-moi une mise au pincé, mais j'ai une recommandation de lecture sur ça.

Terry : Ok, très bien. Je te redemanderai à la fin. Du coup, sur... Donc, mettons que tu as cette personne qui a ces codes du digital et qui est impliquée sur le projet, mais malgré tout, vous allez devoir travailler vraiment de manière autonome avec cette personne sans avoir de contact avec l'équipe de développement. quelles vont être un peu les clés que tu vas pouvoir donner à cette personne et après on pourra passer dans un autre cas que tu aurais pu rencontrer aussi où tu as l'équipe de développement qui est externalisée mais qui peut.

Simon : Être là à différents moments. Parce que le cas là où l'équipe de développement elle n'est pas du tout là, il reste quand même assez rare. Aujourd'hui en général c'est quand même soit c'est une entreprise qui vient de voir qui a les développeurs en interne, soit on fait de la co-traitance avec un partenaire technique Donc on a quand même les développeurs plus ou moins dans la boucle qui sont identifiés. Le cas où le développeur n'est pas du tout identifié, il existe, mais c'est vrai qu'il est de plus en plus rare. Mais dans ce cas là, nous ce qu'on fait en fait c'est que dans notre prestation, on va vendre nos livrables tels que je les ai définis. Par contre, on ne va pas ajouter une espèce de rédaction de cahier des charges où on livrerait 50 pages, où on détaillerait tous les écrans, toutes les interactions et toutes les règles métiers, parce qu'on considère que ce n'est pas notre rôle de rédiger ce type de documents. Au final, on serait vraiment... On ne serait pas capable de faire un document qui aurait du sens parce qu'on ne connaît pas les règles de gestion. Il y a plein de choses qu'on ne maîtrise pas quand on fait de la prestation de service. On se contente juste de faire la partie ergonomique, interactivité. et visuel. Donc ce qu'on fait, c'est qu'on essaie quand même de décliner au maximum les scénarios qu'on a identifiés. Donc en général, quand je vous disais qu'on matérialisait sous la forme de petits rectangles avec des flèches tous les écrans, en fait tous ces écrans-là, on les design. Et donc quand une fonctionnalité doit passer par 4 écrans et que dans un écran 1, je clique, ça ouvre un champ déroulant, on va faire l'écran 1, le champ déroulant est fermé, l'écran 2, le champ déroulant est ouvert, l'écran 3, la page qui a ouvert une fois que tu as cliqué sur un déroulant, etc. Et on va faire aussi le cas où, si on prend une liste, le cas où cette liste elle est complète et le cas où cette liste est vide pour avoir le cas d'erreur, l'empty state, l'état vide. Donc en fait, on essaye vraiment de maqueter l'ensemble des écrans qui sont identifiés pour que le client et une personne qui arrive sur le projet puissent visualiser les parcours par lesquels vont passer les utilisateurs et qui devront être développés. Notre objectif c'est que les développeurs aient la vue la plus exhaustive sur les comportements, qu'ils aient surtout l'ensemble des composants nécessaires et qu'ils n'aient pas à extrapoler ou inventer certaines choses. Et on va également faire, dans certains cas, on fait pas mal de proto aussi, parce qu'étant donné qu'on décline toutes les pages, pour nous après c'est très simple de créer des interactions entre les composants qui vont permettre d'ouvrir des pages. Et pour certains de nos clients, ça les aide à se projeter aussi dans la solution finale. Donc voilà, notre solution c'est vraiment on fait tous les écrans, tous les états possibles et pour que le client puisse pouvoir par la suite donner ces ressources là à ses développeurs et en général quand il y a vraiment un gap qu'on identifie qu'il va y avoir un gap entre le moment où on développe et le moment où on design, là c'est le cas pour certains de nos clients. On a prévenu nos clients que quand ils auraient choisi son prestataire technique, nous on aurait besoin de contractualiser un suivi d'intégration.

Terry : Je trouve ça hyper intéressant même si comme tu me disais c'est pas le cas le plus répandu, le cas où tu as vraiment une séparation complète du design et du dev aujourd'hui. Je trouve ça hyper intéressant le point que tu as dit que vous n'allez pas en fait jusqu'à rédiger un cahier des charges complètement exhaustif et je rebondis sur ce que tu viens de dire parce que le fait justement de ne pas avoir ce cahier des charges totalement exhaustif ça pousse indirectement aussi le client soit à avoir cette personne en interne qui va pouvoir expliquer l'exhaustivité des écrans que vous avez fait, soit de vous faire réintervenir pour pouvoir venir clarifier certains points ou expliquer certaines interactions. Et du coup indirectement, si vous aviez livré ce cahier des charges ultra exhaustif, vous livrez quelque chose qui va un peu à l'encontre des principes que vous voulez mettre en place, donc je trouve ça assez intéressant.

Simon : Puis on ne veut pas avoir cette responsabilité-là de dire qu'on est capable de rédiger un tel document, ne serait-ce que je prenais les cas de la drop-down. La dropdown, en général, quand c'est très technique en plus, les champs qu'on peut avoir, parfois on ne les comprend pas spécialement. On sait qu'il va y en avoir plus de 5 et c'est pour ça qu'on est plutôt parti sur une liste déroulante. Mais par contre, être capable de donner la liste précise au client, c'est métier. On ne connaît pas cette partie-là. C'est là où je disais qu'on a besoin de comprendre le métier, mais on n'a pas besoin d'être expert du métier. Il y a pas mal de choses qui sont de la responsabilité du client parce que c'est métier, parce que c'est lui qui maîtrise le métier, parce que c'est lui qui va devoir peut-être aller interroger certaines autres personnes au sein de l'entreprise pour avoir les réponses et donc en général on serait pas capable de faire un document qui donnerait beaucoup plus de choses au final que nos maquettes et cette logique de bien ne pas faire que de la maquette d'intention, c'est vraiment de la maquette opérationnelle qui décline le comportement précis de toutes les fonctionnalités.

Terry : Yes très très clair du coup donc ça c'était pour le cas vraiment on va dire le plus extrême où il n'y a pas de communication directe entre le design et les prestas enfin les prestas design et le prestas de dev dans les cas que vous rencontrez plus régulièrement du coup où il y a ces interactions possibles tu peux déjà expliquer un peu ce que tu disais là me rappeler ce que tu voulais dire par co alors j'ai oublié les noms mais bref les modes de fonctionnement que vous avez et puis quelles sont les problématiques et comment toi tu enfin comment vous essayez d'y répondre La logique de.

Simon : Co-Traitance c'est qu'on s'associe avec un partenaire, que je vais appeler un partenaire technique, qui a une capacité de développer une solution et soit le client est venu le voir lui, soit le client est venu le voir nous, mais le client il veut un package global, il veut à la finale quelque chose qui marche. Plus c'est technique, plus il passera par un prestataire technique. Plus c'est visuel ou grand public, plus il passera par nous et nous on doit dire qu'on recommande pour ça de passer avec ce prestataire où on donne parfois plusieurs choix. L'idée c'est que c'est le client qui fait son choix de partenaire mais nous on lui recommande certains partenaires parce parce qu'aujourd'hui on a des habitudes avec certains partenaires et puis c'est aussi que parfois c'est un peu la jungle dans les agences et c'est difficile d'arriver à une confiance avec un partenaire donc aujourd'hui on en a trouvé et c'est très bien. Et donc du coup voilà en général quand on fait de la co-traitance c'est qu'on a répondu tous les deux à une demande client et donc notre proposition commerciale s'est identifiée, il y aura Humans et il y aura telle entreprise, Humans fera le design, telle entreprise fera le développement. Donc là, dès le début déjà, quand c'est ce cas là, comme on doit répondre avec une proposition commerciale, on s'est déjà mis d'accord avec le client du coup, enfin notre partenaire pardon, s'est déjà impliqué. dans la réponse parce que lui doit aussi estimer certaines choses, faire des choix, faire des choix technos parce que parfois c'est un élément assez structurant dans le choix du client. Donc le partenaire technique va déjà être dans la boucle et là plus le commercial qui gère ça technique et sera impliqué dans le projet, mieux c'est parce que lui il a déjà le contexte projet, il va déjà faire certains choix, il va déjà poser certaines hypothèses techniques de son côté. Donc dès la phase, même avant de commencer le design, parfois les développeurs peuvent être impliqués et plus ils sont impliqués à ce moment là, mieux c'est parce que nous aussi ça nous permettra de savoir si par exemple ils ont choisi tel techno mais de connaître aussi les contraintes que cette techno peut amener.

Terry : Est-ce que tu peux prendre un exemple concret sur ça, un exemple de techno et de contraintes ? Moi j'en ai en tête mais... Par.

Simon : Exemple, la personne a choisi Angular et comme elle maîtrise bien PrimeNG, elle a pris le framework PrimeNG. Et pour réduire peut-être un peu le coût, ils décident de plutôt utiliser de pas trop custom les composants PrimeMJ. Donc nous, ça nous dit, ok, en fait on va composer avec le style de PrimeMJ, on pourra changer peut-être certaines choses. stylistique mais on va essayer de ne pas s'éloigner de certains composants ou en tout cas de le prendre en compte dans notre réflexion. C'est des choses comme ça en fait.

Terry : Donc Angular pour les moins dev, framework frontend du coup, c'est le framework utilisé pour faire la partie, si on devait vraiment schématiser le design visuel du site on va dire, enfin le design, plutôt la partie visuelle en tout cas pour l'utilisateur. Quand tu parles de PrimeNG du coup, alors je ne connais pas mais j'imagine que c'est une librairie de composants intégrée dans Angular. Et donc ça c'est un point d'ailleurs qui peut faire perdre ou gagner énormément de temps, c'est que soit tu comprends, comme tu viens de le dire, que c'est ça la librairie utilisée, donc il faut essayer de rentrer un peu dans ce cadre quand tu fais la partie plutôt visual design, et même quand même les interactions aussi, tenir compte des interactions par défaut de ces composants. Parce que si tu commences à vouloir trop sortir de ce cadre-là, la customisation.

Simon : Coûte beaucoup plus cher parce qu'il faut tout refaire. Et c'est là où c'est intéressant d'arriver à détecter quelles seront les facilités de la personne qui va travailler dessus avec cette logique de customisation. Moi je suis assez convaincu que tout est possible de faire et je suis assez convaincu aussi qu'il y a des gens qui ne savent vraiment pas maîtriser le CSS et l'HTML Plus on est dans des logiciels d'usage métiers complexes, moins c'est maîtrisé et parfois on voit vraiment des choses qui sont absurdes et on sait que c'est factuellement réalisable parce qu'on fait jamais des choses trop folles sur des applications métiers. on reste sur des composants web en général très classiques. Et donc du coup pour nous c'est aussi important d'arriver à détecter ça, et c'est pour ça aussi que si on travaille avec des personnes qu'on sélectionne, c'est parce qu'on sait qu'elles sont en capacité d'arriver à produire, pas au pixel perfect, mais en tout cas quasi au pixel perfect, les maquettes qui vont être faites.

Terry : Je renuance juste par rapport à ce que tu disais, c'est qu'effectivement d'être capable de customiser dans la mesure du possible, mais le point que tu disais, la première étape pour travailler au mieux possible en co-traitance avec une agence de dev c'est de se mettre d'accord, vous le regard designer allez voir les defs pour comprendre quels sont les technos que vous prévoyez d'utiliser pour aussi pouvoir en tenir compte même si après effectivement il y aura des choses qu'il va falloir que les defs puissent quand même customiser parce qu'il ne faut pas qu'ils te disent non mais ça c'est infaisable parce qu'on a ça et puis c'est comme ça et pas autrement.

Simon : Ouais ça arrive quand même, on a vraiment des gens qui ne maîtrisent pas bien certaines choses, en tout cas qui le maîtrisent dans le cadre qu'ils sont identifiés et on nous demande de suivre stricto sensus ça parce que ça a été vendu aussi, ça c'est quand ça a été vendu, pour réduire le prix ils l'ont vendu comme ça, donc le jeu c'est de rester avec ça, on a eu des projets et puis ou c'était vraiment ça, et après ça se passe bien. En fait, plus on connaît les contraintes en amont, plus ce qu'on va imaginer sera cohérent avec ces contraintes-là. Donc nous, on n'a jamais... Au contraire, j'ai écrit un article qui s'appelait « Les designers et les contraintes ». Et comme on est vraiment dans de l'opérationnel et que nous, ce qu'on veut faire, c'est que ce qu'on imagine soit réalisable, plus vous nous donnez les contraintes en amont, plus on sera content. Parce que la pire des choses pour nous, c'est imaginer des choses qui au final ne sortent pas telles qu'elles ont été imaginées parce que justement on n'avait pas anticipé les bonnes contraintes ou on n'avait pas anticipé certaines choses. Ça arrive toujours.

Terry : Et ça, du coup, c'est très clair ce point de comprendre les contraintes tech. En revanche, la question que je me pose, c'est à quel moment tu peux demander à la tech, à l'agence de dev, quelles sont vos contraintes ? Parce que dans le processus de design, autant peut-être au début ils vont te dire on va devoir partir sur deux apps natives, il nous faut deux devs, on va faire de l'iOS, de l'Android, donc déjà les guidelines en termes d'UI vont être vachement différentes. autant deux semaines dans le design, ils te disent en fait on va faire une app hybride, on va tout faire en React Native et on n'a plus du tout les contraintes qu'on t'avait dit avant. Donc à quel moment tu poses cette question des contraintes ?

Simon : On essaye de le savoir le plus tôt possible. Après on essaye d'anticiper aussi certaines choses. On ne va pas leur demander s'ils sont bons ou pas bons en intégration parce que de toute façon on n'aura pas la réponse. Donc on essaie plus d'anticiper certaines choses et après nous c'est surtout qu'on a aujourd'hui une certaine technicité dans la conception de nos maquettes où on anticipe le dev en fait et l'intégration. Donc c'est aussi beaucoup à nous designers d'être à l'aise avec, pas de connaître par cœur, mais en tout cas d'être très familier avec les capacités d'intégration et de front-end d'aujourd'hui. pour pouvoir pallier justement au fait qu'au début on ne sache pas.

Terry : Oui parce que l'exemple que j'ai pris était un peu peut-être simpliste, mais du coup tu as quand même répondu à ma question avec quand même votre regard technique de designer. C'est-à-dire que là j'ai pris un exemple simpliste, en gros le fait de partir sur une app hybride ou faire du natif en fonction de la complexité, très tôt tu peux le savoir, tu peux le voir si oui ou non il va falloir faire du natif ou non. En revanche tu pourrais par exemple commencer à designer une app web avec certaines technologies sans réaliser tout de suite dans ta phase de conception l'importance par exemple d'un taux de rafraîchissement de certains dashboards. Et ce taux de rafraîchissement va pouvoir faire que peut-être, si c'est critique pour ton client, changer les technos au préalable qui avaient été pensés. Mais du coup c'est là aussi où votre regard quand même un peu technique...

Simon : Oui bah nous on essaye d'anticiper déjà de faire des choses qu'on pense cohérente de manière générale, de façon agnostique à la technologie. Après, ce qui se passe, c'est qu'on n'a jamais la réponse juste dès le début. Il y a toujours un temps où on pense et un temps opérationnel où les développeurs s'y mettent. Et bien souvent, même s'ils sont là dès le début du projet, ils ne peuvent pas penser à tout. Et puis, ils ne sont pas face à la problématique sur ce moment-là. Donc, ce qui est important, c'est que nous, on puisse être présent encore quand ces changements se font pour trouver des compromis. Parce que, bah oui, ok, je vais pas reprendre ton exemple, mais je sais pas, je suis sur un tableau, on avait pensé que c'était du scroll infini, c'est pas possible, il faut ajouter une pagination, bah pas de problème, on va ajouter une pagination, t'as pas le composant, on te fait le composant. C'est aussi se dire que nous on a toujours conscience que ce qu'on imagine, même si on essaye de faire la chose la plus réaliste possible et d'anticiper et d'avoir cette vision technique des choses, on sait que factuellement que quand ça passera en dev, il y aura toujours des surprises, il manquera toujours des états qu'on n'avait pas imaginés et c'est pour ça qu'on reste, on a toujours nous dans nos propositions de suivi d'intégration ces quelques jours. où la personne peut nous solliciter pour justement ajuster certaines choses qui ont été faites, faire des compromis, mais par contre qu'on puisse être là pour la guider dans les choix. Souvent les choix nous sont imposés à ce moment-là parce que c'est la technique qui drive, mais par contre nous au moins on est là pour s'assurer que ces choix-là, la manière de les représenter soit au moins le plus homogène possible dans le rendu global.

Terry : Tu me fais encore rappeler, parce que c'est vrai que des fois j'ai tendance à trop me mettre dans la casquette équipe totalement intégrée, le fait que tu as dit on a aussi un format un peu suivi d'intégration, donc c'est bien de faire rappeler, là on parle bien du contexte du coup, ces deux boîtes distinctes, la boîte design, la boîte dev, et donc tu as parlé le premier point, c'est-à-dire en amont, sur la réponse au projet, les deux qui vont commencer à discuter ensemble, la tech, et le design pour déjà, voilà, un peu cadrer les contraintes techniques et en tenir compte dans le design. Et ensuite, ce que tu dis, c'est qu'une fois que le livrable design dont tu as parlé au début, ils sont complètement livrés, il y a aussi une phase où potentiellement on peut venir à supporter l'équipe de dev au besoin pour des ajustements, des compléments de composants ou.

Simon : Ce genre de choses. Et par contre, là où on voit que ça change drastiquement, plus on a fait intervenir les développeurs dans le processus de conception, moins on a de changements après. Alors que s'ils ne sont pas du tout venus dans le processus de conception qu'on a conçu avec zéro contrainte, même si on s'est anticipé certaines choses et qu'aujourd'hui on fait vraiment attention à à la manière dont on design. Il y aura beaucoup plus de problématiques après. Et en général, même dans ces cas-là, le suivi est beaucoup moins présent parce que comme ça se fait à des temporalités différentes, c'est pour ça que c'est toujours mieux quand les équipes de développement peuvent suivre l'ensemble des avancées, puis s'être là aux restitutions des wireframes, puis s'être là même en amont aux restitutions du user flow, de tous les choix stratégiques d'organisation qui ont été faits. pour qu'entre guillemets soit on ait une validation de leur part au moment où on le fait, soit qu'ils puissent se questionner et aussi parfois se challenger un peu plus tôt parce que une fois que tu as identifié un problème deux semaines à l'avance avant de parser en tech, tu as le temps de t'y reposer dessus, tu as le temps de chercher, tu as le temps d'aller regarder s'il n'y a pas des choses qui ont été partagées dans des librairies partager, ça leur permet aussi d'anticiper beaucoup de choses et voilà donc c'est sûr que plus on arrive à intégrer la personne qui va vraiment développer dans la phase de design et de conception, plus pour nous c'est l'assurance que derrière il y aura le moins de remise en question possible.

Terry : Et du coup, si je reprends un peu mon exemple du début dans le cadre de développement d'un site, d'un outil autour de la prime rénov' pour pas que ça me revienne trop cher non plus, parce que j'entends du coup ce que tu me dis. Maintenant, je me mets dans la posture client. Tu me dis qu'il faut que l'équipe de développement puisse être là sur certains ateliers design pour être capable derrière d'implémenter au mieux et puis qu'il y ait le moins de friction possible. Est-ce que d'un point de vue très pratico-pratique, En termes de temps, ça veut dire quoi en fait en termes de surcoût ? Enfin, c'est pas du surcoût parce que c'est du temps gagné pour la suite. Mais du coup, en termes de temps de cette personne à louer ?

Simon : Il peut y avoir plein de réponses possibles. Je vais te prendre deux exemples concrets qu'on a eu sur des projets. Le cas où le développeur est en interne, là en général il n'y a pas trop de soucis pour qu'il se libère une heure par semaine pour pouvoir suivre l'avancée et au contraire en général les clients font venir même eux les.

Terry : Développeurs Une heure par semaine sur combien de semaines ?

Simon : Une heure par semaine sur 8 semaines. Entre 8 et 10 semaines, c'est notre temps d'intervention. Donc ça lui demande deux jours de travail à allouer à cette partie-là. Et après quand c'est des partenaires qui eux n'ont pas anticipé cette charge de travail, Ce qu'on fait c'est qu'on fait des points de synchro avec eux. On fait un point de synchro au début pour faire la proposition commerciale, on fait un point de synchro une fois qu'on a bâti le parcours utilisateur et les fameux rectangles et flèches dont je vous parlais là, cette vision schématique qu'on appelle user flow. Donc on présente, en général on se met d'accord, d'abord d'accord avec le client dans ce cas là parce qu'il y a une part fonctionnelle qui est importante et qui doit primer parce qu'on est sur des parcours et des usages. Donc pour nous c'est le fonctionnel parcours qui doit primer. Et après on le présente à l'équipe de tech pour qu'elle puisse avoir la vision la plus exhaustive. Et ensuite on fait des wireframes et là soit on montre des wireframes avant aux équipes de dev, soit même les wireframes en général on les montre d'abord au client et après une fois qu'on a fait le lot wireframe on va aller le présenter à l'équipe de dev pour qu'elle puisse voir le wireframe, qu'elle puisse comprendre, qu'elle puisse avoir la première, elle ça sera sa première découverte de l'outil. En général c'est une réunion de 1h à 2h où elle va poser plein de questions, elle va nous faire aussi ressortir des points à ce moment là que nous on va derrière ajuster ou améliorer. Et en général on repartagera après avec le client qu'on a revu certaines choses pour coller avec les enjeux techniques. Et les clients, ils ne sont pas du tout réflecteurs à ça, même s'ils ont validé un parcours, ils comprennent très bien et ça les rassure même que des changements ont été faits pour des raisons techniques. Jamais un client ne dira non, il suffit de juste expliquer que ça ne marchera pas en ayant fait comme ça. Mais par contre, on a trouvé un compromis qui fait que pour l'usage et l'expérience utilisateur, ça ne l'affaiblit pas et que par contre techniquement, ça sera beaucoup plus fiable.

Terry : Très très clair, rassurant aussi je pense même d'un point de vue client quand tu dans le cas donc tu disais où le dev est en interne mais ça représente en gros sur deux mois, deux mois et demi de design ça représente deux jours de ce dev qui va pas faire du dev mais en fait qui va être là pour pouvoir assurer derrière une bonne implémentation je pense que c'est largement entendable et j'imagine que les bénéfices enfin comme tu l'expliquais les bénéfices derrière ils sont.

Simon : Les boîtes de tech avec qui on travaille et qui ne travaillaient pas avant avec des agences de design ou qui ont pu travailler avec d'autres, ils ont toujours la même réponse, c'est qu'ils nous disent que les bénéfices sont énormes pour eux parce que quand le produit arrive en dev, il est cadré parce que eux aussi, c'est des prestataires de services et donc eux aussi ils facturent avec une certaine volumétrie. Peu importe comment elle est calculée mais il y a toujours une certaine volumétrie. facturer avec des sprints quand on est une petite agence et qu'on n'est pas des grosses ESN, c'est de suite plus compliqué parce que les clients qu'il y a en face, il y a très peu de clients type PME ou ETI qui se disent, ah oui je vais acheter un produit et je ne sais pas ce que j'aurai à la fin. Ça ne marche pas. Tous les clients de cette structure-là, donnez-moi au moins une estimation. à 10 000 près, parce que sinon c'est impossible de faire des choix d'entreprise. Elles aussi sont hyper rassurées parce qu'elles savent que le client a pendant deux mois maturé son produit et que quand ça va arriver chez eux, ça sera normalement assez carré. On n'est jamais à l'abri qu'il y ait des changements et c'est normal, on peut les anticiper. Parfois c'est pas normal, c'est juste parce que les typologies de clients qu'on a en face ils sont aussi tellement pas assimilés à ça que parfois ils pensent que ce qu'ils ont imaginé est un petit impact alors que non. Et là c'est tout le travail de l'agence de dev de refaire en sorte que ça sorte dans son périmètre. Mais j'ai oublié la première question, la question originale.

Terry : Non, non, c'était pas une question, tu confortais en fait ce que je disais, c'est-à-dire que les bénéfices de passer sur deux mois juste deux jours, en tout ça fait deux jours à peu près d'un dev qui va pas faire de dev pendant ces deux mois de design, là tu confortes juste l'impact positif que ça a, que le dev soit de l'interne dans une boîte ou que ça soit aussi un prestat avec lequel vous faites des co... j'ai encore oublié la co-traitance, merci. de la co-traitance, donc ça conforte juste cette idée qu'effectivement c'est hyper bénéfique. Est-ce que sur ces sujets interaction, dev, design, il y a d'autres points là que tu voudrais aborder ? Donc là on a parlé de l'aspect prendre en compte les contraintes techniques des développeurs très en amont pour faire des designs qui soient au plus proche de ces contraintes là, impliquer les développeurs aussi sur ces phases de design pour qu'ils aussi à la fois en regard d'un point de vue métier et qu'ils puissent aussi eux maturer d'un point de vue technique, comment ils vont pouvoir répondre à ces problématiques ? Est-ce qu'il y a d'autres choses ?

Simon : Il y a une troisième phase parce que là on a décrit ce qui se passe avant la conception, pendant la conception, et après il y a la phase après la conception, donc on en a un petit peu parlé de ce suivi d'intégration. Donc nous on est à la disposition en général des développeurs pour lui apporter, ah il manquait un toaster, il manquait une modal à ce moment là parce qu'à aucun moment nous dans notre vision on avait imaginé qu'il fallait telle typologie de modal et que finalement pour des raisons de parce que ça fait une requête serveur tatatitatata il va falloir qu'on mette cette modal, ben voilà on te fait la modal, elle ressemble à à ça et après le texte, vous la gérez comme vous voulez au moins, vous avez maintenant le modèle de modal. Et ce qu'on demande aussi c'est que, donc ça c'est comment nous ce qu'on apporte aux développeurs mais ce qu'on aime bien aussi c'est que les développeurs nous fassent part de l'avancement avec de la pré-prod et qu'ils soient ouverts à ce qu'on puisse faire de la recette graphique, c'est à dire qu'on puisse visualiser l'après-prod et lui faire une restitution sur la manière dont on pourrait améliorer certains éléments, là, purement visuels. Il n'a pas utilisé la bonne taille, ce n'est pas la bonne fonte.

Terry : Donc, ta recette graphique, la terminologie recette graphique, c'est une façon très politiquement correcte de vérifier s'ils ont mis le pixel près sur l'écran.

Simon : Et en général on est quand même assez loin même du pixel près. Après c'est là où tout dépend de la capacité d'intégration de la personne. Déjà si elle n'est pas partante pour nous montrer les écrans pré-prod, ça part mal. Parce que ça veut dire que S5 est un loup, qu'au bout d'un moment on ne va pas te montrer parce qu'on n'est pas sûr de nous. Dès que c'est les développeurs qui nous disent « ah mais on vous mettra à disposition la pré-prod », on est déjà rassuré parce qu'on sait que déjà lui, il n'a aucun problème à partager une pré-prod et avoir des retours. Et après, en général, une recette graphique, c'est qu'on fait un screenshot de l'écran et on met des annotations. Et soit, quand ça ne va pas, c'est tout rouge parce qu'on a mis des annotations partout et encore, on ne s'est concentré que sur l'écran. plus important on va dire. Soit c'est quelques points d'ajustement parce que c'était pas tout à fait le bon espacement à ce moment là ou là c'est une taille de titre qui est finalement plus petite et même parfois c'est souvent nous aussi parce qu'entre les tailles de typos des maquettes et les tailles de typos en rendu, parfois on se rend compte que la manière dont ça a été interprété par le navigateur c'est pas tout à fait pareil donc on demande de réajuster certaines choses. Mais quand on arrive à ce niveau de détail là, c'est que c'est tellement bien fait en dev que ça va hyper vite.

Terry : Mais ça aussi c'est un, je pense, parce que là je blaguais en disant c'est une forme de faire du QA sur la partie purement graphique, mais c'est aussi pour vous, comme tu dis, on va de plus en plus vers des mods où en fait, de Figma, t'extrais toutes les variables que tu vas devoir intégrer dans le cas des applis web, mais parfois tu peux avoir effectivement des rendus un petit peu différents par rapport aux navigateurs ou aux versions, et ça permet aussi vous, au niveau design du coup, d'ajuster, même si le dev a fait exactement ce qui était demandé en.

Simon : Fait, Oui, des fois, même sur des couleurs, on a eu des cas où on utilisait un orange et en fait, quand tu le voyais en fonction de certains smartphones, ça vire au rouge. Du coup, ça apportait plus la même information, donc on a légèrement rechangé la teinte du orange pour pouvoir rester sur tout. la majorité des devices sur du orange qui ressemble plus à du orange. Quand on est dans ce niveau de détail là, nous on est super content parce que ça veut dire que déjà la personne a été capable de se rendre compte qu'il pouvait y avoir un potentiel problème au niveau du visuel. Quand c'est ça, c'est vraiment très chouette. Ça existe, je ne dis pas que ça n'existe pas, mais c'est vrai que... En tout cas, nous, en tant que designer, c'est aussi ce qu'on attend d'un front en face, c'est que, comme nous, on essaye de plus en plus de comprendre les contraintes de front et techniques, on s'attend aussi à ce que les développeurs frontent pour qu'ils, dans leur... un métier et de représenter visuellement une interface, ça intéresse aux enjeux design, sache reconnaître une typographie, parce que honnêtement c'est pas tout le temps le cas et il y a des fois la différence elle est quand même très flagrante. Sache qu'on comprenne des logiques de grilles, des logiques d'espace. Faire en sorte que quand on te dit que la librairie d'icônes c'est celle-ci, si tu dois toi en ajouter une autre, va chercher dans cette librairie d'icônes. Va pas chercher sur le web un PNG que tu trouves joli.

Terry : Très clair, donc là ça fait vraiment trois phases sur comment fluidifier les interactions, design, dev. Est-ce qu'il y a un autre point sur lequel on n'a pas abordé ou même dans cette thématique là un sujet dont on n'a pas parlé ou un point que tu aimerais mentionner ?

Simon : Je pense qu'on a tout couvert. Après moi ce que j'aime quand même vraiment bien faire avec l'équipe dev, c'est vraiment un Slack partagé où au moins on peut se poser toutes les questions en temps réel pour pouvoir fluidifier la communication et que ça ne se passe pas. uniquement à travers de réunions qu'on écrive, mais plus qu'il y ait une vraie interaction. Parce que nous, la problématique qu'on a, donc on a une petite agence où on n'a que des designers et on ne fait que du design, on ne fait même pas d'intégration, on ne fait vraiment que du design. Et les boîtes de dev qui viennent nous voir en général, avec qui on travaille, ils ne font que du dev et ils n'ont pas du tout de designer. Et donc quand on répond en contratance ensemble à des clients, ben le client en fait il se dit ben j'ai deux boîtes quoi, alors qu'en face il y a des concurrents qui ont toutes les compétences au sein de leur boîte, ben moi j'ai des designers, j'ai des développeurs, ça s'arrête plus fluide, ils se connaissent, ils se parleront, etc. Donc nous on a aussi un travail de devoir convaincre que de passer par deux structures c'est mieux que de passer par une seule parce que comme ça il n'y aura pas de majorité dans la manière de faire les choses parce que bien souvent quand vous passez par une boîte qui internalise tout ça c'est souvent plus le produit est technique plus c'est la tech qui est validée et plus le designer sera un petit peu bridé parce que voilà il y a des canvas techniques qui sont très forts c'est des compétences Parfois même lié à des frameworks très forts. Donc moi c'est ce que je vois de mon côté, en tout cas je me dis que le fait qu'on soit deux structures, nous on est au moins complètement indépendant et il n'y a pas une partie qui prend le lead, on essaye de vraiment faire en sorte qu'ensemble on soit chacun content de ce qu'on fasse. Mais par contre on a besoin de prouver à notre client qu'on va aussi avoir ces interactions là, surtout quand on est en contre-étense. Donc tous les points qu'on peut mettre en avant pour montrer qu'on se parlera entre nous, que ce ne sera pas au client de dire, de faire le relais entre nos deux structures. mieux c'est pour déjà convaincre notre client et puis pour nous pour travailler parce que le pire cas c'est quand c'est le cas qu'on est en abordé au début quand on sait pas du tout qui c'est qui dev ou en tout cas qu'on n'a pas de lien direct pour des raisons x ou y, c'est qu'on doit passer par le client pour dire est-ce que vous pouvez me lister parce que c'est vrai qu'on a eu un cas comme ça qui est assez costaud où on était hyper figé par un framework par un framework technique et on devait demander à notre client qu'on nous liste les composants qu'on avait le droit de faire ou de ne pas faire, le client les demande à l'entreprise de tech, l'entreprise de tech répond avec trois jours de retard C'est pas du tout fluide. Donc du coup il faut pas que notre client, quand on fait de la co-traitance, ressente ça. Il faut qu'il ressente qu'il y a une vraie unité et donc à nous aussi de mettre en place les passerelles qui sont les bonnes pour pouvoir arriver à, en étant deux indépendants spécialistes, à quand même proposer une sorte d'unicité dans la conception du produit.

Terry : Hyper hyper clair et puis et puis inspirant aussi sur sur se dire que c'est pas parce que effectivement tu fais appel à des prestats que tu vas te retrouver avec moindre qualité tant d'un point de vue conception que d'un point de vue tech je pense et en tout cas moi tu m'as convaincu dans cet échange et je pense voilà que ça montre que c'est possible après faut trouver les bons prestats les bonnes personnes mais sur des projets comme ça où tu viens en co-traitance en fait chacun un peu a aussi on va dire ça doit rester bien à jour dans son domaine de prédilection et ce qui permet de se challenger mutuellement et du coup de tirer le meilleur des deux donc ça aussi c'est son intérêt. Après le challenge je pense aussi pour des plus grosses boîtes souvent pourquoi elles vont peut-être avec des gens qui ont tout en interne c'est parce qu'elles se posent moins de questions, elles n'ont pas le temps d'aller chercher tous ces prestataires.

Simon : Oui bien sûr et c'est parce qu'elles ont aussi parfois pas l'opportunité en interne de gérer le produit et donc elles vont aussi venir chercher de la chefferie de projets la direction de clientèle et tout un cadre structurel qui va la rassurer mais qui parfois aussi va rassurer les achats parce que nous on a perdu des projets où l'équipe projet voulait une boîte comme la nôtre et des petites boîtes hyper spécialistes de leur domaine mais par rapport aux achats Comme on est trois fois moins cher, on a fait peur aux achats que tu es une petite boîte, tu ne veux pas durer dans le temps, comment ça se passe si tu t'écroules, vous êtes une petite équipe, comment vous gérez votre répartition des projets. Les gros peuvent aussi rassurer. d'autres décideurs dans l'entreprise qui fait qu'ils seront aussi sélectionnés pour ça. Même si ça c'est vraiment beaucoup en train de changer entre le freelancing, entre le regroupement de freelance ou d'experts comme nous on est à taille humaine. Et entre tout ce qu'on entend et tout l'historique que peuvent avoir certains clients avec des grosses structures, des grosses SN, qu'ils en reviennent beaucoup, il y en a certaines qui font très bien leur travail, mais il y en a beaucoup qui viennent nous voir parce que justement ils ont été déçus de tout ça.

Terry : Hyper intéressant du coup pour aller vers les deux questions classiques de fin d'épisode. Donc la première c'est est-ce que tu as une conviction forte sur quelque chose avec laquelle en général quand on parle à tes pairs tu es en désaccord ?

Simon : Ben moi ma conviction qui est forte et qui fait que se renforcer au fur et à mesure c'est vraiment celle dont on est en train de parler, c'est que le designer doit avoir des compétences techniques et doit s'intéresser au développement. Donc moi je ne suis pas du tout un développeur mais par contre je connais vraiment les bases de la manière dont on conçoit un outil, je m'intéresse à des architectures, je sais discuter avec une personne technique, et en fait quand on est dans de l'opérationnel, c'est comme un architecte qui ne connaîtrait pas la différence entre des matériaux et qui dirait bon ben là Du bois, ça va marcher ? Bah ouais, peut-être pas parce que c'est un pont. Quoique des ponts en bois ça marche aussi mais bon, je suis pas architecte, désolé. Mais c'est plus pour faire ce parallèle-là entre on a quand même besoin en tant que designer d'avoir une certaine connaissance technique, surtout quand on veut être dans... de faire quelque chose de réalisable. Et je pense que sur le web, c'est là où parfois le mot designer tel qu'il peut être pensé et de l'origine dans laquelle il vient, n'est pas toujours adapté à du web où on est très pratique, on doit faire quelque chose de réalisable, et on a besoin d'acquérir ces compétences-là techniques Mais en tout cas de s'y intéresser fortement et de faire en sorte que certes on doit penser quelque chose pour l'utilisateur, donc faire en sorte que ça soit le plus fluide pour lui, mais aussi que ça soit réalisable. Et donc ça souvent c'est un vrai sujet qu'il y a plein de gens qui me disent, ah oui mais toi du coup tu ne conçois pas pour l'utilisateur. Je fais si je conçois pour l'utilisateur, mais je suis quelqu'un de réaliste, donc je conçois pour l'utilisateur dans un cadre commercial et dans un cadre technique. et oui effectivement si au bout d'un moment l'entreprise pour qu'elle vive il faut qu'elle mette une bannière publicitaire parce que c'est son business model et on lui mettra la bannière publicitaire par contre le fait de se dire qu'il y aurait une bannière publicitaire au début moi je vais pouvoir dire écoute au lieu de mettre une banneur en plein milieu de ta home page là on va peut-être comme t'as des carousels d'actus peut-être qu'on va le mettre au moment comme une actus sauf que ça sera un élément plus publicitaire Et ça sera mieux intégré dans le parcours, ça sera plus pertinent pour ton utilisateur parce que lui il le verra dans un moment où il est plus concerné par de la visualisation donc en plus il sera moins réfragé, surtout que les bannières maintenant on les évite assez naturellement. Voilà, c'est plus pour dire, moi ma réalité c'est que oui, je dois faire en sorte que le produit soit le plus utilisable possible, le meilleur pour l'utilisateur. Mais on est dans des réalités commerciales et techniques qui font que si tu ne le prends pas en compte, pour moi, tu n'es pas un bon UX UI designer.

Terry : Oui bon très clair du coup t'as dit du coup la conviction sur le fait que les designers doivent comprendre la tech et aussi du coup le business puisque c'est ce que tu viens d'expliquer. Du coup pour aller sur les recos de lecture directement liés à ça, enfin les ressources en tout cas, j'avais gardé en tête parce que tu parlais du fait que les devs notamment frontent aussi c'est important qu'ils comprennent les enjeux design.

Simon : L'autre truc un peu qui met plus des côtés, pas de mes pères, mais des développeurs, c'est que les front-end, il faut qu'ils s'intéressent au graphisme, au design d'interface.

Terry : Du coup, ma question est un peu les doubles, c'est-à-dire d'un côté, côté tech, qu'est-ce que tu pourrais recommander comme ressource pour un peu mieux appréhender vraiment dans un but pareil ? Je n'ai pas beaucoup de temps, mais de manière pratique, je veux mieux échanger avec mes designers, donc qu'est-ce que tu pourrais leur recommander comme ressource, que ce soit de l'audio, de la vidéo, de la lecture ? Et du coup de ton côté, d'un point de vue designer, du coup mieux comprendre la tech, toi les ressources qui t'inspirent et sur lesquelles tu pourrais donner des recos aussi.

Simon : Je pense que déjà s'intéresser à tout ce qui touche de près ou de loin au design system, pour les deux parties, ça va beaucoup aider. Parce que l'avantage d'un design system c'est qu'il y a vraiment des enjeux visuels, d'ergonomie, mais il y a aussi des enjeux de développement. Et la base du design system c'est vraiment essayer de penser des composants de manière hyper éclatée. Donc déjà ça c'est des comportements de dev parce qu'avant on designait des pages, maintenant on design des modules qui ont certains composants. Donc déjà tout ce qui touche de près ou de loin au design system pour les deux parties ça va leur permettre de bien directement de se sensibiliser aux deux mondes. Parce que bien comprendre les librairies de composants, donc tout ce qui touche autour du design system, après il y a des librairies beaucoup plus pratiques, comme le Premium G que je citais, il y a Tidewind, aller explorer ce genre de choses. permettra aux designers d'avoir déjà une vue très exhaustive des composants qui sont réalisables. Pour un designer aussi, ce qu'on fait beaucoup nous quand on est sur des projets où on nous dit je vais utiliser Bootstrap par exemple, c'est qu'il existe aussi des librairies d'outils qui sont accessibles à l'achat mais au moins montrent les capacités de Bootstrap à faire des choses et donc en fait ça permet aussi de crédibiliser ses choix quand le développeur d'arrière dira mais c'est pas possible bah si regarde c'est possible parce que je l'ai vu sur tel site je sais qu'il est développé comme ça donc plus un designer va aussi s'intéresser à ces enjeux là technologiques plus il aura de points pour aussi s'apercevoir que la personne en face c'est pas parce qu'elle sait pas faire ou c'est pas parce que c'est pas possible c'est plus parce qu'elle sait pas faire ou en tout cas elle avait pas pas tout le temps parce que je ne sais pas faire mais c'est du plus parce que parfois même il n'avait pas imaginé que ça pouvait être faisable. Par exemple on a fait un Webflow il n'y a pas si longtemps que ça, on avait identifié des comportements possibles sur Webflow parce qu'on avait identifié des sites qui le faisaient, on avait un dev en face qui nous dit que ce n'était pas possible. bah si c'est possible, regarde, ça existe, on s'est inspiré de tel truc, finalement le projet a foiré, l'intégrateur a changé, l'intégrateur qui maîtrisait plus Webflow qui arrivait par la suite, il n'y a eu aucun problème à le faire. Donc du coup pour un designer, ça ne va pas être des lectures, ça va plus être de s'intéresser justement au techno et aller prendre avec son prisme à lui de designer et ça ne pourra que lui permettre aussi d'asseoir certains choix et de pouvoir les assumer et de pouvoir être sûr de ce qu'il va recommander. Et pour un développeur, ça serait de s'intéresser au design d'interface sur les bases du style graphisme la gestion des couleurs, la gestion de la typographie. On a écrit des articles sur ce sujet sur humans.design. Il y a une section blog, il y a des articles très détaillés sur l'usage de la typographie dans le design d'interface et l'usage des couleurs dans le design d'interface. ou on récapitule, c'est un peu long, mais voilà, ça donne des bonnes bases. La couleur et la typo, c'est déjà, on voulait avoir un premier vernis, c'est le plus important. On passera à la suite après.

Terry : On mettra ça dans les notes de l'épisode. Et du coup, la dernière ROCO que je te demande qui n'a pas grand chose à voir avec ce que je viens de te demander, mais je ne l'ai pas oublié, c'est au sujet de... du support client exactement parce que juste ce que je disais donc c'est que dans les produits digitaux souvent on a le regard très tech, on dit ok il faut penser à la tech, comment ça va être fait, le design mais on oublie après le mode run où derrière tu as du support client, des CSM qui vont s'y vendre, expliquer comment ça marche, les fonctionnalités donc il y.

Simon : A toute une.

Terry : Des métiers qui sont un peu cachés, mais qui sont hyper importants pour le mode run de ces produits digitaux. Donc juste faire un SaaS B2B, c'est pas faire le SaaS et après on va se mettre sous les cocotiers, se faire bronzer. Non, non, non, il faut effectivement être au quotidien, répondre aux appels quand ça marche pas et se piquer. Donc la ressource que tu avais à ce sujet là sur le support clientiel.

Simon : La ressource que j'avais, alors j'ai pas le titre exact, mais j'ai l'auteur, si je ne me trompe pas, il s'appelle Jonathan Lefebvre. Il était chez Captain Train à l'époque, où ils ont, dans les premiers membres de l'équipe, et c'est lui qui a mis en place le support de Captain Train, et ils étaient connus et reconnus pour leur support, parce que c'était ce qui faisait vraiment leur force face à à la CNCF et donc il a écrit un livre sur le sujet qui s'appelle le service client héros ou quelque chose comme ça je suis désolé je me rappelle plus du nom mais je pense que tu mettrais le lien. Il est hyper intéressant parce qu'il raconte toute la genèse et tout ce qu'ils ont mis en place chez Captain Train à l'époque. et la culture aussi support, parce que c'est vraiment comme tout, c'est surtout des enjeux de culture, et comment en fait faire en sorte que la culture support s'étende dans l'entreprise, soit vraiment pris en compte par tous. Et la lecture elle est super, je ne suis pas du tout dans ce domaine là, mais j'ai réussi à lire le livre parce qu'en plus il est très drôle, il sait très bien écrire, ça marche super.

Terry : Top, merci beaucoup Simon.

Simon : Avec plaisir, merci pour cette invitation.