Front/Back, HTML/CSS, Git : 5 notions devs que tout designer doit connaître

5 notions devs que tout designer doit connaître

La série tech-knowledge, c’est un format d’article qui vulgarise des notions devs utiles à votre quotidien de designer 🚀 L’objectif : acquérir des connaissances transversales à vos design skills pour mieux collaborer avec vos collègues développeurs 💪

Avec du recul, mes premiers pas de designer n’ont pas été faciles à certains moments ! Je ne comprenais pas toujours pourquoi certaines de mes propositions design n’étaient pas implémentées telles qu’elles malgré la valeur qu’elles apportaient à l’utilisateur 😅 Les présentations de mes maquettes se succédaient, les amendements techniques plus ou moins expliqués aussi… générant toujours un peu plus de frustrations 😵‍💫 Au fil des années, à force de lectures et d’échanges avec mes collègues dev, j’ai acquis un certain nombre de connaissances techniques qui m’ont permis de faciliter mes interactions avec eux 💪 

Nous allons passer en revue 5 notions techniques essentielles qui vous permettront de comprendre les retours techniques des devs 🚀

# Notion 1 : le back

Le back, c’est la partie “invisible” d’un site web ou d’une application, c’est le programme. Les principaux langages back sont PHP, Python ou node.js. Le back s’occupe du traitement des données. Lorsque vous utilisez une application, vous envoyez des demandes. Derrière chaque bouton, chaque input des actions arrivent au back, l’information demandée sera cherchée dans la base de données et renvoyée à l’utilisateur, c’est ça le back de manière très schématique.

🤔 Pourquoi dois-je connaître cette notion ?
Même si à première vue, le back ne vous concerne pas directement en tant que designer, comprendre comment se fait la récupération des données est très utile ! Il faut savoir que dès que vous afficher des données dans un wireframe ou une maquette, côté back, les devs devront réfléchir à la récupération des données pour les afficher.

Hack Coding GIF by Matthew Butler - Find & Share on GIPHY

# Notion 2 : le front

Le front, c’est la partie visible d’un site web ou d’une application, c’est l’interface avec laquelle l’utilisateur interagit avec le programme. Le front s’occupe de l’affichage des données. Les langages front sont HTML / CSS et JS. Les principaux frameworks comme React ou Vue.js permettent un développement flexible par composants ⚛️.

🤔 Pourquoi dois-je connaître cette notion ?
Le design d’interface et le développement front ont beaucoup convergé ces dernières années notamment avec Figma. L’atomic design, approche par composant est une logique commune aux devs front et aux designers. Elle a d’ailleurs été théorisée par un développeur front, Brad Frost !

# Notion 3 : HTML/CSS

HTML est un langage de balisage, il permet de structurer un document HTML.
CSS est un langage de mise en forme, il permet de styliser un document HTML.

🤔 Pourquoi dois-je connaître cette notion ?
Toute interface est intégrée avec ces deux langages. Connaître les différentes balises HTML et propriétés CSS m’a permis de mieux structurer mes composants et mes maquettes dans Figma 🙌

👷 Tips du terrain :
dès que j’ai un doute sur la structure d’un pattern ou d’un template, je vais consulter la documentation d’un framework CSS ou d’un design system existant. En faisant ça, je m’approche au plus près de l’intégration finale 💪

Codepen Projects GIF by Product Hunt - Find & Share on GIPHY

# Notion 4 : git

Git est un logiciel de gestion de versions décentralisé. Le code d’un site web ou d’une application est généralement stocké et versionné sur un dépôt en ligne sur des plateformes comme GitHub ou GitLab.

Un système de branches permet de gérer plusieurs versions du code. La branche master, c’est la branche principale, elle correspond à la version en production. Les branches develop, ce sont les branches de travail sur lesquelles travaillent les devs avant de mettre en production. Une fois les tests et la code review passés, le code développé en local est fusionné dans la code base. Les devs font des demandes de merge selon la plateforme choisie :
– des PR (Pull Request) sur Github
– des MR (Merge Request) sur GitLab

🤔 Pourquoi dois-je connaître cette notion ?
Connaître le cycle de développement d’une feature est utile pour comprendre pourquoi certaines propositions design ne sont pas tout de suite implémentables ! Ce n’est souvent que partie remise 💪 L’implémentation sera différée pour rentrer dans l’estimation prévue ou parce qu’elle concerne un autre lot de fonctionnalité. 

👷 Tips du terrain : pendant une UI review lorsque je constate qu’un élément présent dans la maquette n’est pas intégré, j’échange avec le dev sur ce changement pour :
– comprendre les contraintes techniques rencontrées
– planifier quand l’élément sera implémenté
J’aime beaucoup les UI review, ces moments d’échanges sont un bon vecteur d’acquisition de connaissances techniques mais pas seulement ! Elles permettent de trouver des solutions ensembles, de rapprocher devs & designers.

Code Coding GIF by EscuelaDevRock - Find & Share on GIPHY

# Notion 5 : workflow de déploiement

Avant d’être mise en production, une feature passe par plusieurs étapes : Local > Code review > Staging > Prod. Le dev travaille la feature en local sur sa machine. Chaque feature est reliée à une PR. Une fois la feature terminée, elle passe en code review pour relecture par un ou plusieurs autres devs. Une fois validée, la PR peut être mergée sur la staging, l’environnement de test. Cette seconde étape de validation permet de tester le comportement de la feature dans l’application globale. Une fois cette étape passée, la feature peut être mise en production (MEP) sur la prod, l’environnement de production est celui que les utilisateurs finaux utilisent.

Data Coding Gif By Sticker - Find & Share on GIPHY

🤔 Pourquoi dois-je connaître cette notion ?
En m’intéressant au processus de déploiement, j’ai mieux compris pourquoi certains éléments de mes maquettes n’étaient pas intégrés sur une feature. En discutant avec les devs, j’ai pu observer qu’ils font la distinction entre ce qui est de l’ordre d’une feature (spécifique) ou de l’application (global). Réfléchir avec cette logique permet d’anticiper dès les maquettes ce qui sera implémenté directement ou différé, ça permet de mieux prendre son mal en patience 😄

👷 Exemple du terrain 1 : je travaillais sur une fonctionnalité d’écran d’affichage destinée à présenter des statistiques sur un grand écran. J’avais prévu dans mes maquettes un thème clair et un thème sombre pour limiter la fatigue visuelle pour les utilisateurs. L’implémentation de cette fonctionnalité a simplement été différée car elle concerne potentiellement l’ensemble de l’application. Elle fera l’objet d’une autre PR et surtout un travail design plus global à l’échelle de l’application !

👷 Exemple du terrain 2 : je travaillais sur une carte qui concernait l’amélioration de la page formulaire d’une entité sur une application métier. Pour faciliter l’accès au bouton d’enregistrement, je l’ai déplacé dans une barre d’action fixe en bas de l’écran. L’optimisation proposée n’a pas été implémenté tout de suite, pour la même raison que précédemment : c’est un affichage qui concerne plusieurs autres endroits dans l’application (toutes les pages formulaires) donc elle fera l’objet d’une autre PR.

Le mot de la fin

Sans aller jusqu’à savoir coder, je pense qu’un designer doit maîtriser quelques connaissances techniques de base pour évoluer avec aisance dans son équipe. Élargir votre champ de connaissances vous permettra de faciliter la passation de votre travail en développement et surtout fluidifier votre collaboration avec les devs. 

Grâce à ce starter pack : back, front, HTML/CSS, git et workflow de déploiement, vous vous sentirez plus à l’aise dans les échanges et ça vous évitera des incompréhensions, parfois source de frustration intérieure ! S’ouvrir au métier de l’autre, à son cadre de référence est bénéfique à tous les niveaux 🧘 🙌

Comment avez-vous trouvé cet article ?

Note moyenne 0 / 5. Nombre de vote : 0

Soyez le premier à donner votre avis 🙂