Place du rôle de designer UX/UI en agilité

Faut-il un track ou 2 tracks afin de séparer Design UX/UI et développement pour que ça aille plus vite ?

C’est une des questions principales qui m’ont été posées au démarrage d’une mission d’accompagnement d’équipes.

Une réponse générale indépendamment de la nature de l’activité

Quelle serait l’organisation optimale des activités de design ux/ui si on demande aux designers eux-mêmes et aux développeurs ?

On risque de se confronter au même type de mur d’incompréhension que celui que devops tente de retirer entre des développeurs qui changent fréquemment leur code et des opérationnels qui veulent garder la maîtrise de la plateforme de production et ralentir la fréquence des changements.

Si nous pensons que les personnes d’une équipe gagnent à se synchroniser et à interagir quotidiennement pour préciser ce qui change, ce qui serait le plus important à faire, à finir alors il n’y a pas de débat. Le daily scrum meeting est fait pour ça, l’équipe gagne à être regroupée pour coopérer au jour le jour.

Si la fréquence d’interaction entre certaines personnes et le reste de l’équipe est plus espacée (moins de 2 fois par semaine ) alors il convient de “décorreller” l’activité et de ritualiser leur rencontre, pour fludifier le cycle du développement.

Quoi qu’il en soit, il est préférable que la discussion soit conduite avec les personnes elles-mêmes et que la décision sur la règle d’interaction puisse être révisée de façon ponctuelle (le SM peut faciliter l’exception) ou pour une période définie (le SM peut faciliter la définition, la communication, l’adoption/l’acceptation de ce changement dans l’organisation).

Rôle et activités des designers UX/UI

Les designers UX / UI ont à interagir avec les autres rôles de l’équipe et certaines parties prenantes extérieures :

• Product Owner
• design UX <-> designer UI
• experts/représentants métiers
• SEO
• utilisateurs ?
• développeurs

Eléments de travaux

Le Product Owner constitue un premier backlog d’éléments décrivant le produit à réaliser. La plupart de ces éléments seront des fonctionnalités offertes à l’utilisateur. Si le produit est un site web, certaines seront facilement associées à une page ou un bloc à réaliser.

L’articulation et la représentation générale de ces fonctionnalités et blocs est pensée et concrétisée par le designer de l’expérience utilisateur. Les critères pour l’améliorer, sont la simplicité, la navigabilité du site web. Les contraintes SEO poussent aussi à positionner des informations significatives sur les pages pour l’optimisation de les moteurs de d’indexation.

Tout ce travail est pensé “en amont” du design de l’UI et du développement, afin de limiter le rework.

Il s’agit de trouver la bonne granularité pour le découper et fludifier le processus afin d’avancer… Ainsi chaque élément de haut niveau “fonctionnalité / page” sera couvert par une Epic. Chaque Epic sera couverte par une tâche de Design UX couplée à une tâche de Design UI. Les 2 pouvant être fusionnées en une tâche de “DESIGN UX/UI” dès lors quelle porte sur le même objet et aboutit à des User Stories de développement décrites par une même maquette.

Feedback après 6 mois

Ce mode de fonctionnement a bien marché. Les Designers UX/UI communiquent quotidiennement sur leurs chantiers en préparation en sollicitant les développeurs sur la complexité de ce qui est prévu. Ils communiquent les retouches mineures sur les chantiers précédents à intégrer au fil de l’eau. Ils participent à la vérification des User Stories disponibles au fur et à mesure en environnement d’intégration.

Bref, le propre d’une coopération efficiente, qui élimine les écarts au plus tôt, en impliquant le Product Owner pour décider de la maturité et de la pertinence des changements à apporter.