Client, designer, développeur: un workflow qui fonctionne

Arrivé depuis maintenant plus d’un an chez Synbioz, j’ai eu l’occasion de travailler sur plusieurs projets avec plusieurs développeurs.

En tant que webdesigner et intégrateur j’ai la possibilité de gérer un projet de la charte graphique jusqu’aux développements JavaScript des interactions utilisateur.

Développeur back et intégrateur sont totalement complémentaires et pourtant, parmi les conversations partagées avec ces deux acteurs du web je remarque que travailler efficacement ensemble n’est pas si simple.

Évidemment le client vient au cœur du processus de création lorsqu’on s’attaque à une application dite “métier”. Il est votre interlocuteur privilégié pour exprimer les besoins auxquels répondra l’application.

En quête permanente du meilleur workflow, je vais tenter de décrire celui qui nous a le plus réussi tout en gardant en tête que cela dépend également de l’investissement et des compétences de chacun.

Commencer par le design :

Mise en place des maquettes

À la base de toute réflexion sur le projet, commencer par designer une application reste une valeur sûre.

Les spécifications, cahier des charges, emails sont un premier support pour vous donner une idée globale du fonctionnement de l’application. Tous ces supports textuels doivent être expliqués une première fois par le client pour en brosser les usages.

Au fur et à mesure, on crée les maquettes. Cette phase demande une grande implication du client. C’est lui qui saura nous guider dans tous les besoins liés à son métier. À l’inverse nous pourrons lui expliquer les contraintes techniques et ergonomique que l’on doit mettre en place afin de faire des arbitrages.

Cette transparence ne peut être que bénéfique pour votre client et vous, et permet de s’éviter 200 pages de spécification, qui sont un enfer à rédiger, à lire et qui inhibe la créativité.

On met en avant les fonctions principales, les différentes difficultés techniques d’intégration, on prends en compte la cible et les objectifs fonctionnels de l’application. Toute la subtilité tiens dans l’équilibrage entre usage et complexité.

Échanger, discuter…

Cette période d’échange entre designer et client a tout intérêt à être surveillée de près par un développeur qui saura exprimer les contraintes back que pourrait induire des fonctionnalités designées.

Je pense que le designer doit aussi s’intéresser aux métiers connexes afin d’avoir un œil global sur ces contraintes.

Une fois cette étape avancée, les maquettes peuvent devenir la référence pour la suite des échanges, sous réserve qu’elles soit validées par le client.

Elles permettent de se rendre compte plus facilement de la masse d’information à gérer, du nombre d’éléments à intégrer, des différentes fonctionnalités à développer.

Les maquettes graphiques ne sont pas forcément exhaustives, elle pourront être adaptées en fonction des échanges intégrateur / client / développeur. Toutefois elles doivent à présent être abouties, et représenter pour votre client la vision finale qu’il aura de l’application afin qu’il puisse les acter.

Et on développe !

Nous avons testé plusieurs configurations : tout intégrer avant de développer, intégrer après le développement…

Au final il s’avère que ces deux processus sont indissociables.

Maintenant que les fonctionnalités sont pensées, que la structure globale de l’application est définie, le développeur commence à créer le squelette de l’application ainsi que les fonctionnalités associées.

Dans notre cas avec Ruby on Rails, comme avec un autre framework, démarrer directement par l’intégration va obliger le développeur à repasser sur toute la structure sémantique pour utiliser les helpers du framework, ce qui sera un travail fastidieux et sans valeur ajoutée.

Par exemple, il devra transcrire un formulaire classique pour utiliser form_for. À l’inverse le framework web offre déjà des mécanismes pour mettre en avant les champs qui sont dans un état d’erreur, autant l’utiliser plutôt que de réinventer la roue.

Le développeur va donc définir la structure et les routes que l’intégrateur pourra suivre.

Au fur et à mesure de l’avancement des différentes fonctionnalités l’intégrateur pourra donc passer sur chaque page et définir les styles associés aux éléments fonctionnels.

Il pourra aussi rapidement définir le layout de base de l’application que le dev pourra récupérer à chaque nouvelle page qu’il crée.

Ces phases durent chez nous généralement 2 semaines. En fin d’itération l’application est mise à disposition du client sur un espace de pré-production à partir duquel il peut commencer à recetter.

Il est important pour le client d’avoir ces retours réguliers pour qu’il se rende compte de l’avancement du projet. De notre côté nous pouvons rapidement collecter du feedback et nous assurer que nous allons dans la bonne direction.

Ces itérations courtes permettent également au client de collecter rapidement des retours auprès de ses utilisateurs potentiels, voire de modifier le comportement de son application dans une démarche agile.

Se discipliner pour limiter les efforts

Il est important dans ce genre de workflow de bien définir les limites pour chaque métier.

L’utilisation d’un outil comme Git est indispensable dans ce genre de configuration puisque des modifications se feront en parallèle ; mais l’idéal reste de trouver un rythme en fonction des besoins de chacun.

Chaque élément doit être précisé sur la maquette pour être pris en compte au niveau back, et une fois développé on y ajoute la couche de style. En clair la règle est de connaître le livrable entrant, sortant et identifier l’origine et le destinataire.

Le travail en équipe nécessite l’implication de chacun, ainsi que de la confiance et du bon sens.

La façon de travailler n’est pas la même lorsqu’on livre un design à son équipe ou à un autre prestataire. Une bonne compréhension du métier de chacun permet de fluidifier les échanges et limiter le niveau de détail.

En terme de règles, on utilise des classes spécifiques pour les utiliser avec JavaScript, on évite d’utiliser les IDs pour le style quand ils servent avant tout à gérer la communication avec le back ; bref on utilise des règles communes de développement.

Tout se joue dans le côté évolutif de votre intégration. Tout comme pour le layout, si vous imaginez un élément en le prenant en compte sur plusieurs pages à la fois et créez ainsi un module, un dev back pourra aisément récupérer le template pour créer de nouvelles fonctionnalités.

On commence à en voir le bout.

Cette façon de travailler en symbiose avec les autres métiers vous permet une plus grande flexibilité et une meilleure consistance de l’application.

Vous prenez toutes les contraintes en considération et améliorez directement l’expérience qu’aura l’utilisateur en vous mettant à sa place.

En plus de vous permettre de gérer développement et intégration en parallèle, une telle façon de travailler vous incite à être acteur de l’application, à détecter les bugs en amont du recettage client et à corriger les détails graphiques auxquels il est parfois difficile de penser lors du maquettage.

Témoin du problème de communication que peuvent avoir designers, développeurs et clients j’essaye d’effacer les différences de nos métiers pour me concentrer sur leur complémentarité.

L’équipe Synbioz.

Libres d’être ensemble.