Certains de mes projets ont abouti, puisque mes maquettes ont été retenues, pour mener à bien ces projets, tout un protocole d’échange avec l’agence de développemnt a été établi afin de réaliser ces projets. J’entend par là, la phase de développement des maquettes dans une agence externe à l’entreprise dans laquelle je me trouvais. Malheureusement, le dialogue n’a pas toujours été fluide et les incompréhensions étaient fréquentes. En effet, il faut savoir que nous avons une approche différente des sites que les développeurs. Nous allons avoir un approche plus ergonomique et esthétique tandis que ces derniers vont plus voir comme des lignes de codes et des contraintes

C’est pourquoi j’ai longuement réfléchi à un “protocole” type permettant d’améliorer les phases d’échanges entre Web Designers et développeurs avec la problématique suivante :

Commençons par le commencement, une fois le développeur ou l’agence de développement en question connu, il faut procéder à une première prise de d’informations qui va être importante avant de commencer le prototypage du site Web en question. En effet, toujours dans une problématique de temps et d’argent, il va falloir favoriser une structure de site qui va rester dans les codes et habitudes de l’agence de développement en question.

Dans un premier temps, on va chercher à savoir quels outils ils utilisent dans la structuration de site web (bootstrap) et quelles sont leurs habitudes. Pour ma part, lors des plusieurs projets que j’ai eu avec l’agence Web Première, ces derniers travaillaient avec bootstrap et un container par défaut de 1110 px pour leurs structures de pages. J’ai dû m’y adapter car lors du projet ACTA boardsports, ma maquette était basée sur un container de 1240 px et j’ai dû tout revoir et resizer (ce fut une grosse perte de temps). Tout ça pour dire que cette information est très importante et reste une des premières informations à demander.

Dans un second temps, dans une logique de réduction des coûts, il sera important de demander quels types de modules ils utilisent pour les fonctionnalités que nous souhaitons mettre sur notre site. Par exemple, une fonctionnalité indispensable à un site e-commerce, le module de paiement (tunnel d’achat). Si nous sommes dans un cas où aucun critère spécifique ou fonctionnalité doit être présent dans le module de paiement, il sera préférable d’utiliser les modules de paiement que l’agence à l’habitude d’utiliser pour ses autres projets. Pour ma part, lors du projet ACTA, j’ai repris un module de paiement sur un autre site e-commerce réalisé par WEB Première et je l’ai adapté à la charte graphique de la marque. En dehors du module de paiement, on peut également demander le type de module de catégorisation utilisé habituellement (dans le cas de WEB P c’étais le module Amazing), là encore on adoptera dans la mesure du possible sa catégorisation en fonction de cela tout en adoptant une design spécifique à la marque.

Ces prises d’informations sont nécessaires dans le cas où le site en question n’ait pas trop de contraintes techniques à respecter avec des fonctionnalités trop spécifiques, c’est -à -dire que l’on a une certaine flexibilité. Elle permet un gain de temps énorme, dans mon cas pour les projet que j’ai effectué avec WEB Première, j’ai parfois été obligé de reprendre des maquettes entière car les modules que j’avais maquettés étaient complètement différents de leurs modules qu’ils utilisent et auraient induit une surcoût énorme lors du développement du site.

Une fois les premiers questionnements effectués, le Webdesigner peut procéder au prototypage du site en question. Lors du prototypage, il est toujours bien d’avoir l’avis du développeur ou de l’agence sur la faisabilité d’un module ou d’une fonctionnalité présente dans la maquette. Cela permettra d’avoir des réponses rapidement et de pouvoir anticiper des solutions alternatives en cas de surcoût excessif ou de trop grosses difficultés de réalisation.

Après la phase de prototypage, il s’agira de transmettre la maquette à l’agence de développement afin de leur faire prendre connaissance du projet en question. Lors de la transmission de la maquette, il faudra toujours accompagnées celle-ci d’un cahier des charges qui permettra de détailler toutes les spécificités de la maquette et les fonctionnements qui ne sont pas prototypable ou qui ne sont pas visibles sur la maquette. Cela permettra de réduire le nombre de questions qui nous semblent logiques lors du premier retour de l’agence sur le projet, et donc un gain de temps.

Lors de cette phase d’échange qui va se conclure par la signature d’un devis de développement, il faut bien définir lors de cette étape et non plus tard qui sera charger de quoi entre l’agence et de Designer ; on va prendre l’exemple des traduction de boutons et modules, tous ces types de tâches doivent être mentionnées sur le devis si elle sont réalisées par l’agence. Les tâches doivent être clairement réparties. Dans mon cas lors du projet ACTA, j’avais compris qu’il étaient en charge de la traduction des pages CMS (la marque, skateboards guide, etc) alors qu’en réalité il les avaient laissées vides dans les langues autres que le français et c’était bien a moi de dupliquer ces pages dans les autres langues et de les traduire.

Une fois la phase d’échange entre le designer et le développeur terminée concernant les spécificités du projet, il s’agit ensuite de la phase de développement du projet en question. Afin de ne pas perdre de temps et de ne pas se retrouver dans la panique. En effet lors de mon projet ACTA, d’un jour à l’autre, sans prévenir WEB P avait terminé le développement du site et c’était moi qui était en retard par rapport à eux concernant l’envoi des assets visuels. Il faut donc demander à l’avance les besoins du site en termes de contenu ; j’entend par là les contenus visuels et textuels avec les tailles et les poids pour les images et icônes et le nombre de caractères pour les textes.

Une fois la phase d’envoi et d’ajout de contenus textuels et visuels sur le site terminé, et les quelques rectifications effectuées par l’agence afin de rendre le site fonctionnels, il s’agit de procéder au “débug” du site. J’ai mis en place une procédure bien précise permettant d’analyser au mieux le site en loupant un minimum de bugs.

Vient ensuite le fonctionnement du site et sa mise à jour régulière. Pour conclure, cette méthodologie est très importante afin de favoriser le gain de temps et d’argent. Cette méthode peut s’appliquer à tous les projets pouvant se permettre une certaine adaptabilité sur certaines fonctionnalités et ayant une problématique de réduction maximale des coûts. Sur des projets plus précis avec des fonctionnalités bien particulières ce ne sera pas le cas et la problématique de coût ne serait plus d’actualité pour ce type de projet.