Réussir les ateliers de conception d’un projet web
Après avoir abordé les grands principes définissant une phase de conception dans notre précédent article, nous vous proposons de nous atteler à la définition plus précise des ateliers de conception d’un projet web.
Si vous êtes effectivement passés par toutes les étapes que nous avons décrites, que vous ayez un projet en tête, que vous nous ayez déjà contacté, que vous soyez satisfait de la proposition d’accompagnement que nous avons réalisée, et que vous sachiez que la phase de conception va commencer, vous devez encore légitimement vous poser quelques questions.
Comment se déroule les ateliers de conception d’un projet web ? Combien de temps prendront-ils ? Comment allez-vous vous approprier le design que vous avez réalisé ?
Une fois que vous avez terminé les différentes étapes préalables à votre projet, de l’idéation au choix de votre partenaire, il est légitime de vous poser encore quelques questions au moment d’aborder la phase d’ateliers de conception promise par votre partenaire.
Pour répondre à toutes ces questions et aller un peu plus en profondeur dans cette phase d’ateliers , nous vous proposons de prendre un exemple concret : l’entreprise DISRUPTOR2000 vient de nous contacter pour développer une application révolutionnaire de mise en relation de particuliers sur un seul et unique réseau social : DISRUPTBOOK. DISRUPTOR2000, en bon élève nous ont fait parvenir un cahier des charges extrêmement détaillé sur la base duquel nous avons pu leur fournir une estimation financière et une proposition d’accompagnement sur-mesure. Nous avons bien identifié les éléments critiques de l’application (rôle de l’utilisateur, interaction via des formulaires, volumétrie des données échangées, publication de photos, vidéos, messagerie instantanée, etc.) et défini une base technique solide (un front en VueJS et un back en Symfony par exemple) mais nous avons encore besoin d’informations pour déterminer la manière de les présenter. Aussi nous savons que l’interaction entre les utilisateurs et la viralité de l’application seront les éléments clés de sa réussite. De plus il va nous falloir travailler sur un design efficace et une expérience utilisateur parfaitement adaptée. Dernière chose, DISRUPTOR2000 souhaite disposer de technologies flexibles et ne pas être dépendant d’un outil sur étagère. Il souhaite connaître les différents éléments qui vont composer son application et s’assurer qu’elle pourra évoluer facilement
– Revue des interfaces et analyse du besoin
– Design UI/UX
– Architecture technique
– Validation des spécifications.
Dans notre précédent article, nous avions vu que notre phase de conception allait se découper en plusieurs ateliers ; que nous avons choisi de définir comme suit pour l’exemple de DISRUPTOR2000.
1er atelier : Revue des interfaces & analyse du besoin
Ce premier atelier va nous permettre de revoir ensemble toute la proposition d’accompagnement ainsi que le cahier des charges. Nous validerons très rapidement les éléments qui ne font pas débat (il y aura 2 types d’utilisateurs, une gestion des droits classique, etc.) et nous attarderons sur les fonctionnalités un peu plus complexes.
L’objectif n’est pas seulement de valider bêtement une liste de fonctionnalités, mais plus d’être force de proposition sur la manière de traiter les différents objets métiers. Nous avons effectivement la chance de travailler pour un grand nombre de sociétés dans des secteurs extrêmement variés et nous mettons cette expérience au profit de tous nos nouveaux clients. Il s’agit alors de proposer des schémas globaux, éprouvés, sur lesquels il paraît judicieux de se calquer pour assurer le bon fonctionnement de l’application. Là ou les deux visions s’entrechoquent (celle du client et la nôtre), nous ouvrons le débat et validons ensemble la manière de traiter chaque sujet. Nous fournissons ensuite un document détaillé récapitulant le comportement de l’application dans son ensemble.
2ème atelier : Design UI/UX
Pour ce second atelier nous pouvons encore féliciter DISRUPTOR d’avoir déjà travaillé sur un design et des parcours utilisateurs. Ils souhaitent conserver l’ensemble des éléments déjà réalisés, mais sont plutôt réceptifs à l’idée de recevoir des conseils sur des points d’amélioration. Nous avons donc réalisé un audit graphique en amont de l’atelier que nous allons leur présenter en séance et intégrer les modifications qu’ils auront validé à la fin de l’atelier.
3ème atelier : Architecture
Cet atelier est un peu particulier. Bien que nos interlocuteurs n’aient pas toujours les compétences techniques nécessaires pour juger le type de technologies choisies, nous tenons à leur présenter un document d’architecture technique en leur expliquant ses différents composants.
Nous en profitons notamment pour justifier l’emploi de chaque outil en le mettant en rapport avec ses besoins. DISRUPTOR peut alors vérifier grâce à ce document, que l’ensemble des besoins exprimés est satisfait. En fonction des retours et des échanges pendant cet atelier nous validons ou modifions ce document.
4ème atelier : Validation des spécifications
Ce dernier atelier va nous permettre de présenter l’ensemble des livrables à DISRUPTOR 2000 pour nous assurer de la bonne compréhension et de la bonne traduction de leurs besoins en spécifications fonctionnelles et techniques. Ce moment sera l’occasion de faire les derniers retours sur les thématiques abordées avant de valider la phase de conception.
DISRUPTOR2000 nous a donc fait les remarques suivantes :
REMARQUE LIVRABLE 1
“Finalement, je ne souhaite pas que certains utilisateurs aient plus de droits que d’autres dans un premier temps. Je ferais une partie pour les entreprises dans un second temps, une fois que le modèle sera bien assis, sortons cette partie du périmètre de l’application”. Pas de problèmes ! Nous pouvons mettre de côté cette partie de la spécification et la récupérer pour mettre en place des évolutions dans un second temps 😉
REMARQUE LIVRABLE 2
“Super travail TheCodingMachine, je suis super impressionné ! Mais finalement je ne suis pas sûr que le bleu comme couleur principale soit la plus adaptée, on pourra tout faire en vert ?” Bien sûr, nous vous fournirons l’ensemble des écrans déclinés en vert sans aucun problèmes
“Ah et on peut refaire une page d’accueil complètement différente ? J’aimerais voir ce que ça donne avec ça là, et ça là…”
Malheureusement à ce stade-là nous ne pouvons que faire des adaptations mineures des maquettes proposées comme la couleur, l’emplacement de certains éléments. L’atelier design et les itérations sont là pour valider l’identité graphique de votre application que nous vous proposons de décliner en fonction du nombre de pages défini dans les spécifications. Si vous le souhaitez nous pouvons faire intervenir notre équipe Design en marge de ce projet pour vous proposer d’autres intentions de design, mais cette prestation sera séparée du projet. Nous pourrons bien entendu intégrer tous les nouveaux éléments graphiques ainsi réalisés à l’application !
REMARQUE LIVRABLE 3
“Bon de toute façon, la technique je vous fais confiance, je ne comprends pas grand chose. Mais c’est aussi quelque chose qui me fait un peu peur parce que je ne peux pas avoir le contrôle, comment vous pouvez m’assurer que tout va bien se passer ?”
Nous travaillons essentiellement grâce aux technologies développées en Open Source. Ces outils sont notamment développés par Google, Amazon ou encore Facebook, c’est à dire qu’elles sont suivies par les plus grandes communautés de développeurs dans le monde. Toutes ces technologies seront donc totalement évolutives et maintenables. De plus, vous serez totalement propriétaire du code que nous allons vous livrer, si vous souhaitez embaucher des développeurs en interne, les bonnes pratiques techniques que nous mettons en place leur permettront de le reprendre et de le faire évoluer très facilement. Nous documentons aussi toutes les applications que nous développons et réalisons régulièrement des guides plus fonctionnels (administrateur ou utilisateur) dans les cas d’applications complexes pour faciliter l’adhésion à l’outil et permettre une prise en main rapide.
A noter qu’il arrive souvent que la phase de conception révèle de nouvelles fonctionnalités ou besoins liés à l’application, dans ce cas-là, si les adaptations sont mineures nous pouvons les intégrer au périmètre de développement. Si elles concernent le développement d’un module entier ou d’un set de fonctionnalités, nous pouvons proposer de modifier les spécifications et réévaluer le coût global du projet pour intégrer ces éléments. Dernier cas possible, nous proposons un allotissement de l’application en développant la première base identifiée et en planifiant les évolutions pour un second lot. Nous avons donc intégré ces différents éléments aux spécifications dans les jours qui suivaient et DISRUPTOR a finalement pu valider la spécification. Il est temps de commencer à développer !
Mais quels sont les critères qui peuvent vous permettre d’évaluer la réussite de cette phase de conception ? De vérifier la qualité des livrables fournis ? De se satisfaire des ateliers proposés ?
La suite au prochain épisode 😉
N’oubliez pas de nous suivre sur vos réseaux sociaux préférés !
Pierre Bertrand, Consultant chez TheCodingMachine
