Intégration Designer x Developer: comment optimiser?

Des designers qui travaillent de l'avant

Cela semble un paradoxe dans un environnement de développement Agile, et certains le traitent même comme un anti-modèle, et à mi-chemin vers la méthodologie de développement Waterfall! Cela pourrait même en faire partie. Cependant, dans notre contexte, les concepteurs travaillant un peu en avance sur les développeurs se sont révélés être une bonne solution.

Généralement, au début du projet, nous avons une itération exclusive au design: recherche client et utilisateur, flux, conception. À la deuxième itération, lorsque les développeurs structurent l'application, définissant son architecture et ses technologies, les concepteurs plongent dans les processus UX et UI sur les fonctionnalités à implémenter par les développeurs à la prochaine itération.

C’est la solution que nous avons trouvée pour donner un peu de temps et de marge de manœuvre aux concepteurs pour effectuer des recherches sur le système dans son ensemble. Après ce premier cycle, UX et UI continuent d'avancer (avec de nouvelles investigations spécifiques) au moins une itération avant les développeurs, qui peuvent implémenter des fonctionnalités avec des interfaces, des prototypes validés et des user stories déjà en main!

Malgré cette différence de fonctionnalité au sein d'une seule itération, si un développeur a besoin de clarification dans la spécification sur laquelle il travaille, le concepteur rétroagit pour partager sa compréhension de cette fonctionnalité. En plus de cela, de nombreux ajustements sont nécessaires lors de l'intégration back-end (si vous travaillez avec un logiciel, vous savez comment ça se passe!). De cette façon, les concepteurs, en fait, marchent sur des fils simultanés de fonctionnalités distinctes: regarder vers l'avenir et être dans le présent.

Il est important de souligner que nous n'indiquons pas beaucoup d'interfaces à préparer avant leur développement (ce qui se passe lorsque les concepteurs sont très avancés): au fur et à mesure du développement, la compréhension du système évolue, la compréhension de ses flux est approfondi, et des ajustements sont toujours nécessaires! De plus, nous ne voulons pas retravailler, tout jeter. Cela dit, les concepteurs pourraient être en avance, mais pas trop loin!

Partager la vision

Cette solution est liée à un écart d'approche problème. Au lieu de le voir comme un élément nuisible à la communication dans l'intégration designer × développeur, nous devrions essayer de l'utiliser comme une force.

Le développement agile favorise la construction incrémentale; naturellement, l'équipe commence à se concentrer sur les solutions à court terme et leurs fragments, et la vision globale du produit finit par se perdre dans la mer des itérations. Pour profiter de la vue holistique, les concepteurs ont généralement, au début de l'itération, les concepteurs présentent la ou les fonctionnalités à implémenter. Cette présentation apporte des détails sur les fonctionnalités, mais aussi sa position dans l'ensemble du système: ses objectifs, le contexte d'utilisation et les relations avec d'autres fonctionnalités.

Ces discussions ont été fondamentales pour induire des idées sur les relations et les interférences entre les parties des systèmes. De nombreuses règles métier sont également mises à jour, et les connaissances sont aplaties, ce qui est essentiel dans Agile et ses fonctionnalités non méticuleusement décrites.

la communication

La communication avec les clients est impérative dans notre contexte; en général, nous leur disons: il y a des moments où vous vous sentirez faire partie de l'équipe, parfois ce sera ennuyeux, et cela prendra du temps, mais nous devons vous avoir à nos côtés! C'est nécessaire parce que dans l'approche itérative que nous explorons tout au long du projet et que nous devons valider rapidement (de manière rapide) et toujours (de manière simple et continue), pour découvrir les exigences des systèmes et les hiérarchiser.

La communication entre les membres de l'équipe est cependant plus qu'impérative! Nous aimons garder la communication disponible pour tout le monde, tout membre peut participer à la plupart des réunions et les moyens de communication numériques sont largement accessibles. Bien sûr, certains sujets ne sont pas dans l’intérêt de tous, ou nous savons que cela favorisera une discussion avant un consensus. Pour ces cas, nous essayons d'utiliser des moyens privés (nous ne voulons pas inonder les véhicules partagés, les gens commenceraient à ignorer les messages essentiels) et, lorsqu'il y a un dénominateur commun, nous exposons les conclusions et les motivations. Il est important de donner un résumé, afin que les décisions soient non seulement acceptées mais comprises.

En plus de cela, nous avons rencontré des questions en double au client. Pour éviter cela, avant de demander au client, demandez d'abord aux collègues de l'équipe! Une autre situation courante est celle d'un membre de l'équipe qui s'essaye au cerveau en essayant de comprendre quelque chose. Nous savons que cela fait partie du processus d'apprentissage et nous le stimulons. Cependant, lorsque les informations ne sont pas suffisamment claires et que la vitesse est plus précieuse, demandez à l'équipe et demandez à nouveau jusqu'à ce que vous compreniez.

Chez Guava nous n'avons pas de postes fixes, nous définissons notre table en fonction du projet qui nous est alloué. La position physique s'est avérée essentielle pour une communication directe, rapide et efficace en réduisant son bruit. Pour citer un standard du principe Agile: la conversation en face à face est la meilleure forme de communication.

Prototypes basse et haute fidélité comme éléments de communication et de validation

Même si les concepteurs conçoivent la première vue holistique du système à la fin de la première itération, le seul produit livrable pour tout le système est généralement le flux de produits numériques (d'autres artefacts intermédiaires, tels que l'analyse de recherche, sont également générés). Tout au long des itérations, d'autres artefacts de conception importants de parties du système sont créés: des prototypes haute et basse fidélité.

Pour nous, ces prototypes sont utilisés non seulement pour la validation du contenu, de la navigation et de l'esthétique avec le client / l'utilisateur, mais aussi pour expliquer les fonctionnalités aux membres de l'équipe. En fait, avant de les montrer au client, il y a des séries d'expositions internes pour que les développeurs puissent comprendre et se prononcer (sur les difficultés et les ajustements). C’est le moment de la négociation entre les concepteurs et les développeurs, tout en gardant à l’esprit que l’objectif principal est de répondre aux besoins du client et qu’une analyse coûts-avantages doit être effectuée. En plus de cela, les prototypes sont également référencés par des user stories.

Histoires d'utilisateurs

Les histoires d'utilisateurs prennent en charge l'intégration concepteur × développeur car elles traduisent en mots les fonctionnalités découvertes par les concepteurs afin que les développeurs puissent les implémenter. Dans Agile, une documentation étendue est évitée; par conséquent, le niveau de détail est controversé: nous devons contrôler la portée du projet, mais nous ne voulons pas surévaluer et perdre beaucoup de temps! À Guava, nous recherchons en fait le niveau élevé de description des fonctionnalités et la responsabilité des histoires. Cependant, il est important de garder à l'esprit qu'ils (ou une manière équivalente de décrire les fonctionnalités) sont importants pour l'intégration designer × développeur.

Collaboration

Cette solution fait de chaque problème de conception ou de développement (ou tout autre type lié au projet) un problème d'équipe! Pour que toutes les responsabilités soient partagées entre les membres de chaque équipe, la connaissance des activités de chacun est nécessaire.

D'un côté, la collaboration vise à démocratiser la responsabilité de l'expérience utilisateur à travers une co-conception: les concepteurs mèneront des processus de conception, cependant, les développeurs devraient être inclus dans les processus de création. Pour un exemple pratique, voir le sujet: Toute l'équipe dans le processus d'immersion.

D'un autre côté, les problèmes de développement peuvent également être persécutés par les concepteurs. Pour un exemple pratique, voir le sujet: Un point de plus pour le concepteur de licornes.

Toute l'équipe dans le processus d'immersion

Cette solution favorise une meilleure connaissance des activités de conception parmi les développeurs: les développeurs agissent en quelque sorte en tant que chercheurs, plongent dans les processus de conception, comprennent et participent aux choix de conception de produits pendant au moins une itération. Ce mélange finit par générer de nouvelles idées et des solutions encore meilleures. De plus, ce processus s'est avéré important pour renforcer les relations et accroître la synergie des équipes, car nous avons différentes équipes pour chaque projet.

Rappelez-vous que j'ai dit que nous dédions la première itération exclusivement au design? De plus en plus, nous essayons d'inclure les développeurs dans cette étape, en les faisant agir en tant que concepteurs! Chaque développeur d'équipe participe à la dynamique, fait des recherches et met la main à la pâte en analysant également toutes les données collectées! Il aide les concepteurs à se déplacer plus rapidement (le temps est limité), permet aux développeurs de comprendre le produit et, certainement, est rentable tout au long du projet en améliorant l'intégration concepteur × développeur.

Tout au long du projet, nous essayons également d'inclure, au moins un développeur sur les décisions de conception cruciales, afin que leur intuition contribue au processus de décision.

Un point de plus pour le concepteur de licornes

Chez Guava, l'un des principes de conception est le suivant: «les moyens de production appartiennent aussi aux designers ». Dans un spectre plus large, cela signifierait que la créatrice connaît le matériau pour fabriquer son produit; dans notre set, cela implique que le designer se développe aussi! Ici, ils implémentent des interfaces Web avec HTML, CSS et, dans certains cas, JavaScript. Cette solution favorise une meilleure compréhension des activités des autres développeurs, en plus des autres avantages signalés dans cet article: Le mythe du mythe du concepteur de licornes.

Nous savons qu'il existe des différences entre les différentes technologies, mais les concepteurs qui recherchent des technologies pour la création de produits numériques soulèvent en eux-mêmes une perspective plus réaliste des limites et des barrières (qui peuvent ou non être dépassées!). En plus de changer la vision des concepteurs depuis la conception du produit, cette réalité leur permet de comprendre les difficultés des développeurs et d'agir en équipe pour les résoudre.