En tant que développeur frontend, j’aimerai vous parler de la relation, ou plutôt, de la « non-relation » entre les designers et les développeurs frontend en agence, avec ses problèmes, ses conséquences et ses solutions possibles (que j’énoncerai dans un second article).
Petit rappel métiers
✏ Le(s) Designer(s)
Le designer va se concentrer sur la conception du site. Il y a certes l’apparence visuelle (choix des couleurs, des typos etc…) qui va être importante mais aussi l’expérience utilisateur. Il est difficile de concevoir qu’un site soit beau mais inutilisable ou incohérent pour ses utilisateurs. C’est là qu’intervient l’User Xperience Designer en amont de l’User Interface Designer.
- L’UX designer va proposer une interface utile en plaçant les objectifs de ses utilisateurs au coeur de sa réflexion ;
- l’UI designer va ensuite rendre cette interface agréable à regarder et va placer les émotions de ses utilisateurs au coeur de sa réflexion.
✏ Le Développeur frontend
L’objectif principal du développeur front-end est de développer des sites de façon à ce qu’ils ressemblent exactement aux maquettes préalablement conçues par le designer (intégration pure). En travaillant de concert avec le développeur backend, il s’occupe aussi et surtout de développer les fonctionnalités, les interactions du site tout en produisant un code propre, modulable et en proposant des technologies adaptées au besoins du client.
Pour moi, le développement front-end n’est finalement que le prolongement du design, et il est donc normalement très important que les deux métiers sachent communiquer.
Problème
Hors il arrive que ces deux corps de métier ne se trouvent pas dans la même agence. Ce fossé entre design et développement est donc souvent présent.
Chacun fait son travail de son côté, sans penser à l’autre et sans se consulter… Le designer va dans un premier temps créer les maquettes du site, puis ses maquettes vont passer dans une seconde agence qui va s’occuper de les développer. Et quand il y a des incompréhensions, on ne sait pas forcément à qui revient la faute, si le designer s’est mal exprimé ou si le développeur a mal interprété… En tant que développeur front-end, vous avez peut-être déjà rencontrés ce genre de problèmes lorsque vous avez reçu des maquettes :
- L’utilisation de masques, options de fusion, etc… est difficilement réalisable (voire parfois impossible)
- Les textes définitifs du site ne se limiteront jamais à ceux des maquettes. « Hello » en anglais se dit « Здравствуйте » en russe ! (idem pour les contenus plus longs, ou en wysiwyg rédigés en back-office)
- Les couleurs dans les PSDs en mode : 50 Shades of Grey ou des couleurs de texte en « noir opacité 0.5 » au lieu d’un gris
- La gestion des erreurs ou des cas particuliers n’est pas prévue : erreurs dans un formulaire, erreurs serveurs, contenus vides, écrans 27 pouces, etc…
- Les différents états d’un élément sont soit cachés, soit mal rangés, soit juste inexistants. Pas ou peu de dossiers rangés, des calques nommés « Calque 1 » « Calque 2 » « Calque 2 copie » « Groupe 15 copie » etc…
- La conception en 1er lieu de la home page qui est une page spécifique alors que les pages « templates » permettraient de mieux s’organiser pour le code
- Les PSD sont des fichiers statiques, même avec des specs fonctionnelles, il est souvent difficiles de se rendre compte d’un effet de transition ou d’animation souhaité.
Bref : c’est un calvaire et une perte de temps de devoir déchiffrer et interpréter des maquettes ! Je ne dis pas qu’il est facile d’anticiper les problèmes de conception, mais je pense que certains peuvent être évités. Dans tous les cas, le manque de communication et/ou de travail main dans la main est une réel obstacle pour le bon déroulement d’un projet. Malheureusement, il est compliqué voire impossible de faire autrement. Cependant, il existe quelques outils qui peuvent aider à combler ce manque…
