Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Timo Roustamoff, Timo, bonjour.
Bonjour Benoît, j'ai envie d'être avec toi.
Ravie d'avoir aujourd'hui sur le podcast, est-ce que tu peux te présenter en quelques mots
pour ceux qui ne te connaissent pas ?
Bien sûr, alors je m'appelle Timo, je suis ingénieur full stack chez GoJob, ça fait
déjà 3 ans et demi que je travaille chez GoJob en tant que staff ingénieur en fait,
donc j'ai pour mission de développer les features mais aussi de former les autres et
en former les autres, bah je m'en to forme aussi, donc c'est génial, c'est un cercle
vertueux.
Et ce qui me passionne avant tout c'est de fournir des bons outils aux bons utilisateurs,
donc des outils adaptés qui servent aux utilisateurs.
Et l'outil du jour dont on va parler, c'est que tu veux l'introduire ?
Alors oui, carrément.
Donc aujourd'hui on va parler avec toi de design system, à quoi ça sert, comment on
a construit un bon et quelles sont les pièges à éviter lors de ces actions.
Et bah écoute, tu penses que ça sera un vrai sujet, en tout cas c'est un sujet par lequel
je suis passé moi en tant que dans un des projets, donc on pourra confronter un petit
peu ce que tu... enfin je vous pourrais confronter avec ce que tu ne veux pas nous raconter.
Et avant de rentrer dans le commande maître en œuvre, est-ce que tu peux nous rappeler
ce que c'est d'abord un design system ?
Bien sûr, ouais.
Enfin je pense que tout le monde a déjà entendu au moins une fois dans sa vie, c'est deux
mois en tant que développeur, mais c'est un objet assez mystique quand même.
Donc on va essayer de le demystifier un petit peu en vraiment en décomposant le sens de ces
deux mots.
Un design system en fait c'est un ensemble de standards qui s'applique donc à notre
design et ils ont pour l'objectif de scaler en fait avec le temps de prendre de l'envergure.
Enfin lorsqu'on... notre projet prend de l'envergure, il faut que notre design system soit le
garant qui résiste en fait à la mise à l'échelle de notre entreprise.
Au début quand c'est simple c'est facile, quand c'est tout petit c'est facile.
Et plus l'entreprise grandit, plus le produit grandit.
Plus on a des disparités et le design system a un pro-objectif de réduire le coût de
maintenance, permettre de faciliter en fait la mise en œuvre de nouvelles pages, de
nouvelles fonctionnalités visuelles.
Quand tu dis que c'est un standard, quelle forme il prend en fait ?
Moi le design system j'ai sous les yeux une bibliothèque de composants en fait.
Est-ce que c'est réducteur ou est-ce que ça résume assez bien ?
C'est une partie du design system.
En fait en réalité il comporte pas mal de DAX.
Un design system c'est par exemple un style guide de...
Ok.
Ok bah ce sont les couleurs qu'on utilise.
Allez c'est parti.
La palette de couleurs.
Voilà la palette de couleurs, les châteaux par exemple.
Les arrondis qu'on utilise, les spacing.
Donc il y a ça, il y a cette partie là en effet.
Il y a aussi les patterns qu'on emploie.
Donc par exemple je sais pas lorsqu'on veut afficher une information spécifique en mode
toast.
Quelle forme ça ?
Donc comment communique cette information ?
À chaque usage ça son pattern.
Ensuite il y a les guidelines d'entreprise.
Par exemple le ton qu'on emploie.
Si on est copains-compas avec les utilisateurs parce qu'on s'adresse peut-être à un public
un peu cool.
On va employer un ton.
Et ça aussi ça fait partie du système.
Et je pense qu'il y a un élément qui est central.
En fait dans tout ça, ça s'appelle le langage visuel.
En fait j'adore cette expression, le langage visuel.
Parce que comme les lettres forment des mots et les mots forment des phrases.
Les primitives, donc enfin ce qu'on appelait le style guide juste avant.
Donc la typographie par exemple les arrondis, les châteaux, le padding forment des composants.
Et ce composant à leur tour forme des pages au final.
Donc en fait au final comme des mots qui forment des phrases, les composants forment des pages
et ça a un sens.
Et en fait c'est ça qui émerge depuis le design system, c'est le langage visuel.
Parce que ce que tu dis c'est que si on n'a pas ce genre d'outil en place au fur et à
commencer à avoir des disparités dans la production du logiciel.
Ça c'est quelque chose que j'ai vu.
Il y a des équipes d'abord qui vont réinventer la poudre ou qui vont réinventer la manière
de faire.
Et puis surtout tu vas avoir après des interfaces qui ne sont pas cohérentes entre elles en
fait.
Oui ça c'est très dur à en effet.
Si on ne met pas des règles en place, ça a tendance à en effet assez éclater relativement
rapidement.
Même si on veut bien faire, chacun va un petit peu en reinventer sa roue.
Moi aussi je pense qu'on est tous passé un peu par ce chemin-là.
On a tous vu comment ça peut très vite partir en bazar.
Et c'est ça qui t'as amené à pousser ça en interne de Poussaint-Zé ?
Oui c'est ça exactement.
Vu que je l'ai vu ce pattern se reproduire plusieurs fois et qu'à chaque fois on était
en train de faire appliquer des patches par-ci par là à chaque fois, ça a revenu de les
futurs revenus de QA.
Parce que les designers n'étaient pas contents parce qu'il y avait un padding de 16 alors
qu'ils demandaient 12.
C'est l'oeil guisé des designers.
Tu les connais, c'est clair.
Et puis tu fais non je dois faire passer ma mergerie Quest encore, ça va prendre une
heure de pipeline et tout.
J'ai autre chose à faire.
Et donc vraiment c'est une perte de temps au quotidien de ne pas avoir de design
système au final.
Après pas tous les use cases ont le besoin de design système.
On peut s'en passer mais c'est un choix qui est délibéré, qui doit être adopté
par tout le monde.
Il y a compris les designers, il y a compris les product managers.
Oui parce que ça standardise à normalisme et justement ça standardise en normalisme
donc du coup le jour où le designer a envie de faire un truc un peu plus fancy il fait
comment ?
C'est ça exactement.
Après on va en parler un petit peu plus tard justement de cet aspect un peu spécial
Snowflake parce que les designers c'est des artistes et ils aiment créer, ils veulent
pas juste reproduire la même chose tout le temps.
Donc par ci par là tu vas avoir des petits grains de spéciale, des petits touches spécifiques
à lesquelles il faut gérer et il ne faut pas du tout combattre ce genre de pattern.
Donc il ne faut pas non plus tout standardiser.
Il faut se laisser la possibilité de faire un petit peu de spécifique à des endroits.
Parce que moi l'histoire que j'ai de la transition sur un design system c'est qu'il
y avait un peu les problèmes que tu évoquais et surtout ce qui nous avait motivé c'est
qu'on remarquait que les designers ils devenaient un espèce de goulais d'étranglement pour
sortir tous les écrans avant qu'on publie et des fois on sentait que c'était inutile
parce qu'en fait on savait qu'elles étaient les composants à mettre dans la page et donc
ça ne servait à rien même de faire intervenir le designer pour designer la page.
C'était voilà ça faisait pas de sens et donc du coup on s'était dit ça va nous
permettre d'aller plus vite dans la production de nouvelles features et de nouveaux écrans
parce que du coup le designer n'avait qu'à se concentrer sur vraiment l'expérience
utilisateur et pouvait rester au niveau de moque et par contre dans la transition ça ressemblait à
bon le produit était assez gros mais encore assez petit en gros le designer s'est mis sur
son truc pendant deux mois et ça a été un peu blackout pendant deux mois et puis d'un coup
pouf qui sort avec le truc et d'un coup gros choc il faut tout transférer sur le truc et ça
était un peu violent et du coup on a recréé des espèces d'effets tunnels et donc je suis content
qu'on y soit passé si tu veux mais en même temps c'était très frustrant pour moi de vivre ça en
mode des faits tunnels j'imagine alors toi comment est ce que tu recommande la mise en place de
cet outil là et comment tu le fais vivre en fait c'est ça c'est tu me tu me devras c'est exactement
ce que j'allais dire en fait il faut le faire vivre on est fiers depuis la naissance du design
système et pendant toute la durée de sa vie c'est un objet vivant donc il va évoluer au cours du
temps il faut s'y adapter parce que je crois que nous dans notre tête il y avait un petit côté il faut
pourquoi c'est cet effet tunnel parce que il y avait la volonté de s'assurer que que ça matche bien
que ça va bien marcher sur toute l'app et qu'il fallait transiter toute l'app d'un coup en fait
après ouais on peut faire les changements petit à petit vraiment avec une transition je pense que
ce que tu décris là peut-être que c'est un changement de style de design entier parce que normalement
en fait et au passage pour histoire de complexifier les choses on a effectivement fait un changement
de style au passage ouais parce que quand tu en fait quand tu mets en place un design système normalement
tu prends en compte aussi l'existence il faut pas frustrer en effet quand il y a des breakings change
dans un design système c'est mortel en fait pour les développeurs c'est mortel donc il faut en effet
prendre en compte la backword compatibilité ouah c'est dur à dire mais il faut le prendre en
compte et du coup ouais du coup comment tu recommande toi de mettre en œuvre un design
système du coup de partir d'une approche peut-être plus composant par composant on déroule on met
en œuvre ou comment tu recommanderais de passer à un design système ouais c'est très intéressant
en fait en effet moi je recommanderais de prendre un petit peu l'atomique design qui a été introduit
par bradfrost dans son excellent livre qui porte le même titre atomique design on va commencer
par des tout petits états en cité tel que justement les spacing notamment donc on va définir
que notre spacing peut faire que de multiples de 6 par exemple donc souvent on sort en plus
des étapes donc je vais définir comment spacing fait peut faire uniquement 6 12 18 24 et 48 pixels
donc j'ai cinq valeurs dans mes spacing et tout ce qui tourne autour donc à chaque fois que je vais
avoir un bouton avec du texte dedans la distance entre le texte et la bordure du bouton il faudra
12 et ça c'est normalisé dans un framework et tu commences par normaliser par exemple tout et
tout est spacing tout à fait ouais et donc tu normalises absolument tout spacing pareil pour
les couleurs tu peux pas avoir une palette à finir je peux pas avoir tous les examens en
fait tu vas repérer le couleur que tu utilises le le plus et celle qui sort en fait il faut pas
avoir trop bien sûr parce que ça apparaît c'est une complexité mentale qui difficile à gérer donc
on veut faire en sorte que le design système soit le plus petit possible le moins permissif possible
mais qui est quand même des ce qu'on appelle des escape hatches donc des portes de sortie un petit
peu pour les cas spécifiques et comment vous l'avez fait chez godjob de mettre en œuvre de passer de
pas design system à ça a été un début de comment vous avez commencé alors c'est très intéressant
on travaille très étroitement avec notre designer un des nos designers qui s'appelle
clément le blond et en fait c'était dur pour lui de concevoir ses ses vues parce que justement il
avait pas de baseline il n'avait pas tous les stets tous les composants et du coup c'était un petit
peu disparaître un petit peu voilà en bazar nous de notre côté c'était pareil à chaque fois
qu'on implementait quelque chose bah on devait bien checker les spécifiques bien checker les
couleurs ne pas se tromper tout ça tout ça donc à partir de là en fait à partir de ce
besoin là est né une initiative de design système donc avec clément justement avec le
designer en question on s'est posé on a longuement réfléchir à comme où est ce qu'on peut couper
dans le l'art en fait quels sont les pas de termes qu'on utilise le plus qu'elles sont les couleurs
qu'on utilise le plus qu'elle est la typographie qu'on utilise le plus et on commençait vraiment à
essayer de structurer pour ça c'est un travail qui prend beaucoup de temps beaucoup d'énergie également
mais toute dans la discussion je vais te révéler un petit secret en plus ça reste entre nous ça
va alors le dit à personne c'est que en fait il faut pas inclure trop de monde dans l'élaboration
de design système en fait c'est un petit peu ankynomique mais quand on est beaucoup avoir le
consensus de tout le monde c'est très très difficile donc je recommanderai une taille d'équipe
relativement petite entre peut-être cinq cinq à dix personnes parce que si tu inclus ce qui est
déjà énorme enfin même plus enfin cinq personnes pour moi c'est l'idéal parce qu'en fait en
tenir au valet consensus de tout le monde c'est très compliqué en plus le design c'est quelque
chose de relativement personnel personne enfin ça se trouve on voit pas les mêmes couleurs toi et
moi on sait pas et donc en multipliant les acteurs on multiplie aussi les tensions et le travail
quoi donc il ya plus de difficultés imaginons on peut prendre par exemple l'exemple tu prends
trois points ça te forme un triangle et si tu vois les lignes entre ces points symbolise les
interactions le consensus de tout le monde si tu mets quatre points bah t'auras plus de lignes
forcément parce qu'il ya les diagonales qui vont se croiser donc t'auras six interactions si tu
prends six personnes il y en aura 15 et ainsi de suite c'est exponentiel à 14 personnes on arrive à
quatre ou onze interactions donc c'est énorme donc moi je recommande vraiment de rester petit
vous étiez combien au produit au moment où vous avez démarré le projet au produit au sens large
au sens de dev designer ouais ouais on était voilà cinq personnes je dirais mais non en tout dans
l'équipe en tout en tout en tout en tout dans l'équipe dès que le produit on était une trente
ans je pense d'accord donc il ya quand même un cinquième c'est ça un cinquième ouais un sixième
des gens qui ont été impliqués dans le dans le dans le projet et ça demande je pense que ça
scale ça scale pas trop avec la taille ouais avec la taille de l'équipe finalement vous aurez été
sans ça aurait été pareil quoi ça aurait été une petite série exactement ouais non par contre
moi ma question c'est si jamais tu es plus que cinq ou dix comment tu gères ça mais ok c'est dans
le sens et qu'est ce qui vous a fallu comme énergie pour commencer à avoir un un outil que vous
puissiez vraiment sur lequel vous puissiez vraiment vous appuyer ça a duré quelques semaines
quelques mois c'est quoi le nombre de mois c'est ça ouais c'est quelques semaines je dirais en fait on
a déjà eu des essais de mise en place d'un dizaine de systèmes auparavant on s'est l'hermantable
moins mangé en fait ça a été un échec un pain en fait pour les différentes raisons à ça
il paraît intéressant qu'est ce qui fait que ça a fait ça fait justement on était déjà on était
trop permissif de base c'était très compliqué en fait de de loquer un petit peu les valeurs
quand on était beaucoup trop permissif il y en avait un petit peu dans tous les sens pareil
dans côté design on n'était pas sûr de ce qu'on voulait faire et au final aussi le côté
implementation on était on on a pas réussi à garder ça simple en fait et ça ça a amené à
l'échec le truc parce que au final un design système il n'a zéro logique c'est vraiment que
du design et nous on a voulu et inclure aussi de la logique des interactions des choses comme ça
et ça faisait ce temps voilà standardisé ces choses là bah on a malheureusement pas réussi
parce que à chaque usage il y a des spécificités dans les interactions et je pense que justement
les interactions et compagnie ne doivent pas faire partie des items c'est enfin tu peux avoir les
patterns d'usage mais pour moi il n'est pas logique de fournir le code qui va avec ok super
intéressant si tu veux on peut parler des étapes comment on fait ça comment à partir de rien
on va dire la qui nous écoute et qui dit t'as à l'air intéressant comment ce que comment ce
qui il y est si bah vas-y on y va on va le faire comment ce que c'est quoi les étapes yes ouais
bah déjà tout d'abord il faut savoir si vous font un design système déjà de base ce que ça
c'est une vraie question à se poser peut-être que ce qui peut faire que tu que c'est une bonne
question du coup c'est peut-être la taille de l'équipe qui est trop petite parce que c'est un travail
quand même relativement fort en revanche le ver chronophage tout à fait à maintenir un design
système peut-être que le design n'est pas assez sec aussi on sait pas exactement quelle
image on veut renvoyer parce que le design c'est aussi ça c'est on reflète l'identité de l'entreprise
alors oui mais là dis moi dis moi si je me trompe j'ai l'impression que mais je dis donc on change
le design système quand on dit bah maintenant c'est plus bleu c'est rouge c'est plus un spacing de
12 et c'est 8 et qu'on change un peu tous les éléments j'ai l'impression que si tu as un design
système c'est plus facile à faire que si tu n'en as pas oui le refactoring en effet est plus
facile mais c'est c'est difficile parce que c'est c'est des entités les primitives elles sont liées
entre elles donc si tu changes par exemple ton spacing de voilà de 6 à 12 peut-être il va falloir
adapter des des usages et des éléments en conséquence d'accord ok il ya quand même oui
tout à fait ouais c'est pas automatique quoi je j'aime bien ce bon et du coup pareil il y a les
contrastes des couleurs si on change une couleur peut-être qu'elle n'ira pas avec les autres ou
elle n'est pas adaptée aux personnes malvoyantes donc l'accessibilité c'est très très important
également donc il faut prendre en compte tous ces éléments généralement un design système
lorsqu'on construit certes il vit il change mais il ne change pas complètement à partir de là
enfin si les changements sont trop important on est face tôt et on refait un nouveau design
système ok et donc les différentes étapes alors tu en étais là yes tout à fait ouais donc les
différentes étapes c'est de repérer la problématique donc c'est pourquoi se poser les bonnes questions
c'est pourquoi créer le design système il faut ensuite mener des audits internes donc comment
parler aux utilisateurs concerné par exemple donc je sais pas identifier les les différences
du gage déjà existant et d'identifier les composants existants il ya la phase de recherche
de solution également quelle technologie vous convient le mieux pour remplacer votre design
système nous ensemble on va en voir une qui qu'on utilise à godjop qui s'appelle tailwind je dis
un peu là et on la verra bientôt live coding il faut voir également quels sont les quels
est le budget par budget je veux dire aussi temps et argent qu'on veut mettre en place aussi pour
créer son design système il faut c'est très important aussi de créer une convention de nommage de
de langage qu'on parle tous c'est c'est ce qu'on appelle le big widows language que Eric
evance a introduit dans son livre domaines de vignette design donc je pense que ça s'applique
également au design il faut qu'on parle la même langue quand quand je dis une carte par exemple
il faut que le designer comprenne il faut que l'utilisateur comprenne ce que c'est également
quand tu dis l'utilisateur tu parles de l'utilisateur final ou du développeur du développeur
tout à fait tout à fait oui l'utilisateur dans le design système c'est le développeur
en fait tout à fait ouais et c'est le design système en soi c'est un produit qui sert à d'autres
produits en fait qui est consommé par d'autres produits et donc il faut le traiter comme un
produit il doit y avoir un budget il doit y avoir un product manager il doit y avoir un designer
et tout ça tout ça c'est vraiment un projet à garantir donc lorsqu'on se lance dans un design
système il faut bien identifier et quantifier et planifier tout ce qu'on fait dans les projets
qu'on a l'habitude de faire dans nos entreprises voilà donc ensuite il faut le construire une
fois qu'on a planifié tout ça on le construit on itère on teste on fait attention au risque
également on va pas trop vite donc c'est là le cycle de vie d'un produit classique et ensuite
il faut le faire vivre si un design système n'évolue pas c'est que quand même il y a un problème
parce qu'en fait les usages changent constamment les utilisateurs changent les utilisateurs je
veux dire du produit de la poloq ou voilà du produit tout à fait il s'attende peut-être voilà
il s'attend à autre chose les goûts évoluent également dans le temps donc un design système
qui bouge pas c'est un produit qui n'évolue plus quoi c'est ça exactement et donc là il faut c'est
l'assonnée d'alarme ok super intéressant moi j'aime bien cette idée de le voir comme un produit
interne en fait comme un produit qui sert des utilisateurs et bien du coup tu le gères avec
le cycle de vie d'un produit comme on sait bien le faire en général mais c'est vrai qu'en général
on on y met cette énergie surtout ou voir que pour les produits externes et c'est moins développé
de le mettre dans les produits internes ouais tout à fait c'est vraiment un produit en part
de faire en effet ok j'ai quelques astuces de développeurs à donner si tu veux donc là
à part utiliser tail wind à part utiliser tail wind ça c'est un no brainer c'est la question de
c'est vrai c'est le non tu rigoles ou c'est le standard je connais très mal les mises en
eau c'est le standard des factos ou il ya un peu une guerre de chapelle là aussi non c'est pas un
standard pour la standard de factos mais en effet tail wind nous fournit les outils adaptés très
très adaptés selon moi pour construire son design system c'est à dire que on c'est très
rapidement on met en place par exemple les valeurs de spacing dont j'ai tant parlé tout à l'heure
et pareil pour les couleurs c'est extrêmement facile de mettre en place les primitives du design
system donc vraiment tout ce qui concerne les toutes petites entités c'est plus petit que les atomes
dont on parlait bras frost en fait au début enfin je pense qu'il faut revoir ce livre faire une nouvelle
édition ce qu'en fait à l'époque mais c'est marrant comme l'histoire se répète parce que atomes en
grec ça veut dire indivisible et pendant le super longtemps on pensait que un atom c'était le plus
petit la plus petite chose qui existe et après on s'est aperçu que dans un atomes il y avait plein
de choses les électrons les quarks etc etc etc et là c'est pareil on peut subdiver l'atom au sens
de bras frost en plus petit entité encore et donc ces plus petites entités vont construire des
des atomes qui eux à leur tour vont construire de molécules qui vont construire des organismes et à
j'aime bien ta métaphore avec le le monde physique et le et un peu organique même que ça peut
avoir d'un même le le design au sens propre c'est très cartésien on soit quand on y pense même
tout l'art en fait est très cartésien il ya un excellent livre qui s'appelle design for a curse
qui a été écrit par dont je veux pas je veux pas mal citer david cadavis qui justement
démystifie un petit peu le design et comment le faire en fait comprendre par des gens qui sont
très cartésien et en final lorsqu'on regarde vraiment en profondeur d'un art on retrouve des maths
on retrouve des de la géométrie on retrouve le nom de la technique quelque part voilà il ya
forcément une technique et donc le design système c'est aussi ça qu'un autre conseil tu peux donner
alors à des développeurs pour le mettre en eux yes donc moi je vraiment si j'avais un seul conseil
à choisir bon ça serait difficile mais si j'en avais un ça serait d'être très très très très
proche de designer donc vraiment être en constante interaction avec eux peut-être même en un petit
peu en débat faut pas avoir peur de les bousculer faut vraiment parler avec eux remettre en question
leur design voilà participer à la mise en place de ce design voilà venez les embêter pendant les
post cafés je sais pas vous les invité au team building je sais pas jouer à la pétanque et en
fait à chaque il faut construire vraiment une relation de confiance avec le designer pour qu'on
travaille tous ensemble dans la bonne entente ça c'est très important un autre conseil que je
pourrais donner serait d'encourager la contribution en fait au design système donc pour que tout le
monde se sent concerné et honneur du projet donc c'est la responsabilité collective au final
un design système vu que c'est un produit qui sert à tous les autres produits il faut que les gens
des autres produits y participent ou moins adhèrent au principe des design systèmes ouais mais
alors du coup comment tu comment tu gardes une certaine cohérence et tu t'assures que le truc part
pas qu'on reproduise pas dans le système dans le design système les écueils qui pouvait y avoir
dans le produit et comment tu gardes une cohérence il y a quelqu'un quand même qui a la fin et
responsable de valider les poules request ou comment tu gère ça c'est ça on peut l'imaginer comme
ça on peut imaginer aussi que en fait sans avant avant de faire le code correspondant au design
fin aux composants ou à l'atome du design système il faut que le design soit fait et donc là les
designers en fait sont les honneurs de cette ok donc tous les designers peuvent apporter une
amélioration sur peuvent faire évoluer le design système en fait tout à fait ouais et tous les
développeurs du coup peuvent rajouter ces ces features c'est ces composants dans le design
système donc c'est un travail collaboratif et voilà et donc pour ça c'est c'est relativement facile
on met en place en backlog on process les les poules request rapidement pour que les design
les les contributeurs se sont investi en fait se sentent qu'ils aient un sentiment de là de
contribution tout simplement et pour qui ils se sont responsables également de cette chose
voilà un autre conseil que je pourrais donner aussi c'est c'est de le garder ce design système
vraiment extrêmement simple et en plus ne pas mettre de logique dedans assez c'est ce qui a
encore scarifié voilà donc pareil pas de over engineering ou overdesign par ptn
qui pite simple qui pide vraiment super simple ouais c'est ça exactement et aujourd'hui alors
est-ce que tu dis ça fait combien de temps que vous avez fait ce gros travail de migration alors
vraiment le celui en date ça fait bien six mois qu'on l'a vraiment la version finale on va dire
qu'on l'a passé la version 1.0 vous avez mis combien de temps pour la bâtir de version 1.0 je pense
en fait on avait déjà un design système sur papier on va dire entre guillemets sur figman
notamment un autre outil de design et ensuite pour l'implementer on a mis moi je dirais une à deux
semaines ok donc ça fait ça fait moins d'un an que vous avez commencé à vous y mettre sérieusement
ça fait six mois que vous l'avez et est ce que tu dirais qu'aujourd'hui les raisons pour lesquelles
vous l'aviez mis en place ça ça a marché quoi est ce que aujourd'hui tu dirais que ça a tenu ces
je pense que oui en fait en tout cas les retours des développeurs qui l'utilisent sont très positifs
on a réussi à embarquer tout le monde dans le projet et comme david justement te le disais
dans son podcast david olivier il y a même des techniques voilà de frontend first qui
a émergé à partir de là désormais lorsqu'on veut implémenter par exemple une page relativement
simple on a même plus besoin de designer on a juste besoin d'un wireframe donc une maquette
vraiment très très très simple et à partir de là on peut tout faire donc c'est vraiment une
qualité enfin ça a plutôt bien marché au final je dirais et bien écoute je propose que ce soit le
mot de la fin merci timour si les auditeurs veulent en savoir plus te suivre voir ce que tu fais ils peuvent
te suivre ou yes vous pouvez me sur twitter si vous tapez mon nom prénom donc timour rostamov
ça marche on mettra le lien dans la description merci timour merci à toi quand t'attache aux
auditeurs j'espère que bah comme dame que tu as kiffé cet épisode c'est le cas fait le savoir
partage le parce que je sais que cette question du design system c'est encore un sujet qui est pas
évident qui est dur à faire passer comme message qui est dur à fédérer et c'est dur de voilà
d'impliquer les gens dedans donc si tu penses que ça pourrait bénéfique à quelqu'un bah voilà
envoie lui cet épisode de podcast et peut-être que tu s'aimeras une graine je te remercie je te
dis à bientôt